RSS Feed
« .NET StockTrader from MSDN: The new WebGoat? | Main | OWASP Boston Slides and SPF Public Demo Site »

Tamper Proofing Web Applications at Run-Time

Earlier this week we presented at the OWASP NY/NJ chapter meeting on "Tamper Proofing Web Applications at Run-Time". The talk presented some strategies and free solutions for protecting web applications from input driven attacks. The goal is to harden web applications so their non-editable inputs cannot be manipulated, which when left unchecked are a root cause of authorization bypass vulnerabilities such as parameter manipulation, forceful browsing, business logic flaws, etc. You can download the presentation slides here.

Non-editable inputs are those that end-users do not need to modify directly ' hidden form fields, URIs and QueryString parameters, cookies, etc. Traditional approaches to protecting this data ' black list and/or white list validation ' are insufficient as they cannot normally prevent authorization flaws within the context of a user's session.

Our talk demonstrated two freely available solutions that provide this type of protection for existing web applications without the need to modify the underlying application source code. In general, they both operate on the theory that the application should only permit users to perform those actions that the UI has rendered to them. The idea is to leverage HTTP responses at run-time to identify all legitimate requests (forms and links), collect the state of each possible request, and then validate subsequent requests against the stored state information. Specifically, we cover HDIV (HTTP Data Integrity Validator) for J2EE web applications and SPF (Secure Parameter Filter) for .NET web applications. The implementation details of each are discussed as well as related pros and cons.

You can download the presentation slides here.

Reader Comments (3)

HDIV, SPF, and mod_anti_tamper are so-so ok. They aren't that great.

I am still trying to find out why OWASP ESAPI is so superior to HDIV, but I guess I'll have to dig deeper into them myself.

As for the OWASP ESAPI projects, they appear quite great. They don't affect run-time from an operator's perspective. However, I don't really feel that operators should be touching or interfering with production applications outside of deployment. Run-time protections such as these are great for the lab, but they really don't belong in any production environment. Too many knobs and twiddles.

For Java, it is really easy to fix the code -- especially when you have a build server and continuous integration (there are hundreds of ways to do this right: have development pick one). Refactoring JEE code can be really, really easy with a nice development environment.

As for ASP.NET, it's a piece of cake with the Team Server stuff. Microsoft even recently updated their Anti-XSS libraries and made the" rel="nofollow">AntiCSRF module available. There are third-party tools such as ReSharper for easier refactoring, but VSTS is fairly decent when properly configured.

The presentation is kind of messy. I'd probably rather see this in person. Thanks for the links and have a happy holidays.

December 19, 2008 | Unregistered CommenterAndre Gironda

Hi Dre --

Thanks for your comments and Happy Holidays to you as well.

We agree that fixing the code is the preferred option and this is always our first recommendation; however after working with many enterprise customers we've learned the development effort required is not always feasible, practical, or unfortunately a high priority item. Additionally, if the application has never been audited or pen-tested, application owners might not be aware of the vulnerabilities (not to mention the possibility of a zero-day vulnerability). As a security professional, I would like to believe that every application will be audited and every security bug fixed, however that is probably not realistic. The approach and software modules we presented are primarily meant to protect against the "unknown" flaws within an application or to protect against "known" bugs where the code cannot be quickly fixed.

ESAPI should make it easier for developers to write more secure code, however like any other library or API, will only be as good as the developers who use it during development. We would love to see more organizations adopt ESAPI for new development projects and consider refactoring existing code to leverage it. Regardless, we believe in "defense-in-depth" and runtime protection (such as that provided by HDIV and SPF) can be a good compliment to secure programming practices (or a lack thereof).

As a final point, you mention the new version of Microsoft's AntiXSS and the AntiCSRF module. AntiCSRF is implemented as a HttpModule (and configured within the application's web.config file and does not require source code modification) and provides protection at deployment/runtime to new or existing applications. The newest version of AntiXSS can also now be used in a similar manner to provide runtime protection to existing applications using the new Microsoft's Security Runtime Engine (the most notable feature of the new version). Microsoft has likely caught onto the reality that if the only solution to fix a security problem involves re-factoring source code using a secure API (like AntiXSS 2.0), many developers will look for an easier solution. Check out" rel="nofollow">this post on SRE and the new AntiXSS, if you have not already. Again, it is more about dealing with the unfortunate reality that most developers will look for the easiest, cheapest, and least labor intensive solution. This reality is what drove us to investigate available (and ideally free) run-time protection mechanisms like HDIV and ultimately develop SPF.

The slides accompany our presentation and live demos of both HDIV and SPF in action. We'll let you know if we present on this topic at another venue so that you can hopefully attend in person.

December 22, 2008 | Unregistered CommenterJoe Hemler


Thanks for all of that great information. Hope your holidays were well; mine were great!

I was able to get some more information about SRE from a new SDL presentation on" rel="nofollow">Managing Cross-Site Scripting Using CAT.NET and AntiXSS.

While SRE is nice because it works on the outbound (for encoding), the authors even concede that the HttpModule will not work for DOM-based XSS or for things like Response.Write (or anything else outside of ASP.NET controls). While it's important to understand the strengths and limitations of SRE, I do find the project goes above and beyond most other concepts I've seen before - including the configuration tool that scans the code and determines what to do - in addition to advanced configuration through xml files.

All that aside, I guess I'm still worried about performance impact (addressed in the Q&A) and other issues (e.g. change control) this type of solution creates both short- and long-term for a production environment. I continue to stress the importance of sdlc process and bug fixes, regardless of majority rule and democratic business agility decisions.

January 11, 2009 | Unregistered CommenterAndre Gironda

PostPost a New Comment

Enter your information below to add a new comment.

My response is on my own website »
Author Email (optional):
Author URL (optional):
All HTML will be escaped. Hyperlinks will be created for URLs automatically.