SQL Injection Attacks – ASP.NET 2.0 Membership – ASP.NET 2.0 Security Best Practices

Awhile back, Scott Guthrie wrote a post entitled, Don’t run production ASP.NET Applications with debug=”true” enabled. I thought to myself that keeping debug = “true” certainly had to be one of the worst things you could do in a web application.


However, I found something worse in my opinion. I came across this chunk of code yesterday being recommended by one developer to another for website authentication in ASP.NET 2.0:


 

SqlCommand cmd = new SqlCommand(SELECT DISTINCT UserId FROM
[User] WHERE (LoginId =’
+TextBox1.Text + ) AND
(LoginPwd=’
+ TextBox2.Text +), cnn);

 


And, what’s worse, the developer said that he had already tried it :(


I think Microsoft has done an excellent job of pushing security over the past couple of years and has built so much into ASP.NET 2.0 that nobody should be writing or recommending code of this nature.


This has the obvious problem of being susceptible to Sql Injection Attacks. This developer also appears to be storing passwords as clear text in the database. Etc.


I realize nobody is perfect and all of us are learning new best practices and techniques daily, but security is not a good place to learn things by trial and error IMHO.


SQL Injection Attacks


For those of you who are unfamiliar with SQL Injection Attacks, you can check out the following MSDN Article, Stop SQL Injection Attacks Before They Stop You. I wrote something up a long time ago, too, called SQL Injection Attacks – Parameterized Queries – Regular Expressions – ASP.NET Security Best Practices.


ASP.NET 2.0 Security Best Practices


Microsoft has a really good article, called Security Practices: ASP.NET 2.0 Security Practices at a Glance, that does a really good job of discussing ASP.NET 2.0 Security Best Practices.


ASP.NET 2.0 Membership, Roles, Forms Authentication, and Security Resources


Scott Guthrie put together a nice list of resources for anyone wanting to learn more about ASP.NET 2.0 Membership and Security so that you don’t roll your own:


ASP.NET 2.0 Membership, Roles, Forms Authentication, and Security Resources


Microsoft Threat Analysis & Modeling v2.0 BETA2


Microsoft has a free tool for threat analysis and modeling:


“Microsoft Threat Analysis & Modeling tool allows non-security subject matter experts to enter already known information including business requirements and application architecture which is then used to produce a feature-rich threat model. Along with automatically identifying threats, the tool can produce valuable security artifacts such as:


- Data access control matrix
- Component access control matrix
- Subject-object matrix
- Data Flow
- Call Flow
- Trust Flow
- Attack Surface
- Focused reports”


Check it out here. I think it is still in BETA2.


 


Plenty of good information out there on ASP.NET 2.0 Security. My recommendation is essentially not to roll your own. Leverage the ASP.NET 2.0 Membership, which takes care of everything for you.

This entry was posted in Uncategorized. Bookmark the permalink. Follow any comments here with the RSS feed for this post.

9 Responses to SQL Injection Attacks – ASP.NET 2.0 Membership – ASP.NET 2.0 Security Best Practices

  1. jkimble says:

    Dave,

    Here’s a URL I keep in my back pocket!

    http://podcast.microsoft.com.au/teched2005/teched_jesper_hack_anatomy.wmv

    It’s Jesper Johansson’s security presentation. I tell every young (or “who doesn’t understand what the deal with this security stuff”) programmer that I know that they should watch this. It’s funny. You’ll laugh in a number of places.

    What he does is a demo hack of a windows network and the attack starts with SQL Injection. It is admittedly a straw man, but once you’ve seen it you can never think about security in the same way again…

    Sorry I’m late in reading

  2. scottgu says:

    The ASP.NET 2.0 Membership API by default uses one-way hashing and per-row SALT hashing for this very reason.

    It is frightening how many people store passwords insecurely with custom solutions — beware!

    Scott

  3. ewise says:

    Dave – Yeah you didn’t mention encryption, but I felt like it was alluded to by the clear text in the database comment. Just wanted to be sure people who read that didn’t automagically think encryption. =)

  4. johnpapa says:

    Salt? Encryption? We don’t need no stinking encryption? … OK … the medication is kicking in :)

  5. johnpapa says:

    Sometimes I run into people who have confusion over what code is open to SQL Injection attacks. For those who do not use parameterized SQL, the argument I often get is that they cannot use stored procedures so that have no choice but to be open to injection attacks. While its true procs can help protect you, its not so much the procs that do it, instead it is the ADO.NET parameters.

    Yeah, I know you know all of this David … just thinking out loud here :)

    Security practices are still one of those areas of development that our industry has no matured in as fast as the rest of the “cooler” features.

  6. dhayden says:

    Travis,

    The other thing is that hackers are not your only threat. Employees, business partners, web developers, webmaster, DBA, and everyone else who has possible access to the database is a threat. The hacker may be the least of your concerns :)

  7. dhayden says:

    Travis,

    True. But, do you want to add the fact that you have disclosed millions of user’s passwords ( that they may use for other things ) to the list of your problems. Always a one-way hash plus random salt.

    Eric,

    I didn’t say anything about encryption :) One-way hash + random salt is the current best practice.

  8. ewise says:

    Encryption isn’t always the answer as it can be problematic for moving the database to a new machine etc.

    What I usually favor is a nice hash + random salt. It’s portable and serves as one-way comparisons.

  9. Travis says:

    “storing passwords as clear text in the database”

    The thing is, if a hacker gets to the point of being able to read passwords in your database, encrypted or not, there are worse things coming your way than someone being able to read passwords.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>