Learning Web App Security with Google Gruyere

I've been developing web applications for almost 10 years now, but I was rarely concerned with application security issues. To be sure, I am a defensive programmer, meaning that I do all kinds of checks on the inputs received by my functions, leaving very little to chance. But although I heard much about cross site scripting (XSS) and SQL injection, I didn't have a very clear understanding of these concepts. I relied on best practices (like parametrized database queries) and inherent ASP.NET features like request validation to take care of malicious inputs, be it form variables or query string parameters.

Yet I always had a gnawing feeling that I should get more understanding of web app vulnerabilities, attacks and defenses. So this month I started to look for way of how I can brush up on this important topic.

I found a couple of books, of which this one seems to collect a lot of praise from readers: The Web Application Hacker's Handbook (WAHH). I started to read the book, but I also wanted something more practical. I came across Open Web Application Security Project (OWASP) with its plenitude of resources and the famous OWASP Top 10 list of web app security flaws.

OWASP members also develop security software such as the security testing tool ZAP and the request intercepter proxy WebScarab. Both I really handy and easy to use.

OWASP has also produced WebGoat, a fictitious web application full of vulnerabilities that you can run and test locally on your PC. WebGoat has a number of lessons to teach about various security flaws that you can try to discover on your own with the help of some hints. Although a great resource, I found WebGoat somewhat lacking in the quality of their materials.

And then I stumbled upon Google Gruyere, which is a very elaborate web security code lab from Google Code University. It is much similar to WebGoat in that it gives you a sandbox to learn about and try to dicover security flaws in a Python web application that you can run either locally or online. It does a great job of explaining various security concepts and provides challenges to explore them in practice as well as guidance on how to guard against them. It is especially good at explaining the various flavors of XSS attacks, but it also provides a good foundation for understanding many other topics such as path traversal, denial of service and code execution. It touches upon but doesn't go into the details of SQL injection.



I've gone through the lab and thoroughly enjoyed the challenges and learned to use the tools like WebScarab and ZAP. I'd recommend it to anyone interested in web application security!

In parallel I did some security testing of the web applications that I've been involved with for the last year or so. I found that ASP.NET does a great job protecting ASP.NET applications from certain types of attacks out of the box. I found some minor flaws that are mostly due to relying too much on client side validation and forgetting to validate user input again on the server. A quite trivial example of this is being able to intercept a request and change the house number to a negative value. But I also discovered a more serious exploit using the same technique, which I will not describe here :)

The main lesson that I've drawn so far is that we should never trust input coming into our applications, be it through a web browser or a web API. Most security flaws in software result from sloppy programming. Web developers should be well aware of these issues and write their code defensively and test it thoroughly not only from the point of view of functionality but also security-wise.

To sum up, these have been very interesting and instructive few weeks. Web application security is a fascinating topic and I look forward to diving even deeper into it!

Happy coding!

ASP.NET debug="false" and line numbers in error stack trace

It's a good practice to always log run-time errors to a database table or a log file or both. It is also nice to have line numbers appear in the stack trace to be able to see where in your code the error appears. For some types of errors, e.g. for exceptions of type NullReferenceException, this is especially relevant as there is no other way to determine what went wrong.

In the past I had to deploy a debug build of the application and set debug="true" within the compilation section of web.config, in order to be able to see the line numbers in error logs. But this is not a good idea, as this adversely affects application performance (see this blog from Scott Guthrie for more details and this blog for even more details). So please, always set debug="false" in production environments. Or, even better, set deployment retail="true" in your production machine.config

But what do we do if we really want more detailed error information in our logs? There appears to be a an easy way to do this. In the properties of your project, in the Build section, select your Release configuration, click Advanced and make sure that Debug Info is set to pdb-only. This is equivalent to setting this compiler option: /debug:pdbonly in the compilerOptions attribute of the compiler element in web.config (for more details about this compiler option read this MSDN article and this blog article). This will emit your optimized release assemblies together with corresponding .pdb files containing all the information needed to reference files and line numbers in exception stack traces. You can then deploy the build output into your production environment.

This will allow you to log error details like line numbers without significantly affecting the performance of your compiler-optimized release assemblies. Warning: if you do this, then also please make sure that you don't set customErrors mode="off" so that you don't expose detailed exceptions to remote users (which is a wise thing to do from security standpoint!)

Happy coding!