Pages

Wednesday, February 23, 2011

I've created the OWASP Defenders Community as the first step towards a vision of OWASP I outlined the other day. John Wilander is leading the charge on the builders / developercommunity (and I just received an email from Thang Nguyen volunteering to lead the breakers community.

Check out the wiki page here. Note that this is a community. So if you want to be a part of this I highly encourage you to provide the basic bio information and picture as seen on the Community tab. You can upload the data yourself or send it to me (michael.coates@owasp.org)

Monday, February 21, 2011

These three posts provide very interesting insight about OWASP and some concerns in the community. Some individuals may view these discussions and think that OWASP is in trouble and is crumbling. I think that nothing could be further from the truth.The reality is that OWASP is growing by leaps and bounds. Community involvement is up, membership is up and projects are growing. We just held a fantastic summit that gathered the best security minds in the world. Sure, we have issues to address, but that is a result of our growth and our desire to be better. The fact that people are discussing how to make OWASP better points to the strong desire for OWASP to succeed.

Enough for talking without acting, here's how I think OWASP can grow to meet the new demands we are seeing.

Get the right people to the table. We have lots of consultants, let's increase enterprise/industry represenation

A shift from quantity to quality

Use OWASP as a platform for growth and support (as mentioned during the summit)

Do away with the notion of the board driving all decisions and direction. The board will assist and support everyone's efforts. But the people are the true drivers.

Here is a model that I think would be successful for OWASP. The focus is on building communities around builders, breakers & defenders (am I missing anyone?). The intent isn't for these groups to operate in isolation; instead the goal is to get the correct stakeholders united to address the key security issues that they are facing. Developers know what developers need and how development works. So let's get security minded developers together to address the issue. If they need information from the breakers or defenders, then just ask, we're all OWASP. Let's do the same for the breakers community and the defenders community. The intent is to drive security by getting the best people together to solve the right problems in areas where they are experts.

Moreover, within OWASP these groups should be champions of projects within their domain. No more half-baked or abandoned projects. Each community should be able to vouch for the quality of the projects in their area. If its not up to snuff, then fix it or cut it. Is a key project missing? Then develop a strategy and plan to fill the gap with quality material. If OWASP wants to succeed then we need to focus our efforts in the right areas and create high quality outputs.

One last thought, which is probably the most import, this model is all built on top of the OWASP platform. OWASP has a voice and is a gathering point for security excellence throughout the world. Let’s leverage this incredible community and focus our efforts for some truly awesome results.

Don't like this model? Then suggest something better. Talk is cheap; let's get some results.

Wednesday, February 9, 2011

Django and ruby on rails just released security updates (here and here) to address an attack that would allow CSRF through forged headers. Previously these two frameworks provided a CSRF defense for XHR requests that was based on the presence of the X-Requested-With header. The idea was simple, the header was automatically added during normal use of the XHR request by the user and an attacker was unable to spoof or forge a header in the context of a cross domain setting (e.g. CSRF attack). We discussed this a few months back and the consensus was that this approach was safe.

Apparently that has all changed. The details are currently very limited (or I just haven't found them). This is what is provided at the django and ruby on rails security update pages:

Recently, engineers at Google made members of the Ruby on Rails development team aware of a combination of browser plugins and redirects which can allow an attacker to provide custom HTTP headers on a request to any website. This can allow a forged request to appear to be an AJAX request, thereby defeating CSRF protection which trusts the same-origin nature of AJAX requests.

Michael Koziarski of the Rails team brought this to our attention, and we were able to produce a proof-of-concept demonstrating the same vulnerability in Django's CSRF handling.

I'm very curious to find out more. Is a proof of concept available? What browser plugins are required for this attack? The potential exposure must be large because both frameworks have released a "backwards-incompatible" patch.

This is technically backwards-incompatible, but the security risks have been judged to outweigh the compatibility concerns in this case.

We are working hard to advance the security of Mozilla web applications. This includes efforts such as threat modelling, security training, security throughout development, code review, testing, the bounty program, and more. In addition to secure development, we are also working to make our applications “attack aware”.

The idea behind an “attack aware” application is that the application is able to identify abnormal user actions that are not due to user errors, such as typos, and are instead the result of deliberate attacks against the application. The goal is to detect a malicious user probing for application weaknesses and disable their ability to cause damage to the system.

An “attack aware” application uses a blacklist style detection of a potential attack. It is important to realize that this is not intended to be a substitute for secure design principles. Instead, it is an additional detection capability layered on top of a securely designed application. Think of a bank that has been built securely and then installs an alarm system to detect attempted attacks.

The value of “attack aware” applications is in the correct selection of detection points that minimize false positives and effectively detects malicious activity. For example, detecting a single tick (‘) within a text field (which could be used for SQL injection testing) is a bad detection point since there will be many false positives with legitimate uses of that character (e.g. the name O’malley, or just typos).

An example of a good attack detection point is detecting malicious values within password reset token URLs (e.g. site.com/resetToken?k=abc ‘ OR 1=1;–). There is no reason a user would accidentally modify the URL to include a potential SQL injection attack. Therefore false positive rates are low and the likelihood of the user purposively attacking the application is high. This is only one example of the detection points we are using. The OWASP AppSensor research project provides numerous detection points and covers this topic in much more detail.

The next question is what should be done after an attack is detected? Currently we are monitoring attack reports from our attack aware applications. This data is all fed into a security integration manager that allows us to monitor trends and investigate individual attack reports. We are moving towards building a system that will enable us to selectively block the offending user from the application to prevent further attacks.

What about the bounty program? These additional defenses are slowly being rolled into our systems and we don’t expect any impact on the bounty program in the near future. However, when the time arrives one possible solution is to provide a mirror environment of bug bounty sites for security testing and enable the primary application with the attack aware capabilities and response options.