After securing our server and configuration, we can move on to our application. ASP.Net comes in two flavors (soon to be three) flavors. Web forms, a.k.a. “Let’s pretend web programming looks a lot like Windows!” came first, MVC came next. Both have their strengths and weaknesses. Here we shall focus on both their weaknesses. That’s because our main application is a mix of both. We are a small shop, so refactors tend to move at a dignified (some might say glacial) pace. We replace pages one at a time, and often need to link a Web Forms page to a MVC page and vice versa. So, we have to watch both frameworks for bad guys. Enough prattling, on to the list.
Step 0. Authentication – This assumes you need to authenticate of course. Our application allows anonymous browsing of the login page and…. that’s about it. The application was originally written before forms authentication was released (yup, I am an oldster), so I came up with a ticket system that strongly resembles the flow of the aforementioned forms auth. When we integrated MVC, we adapted the application to use the same functionality via attributes on controller actions (yes, again, before authorize filters were released). In your case, if you have a choice, choose a built-in authentication method. You are super smart, I know. You are a crypto genius (me too!). That said, there are a lot of people using the tools that come with .Net. More eyeballs (allegedly) means defects surface quickly and can be corrected. Conservative choices are boring, but usually correct.
Step 1. Username and passwords – Please use generic error messages. If a login fails, do not tell the user why. Generic errors prevent systematic probing (as painful as it sounds). Progressively slowing down responses for failed logins also discourages bad behavior. Based on my user demographic, locking accounts is a last resort for me, but still a valid tool. Lastly, hash passwords. Do not make them recoverable. That’s just dumb.
Step 2. XSS – The most important thing in regards to defending again cross site scripting is to understand it. Once you understand it: encode, scrub, rinse, repeat. Use the built in tools at your disposal. Encoding is baked into MVC pretty well. There is the anti-xss library as well. If you can restrict your audience to modern browsers, check out the content security policy. Both Web forms and MVC provide request validation, make sure you are using it.
Step 3. CSRF – XSS’s ugly little brother. Slightly more straightforward to defend against.
Step 4. Session Hijacking – See Part 1, Step 5. SSL is your friend. Don’t be cheap.
Step 5. Denial of Service – I feel a bit helpless when it comes to DDOS. As a small shop with limited resources, it can be pretty tough to handle a DOS attack (we have never endured one, thankfully). The only meaningful action you can take is to limit your request size and make sure your public pages are performant. Logging (which you should be doing anyway) can help you trace the problem and maybe the attacker, but it is cold comfort in my opinion.
Step 6. SQL Injection – Use a SQL database? Use parameterized queries (and scrub your input). Don’t end up in a xkcd comic.
This checklist feels even more lightweight than the last one. I think all I have accomplished is giving myself an anxiety attack. Excuse me while I crawl under my desk and assume the fetal position.