Monday, May 24, 2010

Application Layer Intrusion Detection & Response

 Originally posted at OWASP.org as part of OWASP Top 10 Additional Risks to Consider

Today’s applications are responsible for securely performing critical operations for individuals and businesses around the world. From transferring money, to managing health records, web enabled applications handle immense amounts of sensitive data each day. Despite the critical role they play, the security defenses within these applications are seriously lacking. The attackers are organized, motivated, and backed by a network of resources and talent. If our applications have any hope of standing up to such formidable opponents, then we need to move beyond just attempting to design our applications securely We need to implement robust attack detection within the application to identify malicious users before they are successful in their attack. Just like in the real world, we would prefer to detect and prevent an attack instead of just responding after a compromise has occurred.
How do we bridge the technology gap to implement appropriate security controls in our critical applications? The first step is to realize that in order to detect and respond to malicious activity at the application layer we need to be able to monitor and understand a user’s actions within the application. Security approaches of previous years are not sufficient. A firewall provides no protection; its purpose is to allow users to access the application. Nor does a network based IDS system since it will have no insight to our application specific traffic. Antivirus is also out of the question since this is a signature based approach that knows nothing of custom web application vulnerabilities.
We need to move into the application layer to understand our attackers. One potential solution is a web application firewall (WAF). A WAF is able to detect generic application attacks such as basic SQL injection attacks or common actions of a known attack sequence. While some detection is better than none, a generic product could never fully understand the intricacies of each custom web application. This approach is just not sufficient to properly protect critical applications that process sensitive financial data or personal user information. Imagine trying to design an effective building alarm system without any knowledge of how the building is designed or even where the doors and windows are located.
The solution is to design and integrate a detection and response system into the application itself. Within the application we have a full understanding of the user initiating an action, the target of that action and whether that action should be allowed for that user. Inside the application our protection system can identify advanced attacks that are attempting to exploit specific features of our application. Within the application we can easily identify attempts to circumvent security controls or use the application in an unintended manner. After we have determined that a particular user has malicious intent and is attempting to identify weaknesses in our system, we can immediately respond and block the user from future access to the application, or take whatever other action is appropriate. Once locked out, such users can no longer login and are limited to attacking the perimeter of an application, which often contains limited functionality and is typically well secured. Alternatively, some organizations may wish to forego an automated lockout response and instead generate an attack alert and allow their security-monitoring center to perform an immediate investigation and decide upon the appropriate response.
The rigor of response is a decision for each organization in relation to their tolerance for risk and specific needs for an application. However, it is clear that this level of detection capability is a must for any organization wishing to prevent skilled and persistent attackers from compromising their critical applications.


OWASP AppSensor

OWASP is committed to the protection of applications through application attack detection and automated response. The OWASP AppSensor project has been established in response to the clear need for guidance and knowledge in this area.
AppSensor provides the following:
  • recommendations for what application actions should be detected as malicious along with suggested responses.
  • guidance on designing and implementing an attack detection and response system within an application
  • a Java reference implementation that you can integrate into your application as the basis for your Application Layer Intrusion Detection and Response mechanism
Find out more at: The OWASP AppSensor Project

-Michael Coates

Friday, May 21, 2010

Google search over HTTPS, +1 for the battle against HTTP

Google is beginning to support queries over SSL.  Although SSL does have its weaknesses, not using SSL is an instant fail for the user.  This is a step in the right direction.

https://www.google.com/

Google Online Security Blog: Extending SSL to Google search



-Michael Coates

Thursday, May 13, 2010

CSRF Attacks and Forged Headers

I'd like to start a discussion on current attacks using CSRF to forge HTTP headers.  The attack would go something like this:

1. Victim visits attacker's site with CSRF attack in page
2. CSRF attack fires causing victim to initiate a HTTP request to targetsite.com
3. Victim's browser sends off a request to targetsite.com and browser happily includes the session ID
4. Bad action occurs as designed by CSRF

The above is the classic CSRF flow. I'm curious about modern day attacks that would be placed in step #2 to allow the attacker to forge arbitrary headers that would be sent by the victim's browser (e.g in step 3).  For example, perhaps the attacker wanted the x-forwarded-for header to be added in the victim's HTTP request (step 3) and set to 127.0.0.1 (not sure why, just an example). Could he craft a CSRF to accomplish this?

In the past there were two ways to launch such an attack:
1. setHeader in Flash action script
2. XHR requests

However, each of these items have been locked down by the following:
1. setHeader in Flash action script --> crossdomain.xml policy
2. XHR requests --> Same Origin Policy restrictions

So, here is the challenge, what methods are currently available to launch such an attack?  Am I just missing something obvious or is this attack not well publicized.  If there isn't such an attack available, should we start relying upon custom headers to prevent CSRF attacks (my gut says no, but let's make a case against it).

Looking for feedback here and clever attacks.

*****
Edit: 5/27/2010
As you'll see from the comments, the same origin policy does hold up here and this attack is not possible. Headers can be relied upon to be free from tampering unless of course the primary site is compromised via some other method and used to inject the malicious XHR.

-Michael Coates

Monday, May 10, 2010

Most Secure Programming Language?

An interesting report was released just the other day by WhiteHat Security.  The study took a look at 1700 websites (all WhiteHat sentinel customers) and reviewed security bug metrics to identify patterns in security posture based on the programming language used for the site.  The overall conclusion, as mentioned by Jerimiah Grossman at the OWASP Bay Area meeting, is that there is not necessarily one language that is the "most secure".

I would agree with this overall conclusion. The elements that determine if an application is secure is far more complex than simply the language that has been selected.  However, I would argue that some languages are more conducive to organized and easy to manage code that follows an MVC approach. Similarly some frameworks provide security controls that are enabled by default to aid in the security of an application.  However, framework and language selection are meaningless if security is not baked in to the entire application life cycle.

Here are the three primary findings from the report.
  • Empirically, programming languages / frameworks do not have similar security postures when deployed in the field. They are shown to have moderately different vulnerabilities, with different frequency of occurrence, which are fixed in different amounts of time.

  • The size of a Web application’s attack surface alone does not necessarily correlate to the volume and type of issues identified. For example Microsoft’s .NET (ASPX) and Struts (DO), with near-average attack surfaces, turned in the two lowest historical vulnerability averages. ASPX and DO websites have had an average of 18.7 and 19.9 serious vulnerabilities respectively.

  • Perl (PL) had the highest average number of vulnerabilities found historically by a wide margin, at 44.8 per website and also the largest number currently at 11.8.ties have taken over 50 days to fix.

The full report requires registration and can be viewed here

Here is a rebuttal to some of the claims made by the report: http://pinvoke.wordpress.com/2010/05/06/faulty-math/
 
As mentioned in the above link I encourage you to take these results with a grain of salt.  The data is gathered from existing WhiteHat sentinel customers and is obtained from an automated tool (technically it is automated discovery with manual verification).  The sample population is not necessarily a reflection of the critical web applications at large, nor is an automated tool able to fully analyze the security of a site. In fact, automated tools are often strong in the areas of input injection based attacks and weaker in areas of authentication, access control, session management and custom logic flaws.

If you are going to take away one item from this study then I hope it is this: there is no magic bullet or super secure programming language. If you want something good then you have to work hard for it.  Security is a continuing effort that requires the support of everyone involed (dev, QA, managers, etc) and must be an essential component of each step of the SDLC.

-Michael Coates

Wednesday, May 5, 2010

Hands-On Web Hacking

The best way to really understand application security is to learn about the issue and then perform the attacks yourself.  You could go through the trouble of building your own vulnerable testing application or you could use one that has already been built specifically for that purpose.  Here are a few to check out:

OWASP's Webgoat
Language: Java
Lesson format with hints and detailed solutions

Google's Jarlesburg
Language: Python
Lessons? Don't know, haven't tried it. Feedback please!


OWASP's Broken Web Application Project
A vmware image of multiple vulnerable web apps designed for testing and learning. The VM image is complete with necessary tools for immediate attacking fun



The only tool you will need is a web proxy and a browser:
Burp, WebScarab, or Fiddler
 


-Michael Coates

Tuesday, May 4, 2010

TLS Podcast Available Now

I've been talking a lot about SSL/TLS recently.  If you haven't already, please check out the slides from my talk at Thotcon on SSL Screw Ups.

Just the other day OWASP released the 2010 Top 10. In addition, the OWASP podcast series released a slew of podcasts on the Top 10 items.  Included in this release was my talk on OWASP Top 10 item 9 "Insufficient Transport Layer Protection".  This podcast closely follows the OWASP Transport Layer Protection Cheat Sheet which was created as a single source of TLS knowledge and recommendations.


Listen now!

Note: This was recorded a few months back before I made the big switch to Mozilla.  Just a heads up to avoid confusion.

-Michael Coates