Chapter 7
Securing Your Application
What's In This Chapter?
- Requiring Login with Authorize Attributes
- Requiring role membership using the Authorize Attribute
- Using security vectors in Web Application
- Coding defensively
Securing your web applications can seem like a chore. It's something you have to do, but not a whole lot of fun. Nobody looks at your application and says, “Wow! Check out how well they secured my personally identifiable information! This programmer rules!” Security is generally something you have to do because you don't want to be caught in an embarrassing security breach.
No, security doesn't sound like a whole lot of fun. Most of the time when you read a chapter on security it's either underwritten or very, very overbearing. The good news for you is that we the authors read these books, too—a lot of them—and we're quite aware that we're lucky to have you as a reader, and we're not about to abuse that trust. In short, we really want this chapter to be informative because it's very important!
ASP.NET Web Forms developers: We're not in Kansas anymore!
This chapter is one you absolutely must read, because ASP.NET MVC doesn't have as many automatic protections as ASP.NET Web Forms does to secure your page against malicious users. To be perfectly clear: ASP.NET Web Forms tries hard to protect you from a lot of things. For example:
- Server Components HTML-encode displayed values and attributes to help prevent XSS attacks.
- View State is encrypted and validated to help prevent tampering with form posts.
- Request Validation (<% @page validaterequest=“true” %>) intercepts malicious-looking data and offers a warning (this is something that is still turned on by default with ASP.NET MVC).
- Event Validation helps prevent against injection attacks and posting invalid values.
The transition to ASP.NET MVC means that handling some of these things falls to you—this is scary for some folks; a good thing for others.
If you're of the mind that a framework should “just handle this kind of thing” — well, we agree with you, and there is a framework that does just this: ASP.NET Web Forms, and it does it very well. It comes at a price, however, which is that you lose some control with the level of abstraction introduced by ASP.NET Web Forms.
ASP.NET MVC gives you more control over your markup, which means you've taken on more responsibility. To be clear, ASP.NET MVC does offer you a lot of built-in protection (e.g. features like HTML-encoding by default using HTML helpers and Razor syntax, request validation). However, it is easier to shoot yourself in the foot if you don't understand web security—and that's what this chapter is all about.
The number one excuse for insecure applications is a lack of information or understanding on the developer's part, and we'd like to change that—but we also realize that you're human and are susceptible to falling asleep. Given that, we'd like to offer you the punch line first, in what we consider to be a critical summary statement of this chapter:
Never, ever trust any data your users give you. Ever.
- Any time you render data that originated as user input, HTML-encode it (or HTML-attribute -encode it if it's displayed as an attribute value).
- Think about what portions of your site should be available for anonymous access, and require authentication on the others.
- Don't try to sanitize your users' HTML input yourself (using a whitelist or some other method)—you'll lose.
- Use HTTP-only cookies when you don't need to access cookies via client-side script (which is most of the time).
- Strongly consider using the AntiXSS library (www.codeplex.com/AntiXSS).
There's obviously a lot more we can tell you—including how some common attacks work and what they're after. So hang with us—we're going to venture into the minds of your users, and, yes, the people who are going to try to hack your site are your users, too. You have enemies, and they are waiting for you to build this application of yours so they can come and break into it. If you haven't faced this before, it's usually for one of two reasons:
- You haven't built an application.
- You didn't find out that someone hacked your application.
Hackers, crackers, spammers, viruses, malware—they want into your computer and the data inside it. Chances are that your e-mail inbox has deflected many e-mails in the time that it's taken you to read this. Your ports have been scanned, and most likely an automated worm has tried to find its way into your PC through various operating system holes. These attacks are automated, so they're constantly probing, looking for an open system.
This may seem like a dire way to start this chapter; however, there is one thing that you need to understand straight off the bat: It's not personal. You're just not part of the equation. It's a fact of life that some people consider all computers (and their information) fair game.
Meanwhile, your applications are built with the assumption that only certain users should be able to perform some actions, and no user should ever be able to perform others. There's a radical disconnect between how you hope your application will be used and how hackers hope to abuse it. This chapter explains how to make use of the membership, authorization, and security features in ASP.NET MVC to keep both your users and the anonymous horde of attackers in line.
This chapter starts with a look at how to use the security features in ASP.NET MVC to perform application functions like authorization, then moves on to look at how to handle common security threats. Remember that it's all part of the same continuum, though. You want to make sure that everyone who accesses your ASP.NET MVC application uses it in the way you intended. That's what security is all about.