Editor's Note: Welcome to .NET Rocks Conversations, excerpts from the .NET Rocks! weekly Internet audio talk show. This month's excerpt is from show 735, with Troy Hunt, a software architect and Microsoft MVP for developer security, author of OWASP Top 10 for .NET Developers, and creator of ASafaWeb -- the Automated Security Analyzer for ASP.NET Websites. Troy joins Carl and Richard in a discussion of the most prevalent security vulnerabilities that .NET and ASP.NET developers must deal with in their applications.
Carl Franklin: So, OWASP Top 10 for .NET Developers was your landmark series. Tell us about this.
Troy Hunt: OWASP is the Open Web Application Security Project. These guys have put together an open not-for-profit foundation to talk about web security in a very generic technology-agnostic fashion. They've laid down a bunch of risks; I call these the top 10 application security risks. This is a really fantastic resource, but I wanted to get something that was a little bit more specific to the .NET community.
CF: Sure.
TH: I really wanted to get thorough and create a resource that people could use that was very practical. I also wanted to just get under the covers and see how these things work -- so we know, for example, passwords that are only hashed and not salted or risk could break for us, but how do you do that? What does it look like? Same for something like intercepting unencrypted traffic. How do you actually do it? I want to go through and actually break the thing and then fix it and show everybody, OK, well, this is how in our favorite programming language we actually mitigate against these risks. And that's where the series came from.
CF: Can you give us a walk-through of the topics?
TH: Sure. There are 10 different vulnerabilities. We start out with injection. Injection may not only mean SQL injection for us. It might mean LDAP injection or any sort of query language injection where we can actually manipulate the execution of the query in a malicious way. So in a .NET world, we're looking at things like parameterized SQL. We're looking at Entity Framework or any other sort of ORM that breaks things down in parameters rather than allowing an attack that's like concatenating a query.
So number two, we go on to cross-site scripting. I think most people are probably pretty familiar with that. Keep in mind, these are in order of prevalence as well. So cross-site scripting is pretty prevalent.
CF: Cross-site scripting is what happens when somebody gets ahold of the JavaScript that's running in your browser when you click link x where you think it's going to take you, I don't know, to the next page or to the thing that you're reading, and it takes you to some website where some crazy stuff is installed. That happens mostly when you don't have a firewall. Can a firewall prevent cross-site scripting, or does it go through firewalls?
TH: No, it's not really a firewall thing. Cross-site scripting will hit you in a couple of different ways. So there's reflective cross-site scripting, where somebody will give you a link, and in sort of the classic cross-site scripting example, we say that link might have some JavaScript, which will execute on the browser or pop up in Outlook or something. That's just embedded in the URL simply because the application is taking that query string from the URL and writing it directly to the page, so an attack can actually start to control the markup or the JavaScript on the page.
CF: So it basically happens when a website gets hacked?
TH: Yeah, you can consider it a hack, but that particular cross-site scripting example doesn't necessarily mean any files on the server are being compromised or anything at all throughout that's being accessed. In fact, the app is really just doing what it was designed to do. It's taking input in the URL and putting it on the page. The other form of cross-site scripting is what you call a persistent cross-site scripting attack, where an attack actually gets marked up into the database -- which can then do a similar thing.
So number three out of the top 10 is a little bit generic: broken authentication and session management. Keeping in mind again that OWASP is pretty technology agnostic, if we put this in a .NET context, the sort of things that might lead us to broken authentication and session management might be things like rolling your own authentication system and not using the built-in membership provider. So a lot of the times when people try to create their own security controls, particularly when they're redundant with the really good ones that are built into the framework -- that can actually present a risk of a session being hijacked and other nasty things happening in the end. So what I've talked about in my writing is, hey, look, let's try and use as much of the goodness that's in the framework as possible. The membership provider gives us straight out of the box the ability to register, the ability to secure passwords as salted hashes, logon password raised. All this stuff is in there already.
CF: Right.
TH: The great thing about it is, not only is this a nice thing for security, it saves you a lot of time. You're in there, and you've got the whole thing up and running in five minutes, an entire membership authentication model.
Richard Campbell: But it's also strong. If you get a cross-site exploit, it now grabs your cookies successfully. They can't use it because it's salted. They've already done that in a membership provider.
