Should I extend ASP.NET Security for a public site?

views:

answers:

+2 Q:

Should I extend ASP.NET Security for a public site?

I have a ASP.NET MVC site with a private site administration application secured with ASP.NET sql-backed authorization. I need to add a login for the public site to allow visitors to sign up for an account.

I am thinking I should create totally seperate storage for the public site, rather than extend the existing user db and rely on roles to keep public users out of the back office. Is there any reason not to do this?

Hey,

Time and potentially money would be one reason. Otherwise, if you have the time. Depending on the need, not knowing exactly the issues at hand, it could also add a lot of complexity...

HTH.

Brian 2010-09-10 15:52:55

Will you ever have a user with more than one role? Could you end up storing the same user in more than one database? If so, I would keep your users in a unified DB.

ThatSteveGuy 2010-09-10 16:04:07

+1 A:

Yes there is. You can isolate the private database from the public database. Create 2 database user accounts, make sure they only have access to the 1 database they need. The public and private apps will use different accounts. Then lock down the database accounts to make sure they only have the rights needed for the web app to function. (I'm not sure what database you are using. if you are using ms-sql make sure they don't have access to xp_cmdshell, if you are under mysql make sure the account doesn't have FILE privileges. There are other considerations but this is outside the scope of this question.)

If a SQL Injection vulnerability is found in the public part of your site then they will be able to access that one database leaving your private site unaffected by the attack.

Rook 2010-09-10 18:03:17

Hrm, I don't know about this. Part of me says, if the site is vunerable to SQL injection I've got much bigger problems, and this is just damage control.

Paul 2010-09-13 19:40:31

@Paul you should try exploiting sql injection vulnerabilities, and then maybe that part will go away. Its called defense in depth, you might not be able to find everything so you have to plan for the worst. This is why you hash passwords. If you have setup your sql permissions properly, the most an attacker can get is an extra select. Executing multiple quires and gaining access to cmd.exe shouldn't be possible, but it is by default.

Rook 2010-09-13 20:57:32

Ah, "Defense in Depth" is exactly what I was looking for. So this was my original plan but now I feel like I can defend it intelligently. After a little reading it appears that Defense in Depth refers to protecting against different attack vectors, not the same attack penetrating the first layer of defense. I'd argue that the reason you hash passwords is mostly to prevent malicious employees from stealing users accounts--but that same logic works for my case.

Paul 2010-09-14 01:04:53

@Paul passwords are hashed to delay the attacker after he has broken into the system. It could be an insider threat, or more commonly an attacker using a union select or sub-select to read data in the database.

Rook 2010-09-14 01:19:24

Sounds like somebody had a bad experience with SQL-injection. :)

Paul 2010-09-14 01:55:54

@Paul actually I write exploits. Here is a recent one (http://www.exploit-db.com/exploits/12510/)

Rook 2010-09-14 03:45:39

Ah ok, well your questions/answers are some interesting reading now that I look.

Paul 2010-09-14 12:36:08

@Rook: When you're writing them, you might want to spell-check your comments. :-)

Steven Sudit 2010-09-18 02:32:48

ansaurus

tags:

views:

answers:

Should I extend ASP.NET Security for a public site?

related questions