Proactive WebAppSec

By Adrian Lane

Earlier this week rsnake blogged about the Top 10 Proactive Web Application Security Measures. He has a very good set of recommendations, a highly recommended read for web application developers and webmasters alike:

anti-CSRF cryptographic nonces on all secure functions: We recommend building nonces (one time tokens tied to user sessions) into each form and validating that to ensure that your site can’t be forced to perform actions. This can be a huge pain to retrofit because it means touching a database or shared memory on every hit – not to mention the code that needs to be inserted into each page with a form and subsequent function to validate the nonce.

DAL (data/database access layer): DALs help to prevent SQL injection. Few companies know about them or use them correctly, but by front ending all databases with an abstraction layer many forms of SQL injection simply fail to work because they are not correctly formed. DALs can be expensive and extremely complex to retrofit because every single database call requires modification and interpolation at the DAL layer.

What I appreciate most is that its recommendations are direct, development-centric responses to security issues with web apps. Unfortunately most companies don’t think critically and ask, “How should I solve this web security problem?” The more common approach is just to wonder, “What’s the cheapest, fastest way to minimize the issue?” That is not necessarily wrong, but that difference in mindset is why most customers go for bolt-on partial solutions, and it will probably prevent people from embrace these sound recommendations. Rsnake stresses that these ideas are best implemented before deployment, but I argue that agile web application development teams can still retrofit these ideas without too much pain.

I will drill into a few of these recommendations in coming posts, where I have been fortunate enough to have implement the ideas in previous companies and I can offer advice. A couple of his recommendations are far outside the norm. I am willing to bet you have never encountered database abstraction layers for security, and while you have probably heard of immutable logs and security frameworks in source code, you have probably never used them. That’s because you are probably using WAF, DAM, log management, and piecemeal SQLi protection. The depth of rsnake’s experience could fill volumes – he is pulling from years of experience to hit only the highlights – and these recommendations warrant more discussion. The recommendations themselves are really good, and the tools are not that difficult to build – the difficulty are in the management and deployment considerations.

No Related Posts

If you like to leave comments, and aren’t a spammer, register for the site and email us at and we’ll turn off moderation for your account.