Boulder OWASP

Last night I presented at Boulder OWASP on the topic of web application security. The talk focused on ideas about enhancing the security of web applications; from addressing SPAM on simple contact forms to behavioral analysis of user requests for more sensitive applications.

The idea behind the talk touched on using the right tools for a given task and how the application is in the most logical position to make a decision based on user input. The talk weaved into a discussion of a tiered scoring system where suspicious requests equate to a higher score (null user agent, 40x server response codes, port scanning, input fuzzing, etc) and the higher the score the more aggressive the response becomes. I.E. Based on the behavior of a user, the application responds a certain way. An example with a contact form would be requiring a CAPTCHA if the the user agent is null and javascript is not enabled on the client. For a more sensitive application, like an online banking interface; profile authenticated users, establish a baseline and when deviations are detected, start locking down functionality or requiring additional forms of authentication. For this example, if the deviation is greater than X, then disable the wire transfer feature and/or prompt the user with an out-of-band question prior to allowing email address changes.

When profiling a user there is a common set of criteria that can be used and a more specific set of criteria based on elements of the application. The goal is to provide security commensurate with the sensitivity of the information being protected. Ideally this would come in a transparent form and like most ideal security situations this is a lofty goal.

An interesting conversation was brought up during this OWASP meeting as a question regarding a bullet point on one of the last slides: How to deal with username harvesting... on the account registration page. Thwarting harvesting on login and "forgot password/username" pages is doable but during the account registration process it is more challenging. Take Gmail for instance. When you sign up for a new gmail account the application essentially has to tell you that your requested username is available or already taken, since two people are not supposed to have the same email address.

One way to combat this vulnerability is to set usernames for the user; don't allow users to choose their own username. Depending on the application this "solution" can range from totally unacceptable (social networking websites) to expected (online banking websites). Remember that there are things in your control as an end user (setting a unique and complex password) and there are things that are entirely governed by the application (support for multi-factor authentication and support for complex passwords). Inconvenience vs security... It can be inconvenient to have an application set my username for me but if it prevents username harvesting is it worth it? The answer depends on the user-base, usability expectations, risk, perception, and supporting security elements.


I want to thank Applied Trust for hosting the event, Mark Major for putting it together and thanks to all of my friends and associates that were able to make it.

As usual with OWASP there were some excellent discussions and I think we all walked away richer for the experience.

Please feel free to download the slides here

Keep in mind that the bullet points tell about 37% of the story, audience participation and subsequent group discussion is where the meat and potatoes are at.