Eazy E Application Security

Your Cloud Provider is a Partner… Not a One-Night Stand

2012-09-18T08:09:00.000-07:00

“We programmatically interface with Cloud Providers to manage our customer data, so we can rely on them for securing our services right?” Wrong!

The moment you start interfacing with a Cloud Provider you immediately inherit the risks associated with their deployment, development, and security models – or lack thereof in many cases. However, you’re still responsible for the secure development of your business’s applications and services, but with the caveat that you are now sharing that responsibility with a Cloud Provider. Unfortunately, most Cloud Providers do not provide sufficient visibility into the maturity of security activities within their software development lifecycle.

Below we’ll take a brief walkthrough of a secure buy-cycle for a Cloud Provider and look at how you are affected by interfacing with Cloud Providers and what you can do to ensure consistent adherence to secure programming patterns and practices.

Gaining Visibility into Security Activities

Gaining visibility into the security posture of a Cloud Provider requires a large amount of discussion and documentation review. There are several common security activities that I look for when evaluating a Cloud Provider. If I were to evaluate your security capabilities as a Cloud Provider, some of my very first questions would be:

Do you centralize application security initiatives?

As a user of your Cloud Provider services, I need assurance that your development team and management staff is enabled by a centralized security team to produce fully secured products. Show me that you have a centralized security team or standards committee. I want to see a team that is responsible for defining application security practices and standards as well as defines and recommends security activities within the organization. Don’t run your application security program like the Wild-Wild West!

Do you enforce an application security-training curriculum?

As a user of your Cloud Provider services, I need assurance that your development team and management staff is aware of the latest security vulnerabilities and their mitigation strategies. Before you can begin addressing application security risks, your team needs to have an understanding of those core risks!

Do you facilitate secure development through automation?

As a user of your Cloud Provider services, I need assurance that your development team and management staff has the tooling necessary to streamline challenging security activities for quick remediation. This is simply a matter of scalability; humans alone are not a viable option for finding and fixing every problem in your codebase. Technologies such as Static Application Security Testing (SAST) and Dynamic Application Security Testing (DAST) help scale code review and penetration testing solutions by focusing on a common set of application security problems while additional human-resources apply more specialized techniques to the business contextual components of your services.

I do not want to hear that you “perform penetration tests on a yearly basis using a 3^rd party firm and or 3^rd party tool.” This type of process is not continuous, does not enable developers, does not scale and leaves too many open problems.

Do you have incident response for dealing with security vulnerabilities?

As a user of your Cloud Provider services, I need assurance that you have a process in place to respond to vulnerabilities identified in production applications. I’m looking for a standardized process that is well understood by the key stakeholders in your business and the applicable business unit.

Show me the turn-around time for fixing vulnerabilities. Give me an understanding of compensating controls used to reduce exposure of exploitable vulnerabilities. Most importantly, show me who did what, when, and how. I cannot make educated and well-informed decisions for my business if you do not provide me with enough information from your end.

How do you ensure confidentiality and integrity of sensitive data?

As a user of your Cloud Provider services, I need assurance that you have sufficient controls in place to protect my sensitive data throughout the service lifecycle. Tell me the protections you have in place when sensitive data is being entered into the application, when the sensitive data is transmitted across the wire, when the sensitive data is at rest, and when the data is presented to end users.

Key security controls that I am looking for in this regard include using FIPS 140-2 compliant cryptographic modules, masking of sensitive fields, use of Transport Layer Security (TLS) for network transmission, use of strong encryption and message digest algorithms for persistence, and a key management strategy that incorporates key rotation and processes to minimize disclosure. The last thing I’d want is you storing the cryptographic key in a database column adjacent to the encrypted data!

How can my team make use of your services securely?

As a user of your Cloud Provider services, I need assurance that my development team will have all the support they need to systematically interface with your exposed API in a secure fashion. Show me clear and concise documentation of the security features and security characteristics of your exposed functionality. My development teams need to understand your authentication and identity management workflow along with guidance on how to manage those identity tokens.

My development teams also need to understand any security relevant assumptions you place on your exposed API. For example, are you expecting my development team to verify the user is authorized to access a database record by querying the UserEntitlments endpoint prior to querying the DatabaseRecord endpoint? Or have you encapsulated the authorization logic within the DatabaseRecord endpoint so that my development team only has to make one API call? I definitely don’t want to be responsible for disclosing my users’ information because you did not provide me guidance on how to securely interact with your service.

Verify Security Claims and Assertions

While simply hammering your potential Cloud Provider with application security questions like the above helps provide visibility into their security posture, it in no way verifies that they’re doing what they claim. In an ideal partnership, it is prudent for you to require your potential Cloud Provider to “get tested” by an application security team before moving the relationship forward. Whether an internal team or a 3rd party carries out the assessment, the goal of the effort would be to gain confidence that the Cloud Provider is properly adhering to and implementing their security claims and assertions.

The assessment should cover not only a code review and penetration test of the target services, but should also evaluate the capability of the Cloud Provider to implement their security activities throughout their Software Development Lifecycle. Use the vulnerabilities from the code review and penetration test to assist in the evaluation of their security activity effectiveness. Ask them:

What vulnerabilities in this report are known and unknown?
How long have you been working on remediating the known?
Why do you believe the unknown were not previously identified?
How long will it take to fix these vulnerabilities?

You can roughly estimate what security activity failed based on evidence from a combined code review and penetration test. If the vulnerabilities indicate a complete lack of security control(s), then there is likely a serious problem with the Cloud Provider’s planning and requirements phases. If the appropriate security controls exist but were not used correctly or there are various implementations of the same security control, then there is likely a problem in the design and implementation phases. If the vulnerability is substantial and was unknown, then there is likely a serious problem with the Cloud Provider’s secure coding enforcement strategies. Finally, if the vulnerability is substantial and known for an extended period of time, then there is likely a serious problem with the Cloud Provider’s incident response strategies.

Conclusion

There is a very common problem facing consumers of Cloud Providers today; they simply fail to dig deep enough in the selection process and settle for what looks good on the surface – a surefire way to build a short-lived relationship. You must realize that you inherit the risk of your Cloud Provider the moment you leverage their services. The risks are further compounded when sensitive information is passed through these Cloud Provider services. When you evaluate your future Cloud Providers, ensure that you gain visibility into their application security activities and you verify security assertions and claims through penetration tests and code reviews. After all, your Cloud Provider is a Partner… not a One-Night Stand!

Simulating Model View Controller

2012-07-25T10:50:00.000-07:00

Sitting here at Black Hat USA 2012, it seems appropriate to write up another technical static analysis post. I’m coming off a night of drinks with some friends at Accuvant Labs, so you can rest assure that I’m moving a little slowly this morning…

We last left off with a discussion about method propagator rules and how they facilitate the static analysis engine’s ability to model the propagation of untrusted data across keyed collections. One of the core use cases for this rule type was the need to more correctly propagate untrusted data across session objects. With this functionality in place, at WhiteHat we can begin thinking about how to simulate the Model-View-Controller architecture utilized by many popular Web frameworks such that Sentinel Source can propagate untrusted data placed in the session by the Controller and the corresponding retrieval of said untrusted data from the session by the View. Simulating this workflow through static analysis better enables Source’s ability to identify Cross-Site Scripting vulnerabilities in modern Web applications.

The first challenge is simulating how an application transfers the execution of the application from the Controller to the View. For simplicity sake, let’s consider an application that makes use of the Struts 1.x MVC framework. In Struts, the developer modifies a configuration file to declare an Action that acts as the Controller. For each Action, the developer can declare one or more JSP files representing the corresponding View. Struts will transfer execution to these JSP files after executing the corresponding Action.

The WhiteHat Sentinel Source static analysis engine will programmatically locate and consume Struts configuration file(s) to identify what Actions are exposed and to which JSP files they transfer execution. Source then locates the corresponding source code and marks each Action with Runtime Binding Rules instructing the engine to immediately jump to one or more JSP files after simulating the execution of said Action. The fine grain details of Runtime Binding Rules are outside the scope of this post and will be discussed in later entries. For the purpose of our discussion, just note that Runtime Binding Rules augment control flow graph traversal necessary for modeling this MVC application.

Let’s walk through the workflow a bit using code snippets from a sample Struts 1 MVC application that WhiteHat used as a test case during development. The application’s struts-config.xml file contains an Action declaration as follows:

 1.   <action input="/index.jsp" name="HelloWorldActionForm" path="/HelloWorld" scope="session" type="com.vaannila.HelloWorldAction">  
 2.     <forward name="success" path="/helloWorld.jsp" />  
 3.   </action>

The engine will consume this declaration and notice exposure of the “com.vaannila.HelloWorldAction” Action class and the fact that it forwards to “helloWorld.jsp” upon completion. The Sentinel Source static analysis engine will locate the method declaration corresponding to the HelloWorldAction class that is invoked by Struts and use this as the starting point for call graph traversal. The found method declaration is as follows:

 1.   public ActionForward execute(ActionMapping mapping, ActionForm form, HttpServletRequest request, HttpServletResponse response) throws Exception {  
 2.      request.setAttribute("name", request.getParameter("name"));  
 3.      
 4.      HttpSession session = request.getSession(true);  
 5.      session.setAttribute("name", request.getParameter("name"));  
 6.      session.setAttribute("message", ((HelloWorldActionForm)form).getMessage());  
 7.      
 8.      response.setHeader("message", ((HelloWorldActionForm)form).getMessage());  
 9.      return mapping.findForward(SUCCESS);  
 10.  }

There are several lines of interest and even a couple vulnerabilities within this code snippet alone. However, let’s focus our attention on the ActionForm variable declaration and the corresponding invocations on line 6. As a result of one or more rules found in our Apache Struts RulePack, the Sentinel Source static analysis engine will mark the ActionForm variable declaration instance as a source of untrusted data. This means that the invocation of all getters containing corresponding setters will return untrusted data for this specific instance.

Moving forward, we see that the developer sets the “message” session attribute to the value of ((HelloWorldActionForm)form).getMessage(). This line triggers a method propagator rule ensuring that subsequent calls to retrieve the “message” attribute from the session will return untrusted data. However, the session object extends beyond the scope of this method and is accessible to other classes and methods such as JSPs. In order to compensate for this increased scope, Source marks the method propagator rule as “global” instructing the engine to maintain untrusted data propagation references beyond the scope of the method.

Once the engine is finished traversing the method, it will immediately jump to the “helloWorld.jsp” file to begin traversal. Source’s static analysis engine carries over the untrusted data propagation references associated with the session’s “message” attribute and associates it with corresponding session instances in the underlying JSP. Consider the following code snippet from helloWorld.jsp:

 1.   <h1><bean:write name="HelloWorldActionForm" property="message" filter="false"/></h1>  
 2.   <h1><%= request.getAttribute("name") %></h1>  
 3.   <h1><%= session.getAttribute("name") %></h1>  
 4.   <h1><%= session.getAttribute("message") %></h1>

We notice that on line #4 the JSP retrieves the contents of the “message” session attribute and displays it directly on the page. This is a perfect receipt for Cross-Site Scripting and is subsequently caught by the engine. If you were paying close attention, you may have noticed that in fact all 4 lines above result in Cross-Site Scripting all of which are identified by the Sentinel Source static analysis engine today.

The command line output of the trace signifying this vulnerability looks as follows:

 (6) Injection.Net.Http.Body (2) (Severity:Medium) (Confidence:High)  
      web/helloWorld.jsp (16) Sink (Sink.Net.Http.Body)  
      src/java/com/vaannila/HelloWorldAction.java (39) Propagator  
      src/java/com/vaannila/HelloWorldAction.java (34) Source (Source.Net.Http.Parameter)

The HelloWorldAction.java class contains a source of untrusted input on line 34 that comes from the HTTP request (i.e. “ActionForm form”). Line 39 propagates that untrusted data via the session set attribute call (i.e. session.setAttribute("message", ((HelloWorldActionForm)form).getMessage());). The application then retrieves the contents of the “message” attribute and displays it to the user without encoding on line 16 of helloWorld.jsp (i.e. <%= session.getAttribute("message") %> ).

Simulating Model-View-Controller patterns should be viewed as a core requirement for today’s static analysis technologies. Static analysis technologies that cannot properly simulate this programming pattern will ultimately miss a lot of vulnerability classes that can and should be identified by a tool. Be aware of technologies that try to overcompensate for this weakness via overly broad assumptions and rules that ultimately produce an overwhelmingly large set of false positives.

This article just scratches the surface of the capabilities within Sentinel Source’s static analysis engine. Method propagator rules are a critical component to pulling off the simulation of MVC as they allow us to propagate across keyed collections and maintain untrusted data propagation references across method declarations. While there are slight variations depending on the technology, this basic strategy can be applied to all MVC frameworks including Struts 1, Struts 2, and Spring MVC.

Phew… That post was a bit long but hopefully it was technically interesting! Alright, time to get back to the normal Black Hat way of life – drinks anyone?

WhiteHat Sentinel Source is Born!

2012-06-11T11:07:00.004-07:00

June 1st 2012 was the official one-year mark since WhiteHat Security and Infrared Security decided to join forces to create WhiteHat Sentinel Source. After a significant amount of hard work from a lot of great people, WhiteHat Sentinel Source has gone public! I’m going to use this opportunity to write up a bit of a nostalgic blog post… while still keeping my Don Draper game face on of course. Having been an application security consultant for years, I’ve developed a pretty big chip on my shoulder as it relates to existing static analysis tools. I said to myself time and time again… “There has to be a better way to do this!” I put that energy to good use and infused our technology and service offering with the following core static analysis values that truly separate WhiteHat Sentinel Source from the competition:

1. Invest in Performance:

In order to support an Agile-paced development world, performance of both scan time and verification turnaround time are critical to success. We are constantly investing in our core technology and processes to ensure we get the fastest turnaround time possible!

2. Support Modern Programming Paradigms:

Development teams have adopted various modern programming paradigms and technologies that throw existing static analysis tools for a loop. Such paradigms and patterns include: Object-Oriented Programming, Aspect-Oriented Programming, Inversion of Control, Dependency Injection, etc. We are constantly striving to ensure that our technology has the ability to support these paradigms to accurately model modern source code!

3. Strive for Actionable Results:

Reviewing 100+ “findings” is a complete burden and dilutes the value of the technology. We are striving for quality over quantitythroughout our core engine and RulePack development processes! “No grep-like rules” is something you’ll hear me say frequently.

4. Provide Feedback Early:

Performing source code scans at the end of a development initiative or even when the project distributable can be built is too late! Teams are constantly requesting feedback during the development phases, not at the end. We are constantly striving to ensure our ability to integrate with source code repositories such that we can provide feedback early in the development phase. This coupled with our core technology performance makes daily scans a possibility!

5. Leave Security to Security:

Putting a large static analysis report in front of a developer expecting them to triage and fix the results is a complete waste of time and energy. We are constantly striving to ensure that we enable developers to more effectively remediate significant vulnerabilities by performing the triage ourselves.

While the success of WhiteHat Sentinel Source is attributable to many individuals, there are a few folks who really stand out:

Jerry Hoff (VP, Static Analysis Division):

Jerry is an incredibly well-rounded application security expert and a long-time friend. Jerry played a critical role in disseminating our static analysis strategy to the rest of the team and really bootstrapped our ability to talk about static analysis in a way that actually makes sense to people. I always thought I had a great ability to make application security topics digestible until I met this guy. Very much a forward-thinking person, I refuse to have strategic discussions without his input. Jerry has been helping me push static analysis since day 1 at Infrared Security. We would have not even gotten half this far without his efforts… thank you Jerry!

Siamak Pazirandeh (Senior Software Architect):

Siamak is an incredibly talented developer, architect, and leader. The benevolent development dictator, Siamak (a.k.a. Max) was responsible for spearheading the integration of static analysis into WhiteHat’s existing DAST service model. This large effort involved designing and building a persistency model for evolving codebases optimized for the purpose of verification, scalability design, service delivery architecture, middleware integration, and overall project leadership. He’s already solved challenges with DAST, why not solve SAST too… thank you Max!

John Melton (Senior Application Security Researcher):

John too is an incredibly well-rounded application security expert with serious technical depth in Java. With his astounding work ethic, attention to detail, and everlasting pursuit of perfection, John Melton has become the lead of the Sentinel Source Java engine and RulePack R&D. His abilities and core values around product development provide me with the confidence I need so that I can focus energies on other development initiatives. He is also one of fewer than five people in the world who can very directly and bluntly call me out on my mistakes without me feeling insulted. I think it has to do with his southern accent… thank you John!

With the core technology in place and our integration with the Sentinel interface, WhiteHat Sentinel Source is ready! We fully intend to shake up this market and will continue to push forward with real innovation. We are making the pledge to strive for accuracy, timeliness and usability with our solution. We look forward to other vendors stepping up to our plate… competition will only make us work harder!!

Keyed Collections and Propagation, PI.

2012-06-05T09:05:00.000-07:00

I’ve been asked several times now about how the static code analysis engine that I’ve been driving and developing for WhiteHat Security’s upcoming Static Code Analysis solution deals with the propagation of untrusted data across keyed collections. If you’ve ever leveraged a pre-existing static analysis tool during a security code review, then you’ve most likely run into one or more “vulnerabilities” which highlight a code snippet that looks similar to the following:

1.  public class HelloServlet extends HttpServlet {
2.  
3.       public void doGet(HttpServletRequest request, HttpServletResponse response) {
4.            HttpSession session = request.getSession(true);
5.            session.setAttribute(“name”, request.getParameter(“name”));
6.            session.setAttribute(“label”, “Eric Sheridan is a ‘Mad Scientist’”);
7.  
8.            Statement statement = createStatement();
9.            statement.execute(session.getAttribute(“label”));
10.      }
11. }

There are a couple of “vulnerabilities” that the old-school static analysis tools would flag with this code snippet. The first “vulnerability” is that setting a session attribute to the value of an HTTP parameter without validation is a “trust boundary violation.” The idea is that developers implicitly trust the values retrieved of the HttpSession object, thus we must take care to properly validate data placed in the collection.

Okay, the subject matter expert in me agrees and feels this is very much a best practice – but a vulnerability!? No way. I can’t imagine presenting that as a vulnerability to the financial institutions I deal with on Wall Street. Those folks are sharp as hell and would tell me to get out of the room. While I like the best practice, this always felt like a marketing excuse as to why the tool couldn’t propagate across keyed collections… let’s take a look at that problem.

The second “vulnerability” that would probably be flagged in this code snippet by an old school static analysis tool is line 9:

statement.execute(session.getAttribute(“label”));

Since the static analysis tool has no way to know if the “label” attribute in the HttpSession object is tainted, it assumes EVERY value in the HttpSession object is tainted – i.e. the entire HttpSession object is marked as a source of untrusted data. This has led to thousands of ridiculous findings over the past several years and is one of the many reasons why the application security community has a serious chip on their shoulders as it relates to static analysis.

Having been an application security consultant for years, I’ve experienced this hell and refuse to let my users experience that whirlwind of pain again. The static code analysis engine for which I've led development supports a rule type called a “method propagator rule” that is designed to propagate untrusted data across two specific methods of an object based on various criteria, one of which is a keyed value. WhiteHat’s internal team of RulePack developers use this rule type to ensure that if we see a call to javax.servlet.http.HttpSession.setAttribute and the second argument is tainted, then the call to javax.servlet.http.HttpSession.getAttribute returns untrusted data if and only if the first argument to both methods (i.e. the key) is contextually the same.

If you have experience in the static analysis space, you’ll quickly realize that this is not just simple taint propagation: we’re working with much more rich propagation models than others. The trick to pulling this off is calculating the key associated with the setAttribute and getAttribute method invocations. Our calculation produces a signature that attempts to identify a consistent pattern between the setAttribute and the corresponding getAttribute. As long as the pattern is consistent, we can propagate across the keyed collection. Take a look at the following examples to help illustrate the approach I’ve developed which is to be used in WhiteHat’s Static Code Analysis solution:

Example #1: Consistent use of the string literal “eric” – SUCCESS!

session.setAttribute(“eric”, request.getParameter(“test”));
statement.execute(session.getAttribute(“eric”));

Example #2: Consistent use of the field Fields.NAME – SUCCESS!

session.setAttribute(Fields.NAME, request.getParameter(“test”));
statement.execute(session.getAttribute(com.company.Fields.NAME));

Example #3: Consistent use of the invocation getProperties().getName() – SUCCESS!

session.setAttribute(getProperties().getName(), request.getParameter(“test”));
statement.execute(session.getAttribute(this.getProperties().getName()));

The conclusion here is that we can propagate across keyed collections such as java.util.Map and javax.servlet.http.HttpSession automatically without any sort of user intervention. We are finding that this strategy significantly reduces false positive rates and produces more actionable results for developers. Pretty cool, huh? As you can infer from the title, this is only Part I of a multi-part series. Want to take this to the next level? How about propagating values in keyed collections from a Struts controller to the correct Struts JSPs? MVC anyone? … Stay Tuned!

WhiteHat Sentinel Source Beta Released!!

2012-04-06T10:00:00.005-07:00

Well, its been almost a year since Infrared Security and WhiteHat Security decided to join forces to design, implement, and deliver a static code analysis solution that actually works! After a significant amount of hard work from a lot of great folks, our solution turned Beta on April 4th, 2012… and man do I feel like a proud parent! Oh, and what’s the name of that solution you ask? WhiteHat Sentinel Source!

WhiteHat Sentinel Source makes use of an advanced static code analysis (SCA) engine that is capable of modeling and analyzing applications developed using modern programming paradigms for security vulnerabilities with extreme accuracy, speed, and precision. Modern programming paradigms that frequently cause challenges for other technologies yet are in the powerhouse of our engine include Object Oriented Programming (more specifically – efficient traversal of multiple concrete implementations for method invocations), Aspect Oriented Programming, Dependency Injection, Inversion of Control, Dynamically Typed Languages, and more! In addition, the core SCA technology acquired from Infrared Security makes use of the patent pending “Runtime Simulation” technology allowing for more accurate and more efficient traversal of source code. Our bleeding edge technology provides the performance and turn-around time that will allow us to be the first static analysis vendor to truly support the fast paced world of Agile development shops! Want some proof? How about a scan of 1.5 million lines of code taking 25 minutes and producing ~150 high confidence vulnerabilities!

An equally exciting piece of WhiteHat Sentinel Source is our overall delivery model. We are the first to provide our customers with the ability to integrate a static code analysis solution within their own source code repositories in a way that allows us to provide insight into the security posture of their applications throughout the evolving development lifecycle… without the need to completely compile and or run the application! As soon as you start committing code and scheduling scans, we can start providing feedback! A really cool part of this decentralized model to static code analysis is our leveraging WhiteHat Security’s proven ability to verify vulnerabilities before they are delivered to the client. While our static code analysis is extremely accurate, we will reach a whole new level with the verification of our results by the Threat Research Center (TRC)!

I’ve had my blinders on for over a year focused on the development of this static code analysis solution. Now is the time to take off those blinders and start sharing with the world the cool research and advancements we are making in the space of static code analysis. Over the next several months, I will be discussing those key technical and process advancements and differentiators that will really make us stand out as a visionary company!

So if we haven’t met before, my name is Eric Sheridan – Chief Scientist of Static Code Analysis… good to meet you!

Hey Django and RoR - How About Some CSRFGuard Love!?

2011-02-09T15:59:00.000-08:00

You caught me in the middle of my usual end of day routine, Django and Ruby on Rails. You dynamic scripting languages with your progressive thinking... your speed of development... your general distaste for static compilation and dependency injection... you snarky devils.

An OWASP buddy of mine, Michael Coates, recently posted about how attackers could bypass CSRF prevention controls for Ajax requests within these popular frameworks (here and here). These frameworks look for the presence of the X-Requested-With header in the HTTP request to determine if it was sent using XMLHttpRequest. If this header was sent, the frameworks would not check for the existence of the CSRF prevention token. The idea was that attackers could not use XHR nor forge the X-Requested-With header in browsers without breaking the Same Origin Policy (SOP).

Well, it turns out some security researchers were able to spoof the X-Requested-With header using "a combination of browser plugins and redirects". THIS IS EXACTLY THE SORT OF THING I PREDICTED WOULD HAPPEN! Too many caps? Perhaps... but you probably use lower case too much. Anyway, this once again confirms my statement that the browser is a hostile environment!

What makes this news more interesting is that their proposed solutions do exactly what CSRFGuard 3.0 ALPHA already does!! These frameworks are now hooking calls to the JavaScript XMLHttpRequest object to ensure that a custom header name value pair containing the CSRF prevention token is sent with every Ajax request. The server-side code will only process the Ajax request if the CSRF prevention token was sent in the header or as a parameter. Mileage may vary - but thats the gist of it!

What to see what the CSRFGuard JavaScript code looks like?? Check it out here!!

The thing that actually annoys me? No mention of CSRFGuard anywhere on the aforementioned sites! How about some freaking love over here!? If you use CSRFGuard in your applications or as a reference implementation for other environments, let me know! We at OWASP put in a lot of work to make these solutions available. Letting the author know you leveraged there work in some way is a very gratifying feeling!

This all assumes, of course, that Django and RoR used CSRFGuard as a reference implementation. If they didn't and re-invented this strategy all on their own, then shame on you guys for not using Google and OWASP! Having to unknowingly re-invent the Ajax CSRF prevention strategy wheel was probably punishment enough.

So check out the OWASP CSRFGuard Project! Version 3.0 is currently ALPHA and is in need of more testing. Please support the project!!

Ok... back to my usual end of day routine.

How CSRFGuard Protects Ajax

2010-12-23T09:30:00.000-08:00

There have been several discussions on web application security mailing lists and blogs about the best strategy to protect Ajax interfaces from Cross-Site Request Forgery (CSRF) attacks. Most of these discussions center around verification of the X-Requested-With header or adoption and subsequent verification of the Origin header. I thought now would be a good time to talk about how OWASP CSRFGuard v3 protects Ajax interfaces from CSRF attacks. It is important to note that CSRFGuard v3 is still in development. Now is a great opportunity to test and provide feedback!

Most if not all of the hard work to project Ajax is done through the dynamic JavaScript code generated by JavaScriptServlet. The first thing this script will do is determine if it was referenced from HTML that was served by the same domain or sub-domain that hosts JavaScriptServlet. This check is intended to help mitigate the risk of JavaScript hijacking; a topic of which is reserved for a separate blog post. If the HTML was produced by our domain, CSRFGuard's JavaScript code will dynamically hook the XMLHttpRequest object with the goal of intercepting the "open" and "send" events. This is rather trivial in browsers that properly support the prototype properties of JavaScript objects, such as Firefox and Chrome. Consider the following code snippet found in the "hijackStandard" function:

XMLHttpRequest.prototype._open = XMLHttpRequest.prototype.open;
XMLHttpRequest.prototype.open = function(method, url, async, user, pass) {
this.url = url;

this._open.apply(this, arguments);
}

XMLHttpRequest.prototype._send = XMLHttpRequest.prototype.send;
XMLHttpRequest.prototype.send = function(data) {
if(this.onsend != null) {
this.onsend.apply(this, arguments);
}
this._send.apply(this, arguments);
}

This code makes use of JavaScript specific function hijacking techniques to hook the "open" and "send" methods. The original copy of both "open" and "send" are stored in an instance variable starting with an underscore followed by the original method name; "_open" and "_send" respectively. Whenever client-side JavaScript invokes the "open" method of XMLHttpRequest, our code will store a copy if the target URL and invoke the original method. We make a backup of the target URL for use at a later point in our code. Whenever client-side JavaScript invokes the "send" method of XMLHttpRequest, our code will invoke the "onsend" event. This is a custom event that is defined by CSRFGuard and allows for the augmentation of the request before it is sent out over the wire. We will see later in the JavaScript code how this "onsend" event handler is used to inject custom headers into the request.

Hooking the XMLHttpRequest object in Internet Explorer, however, is not so trivial. Attempting to run the above code in Internet Explorer would choke at the "this._open.apply" and "this._send.apply" method invocations, complaining that they do not exist. After banging my head against the desk and taking a break to watch Hackers, I decided to do this Zero Cool style and hook the entire XMLHttpRequest object. This required defining my own XMLHttpRequest object coupled with all corresponding constructors, properties, methods, and events. All of this logic is encapsulated within the "hijackExplorer" function. At the end of the day, this code hooks and exposes the same capabilities as the aforementioned code in Firefox and Chrome. Hey Microsoft JavaScript guys, please tell me there is an easier way!?

With the hooks in place and the "onsend" event exposed, we can inject our custom CSRFGuard logic within every XMLHttpRequest object. Our augmentations to XMLHttpRequest should be the inclusion of two header name value pairs for all requests sent to our domain or optionally our sub-domains. Verification of the destination URL before inclusion of the headers is intended to reduce the risk of sending the token offsite as a result of future browser vulnerabilities as well as any existing or soon to exist leniencies in the XMLHttpRequest and Cross-Origin specifications. Consider the following code snippet from the dynamic JavaScript code:

XMLHttpRequest.prototype.onsend = function(data) {
if(isValidUrl(this.url)) {
this.setRequestHeader("X-Requested-With", "%X_REQUESTED_WITH%")
this.setRequestHeader("%TOKEN_NAME%", "%TOKEN_VALUE%");
}
};

If the request is sent to our domain or optionally our sub-domains, then we will inject the "X-Requested-With" header with a configurable value coupled with a custom header name value pair. The custom header name value pair is actually the same CSRF prevention token name value pair that is injected in forms and links. When CSRFGuard receives the request on the server, it will check for the presence of the X-Requested-With header. If supplied, CSRFGuard will then verify that the custom header name value pair exists and the token value is correct for the current session. If no X-Requested-With header is supplied, then CSRFGuard will default to analyzing HTTP parameters for the presence and validity of the CSRF prevention token. Note that CSRFGuard will only make use of the per-session token model as opposed to the per-page token model for Ajax requests. I have not yet figured out a clean solution to support per-page tokens within Ajax requests which would not either break application functionality or increase network traffic two-fold.

CSRFGuard only uses the X-Requested-With header to determine if the request was sent by Ajax. In theory, the X-Requested-With header indicates use of XMLHttpRequest which is bound by the Same Origin Policy (SOP). An attacker cannot send XMLHttpRequests to our origin when served from a separate origin. As a result, many developers simply check for the presence of this header as a defense against CSRF attacks. Now I'm an extremely realistic, or paranoid, person - the browser is a hostile environment! In an effort to reduce my trust in the browser's ability to properly enforce the Same Origin Policy and prevent unauthorized specification of HTTP request headers, I've decided to include the custom header name value pair. If an attacker is able to somehow send an XMLHttpRequest across origins and or specify arbitrary HTTP headers, then they would still need to know the victim's CSRF prevention token for the attack to fire. Now that's defense in depth!

There is a bit of a movement going on around adoption of the "Origin" header to help defend against CSRF attacks. However, I am skeptical. The wording use in various presentations and papers around this topic seem to imply that the Origin header should only be sent in POST requests and not GET requests. Clearly, these are not the people who actually work closely with enterprise level developers and applications. Let me make this very clear - most modern and almost all legacy web applications will gladly process the same POST request as a GET request! Until the specification becomes more mature and address more realistic technical aspects of CSRF prevention, you should be sticking with the synchronizer token pattern in one form or another.

-Eric

OWASP CSRFGuard 3.0.0.336 (ALPHA) Released!

2010-12-15T17:05:00.000-08:00

It is with great pride that I announce the release of OWASP CSRFGuard 3.0.0.336 (ALPHA)! This is a development release of the v3 series that is in need of peer review, testing, and general feedback in preparation for BETA. There are several significant new features that are in need of testing in the enterprise development environments. Please contact me for support if you are interested in testing the latest release. Of course, I am always open to questions, comments, or feature requests! Please check out the project home page (http://www.owasp.org/index.php/Category:OWASP_CSRFGuard_Project) and User Manual (http://www.owasp.org/index.php/CSRFGuard_3_User_Manual) for more information about how to install, configure, and deploy the OWASP CSRFGuard library.

OWASP CSRFGuard has been completely rewritten to address the various feature requests and bug fixes submitted to me over the past couple years. No longer will CSRFGuard be referred to as just a "reference implementation". By addressing the performance and scalability issues plaguing older releases, OWASP CSRFGuard v3 is intended to serve as the de-facto standard prevention mechanism against CSRF attacks for JavaEE web applications. The following is a bulleted summary of the significant changes associated with the v3 release:

OWASP CSRFGuard is now available under the much more liberal BSD license
Owasp.CsrfGuard.properties file can be loaded from classpath, web context directory, or current directory
Developers can implement a custom logger to be consumed by the library
Experimental support for the rotation of CSRF tokens once the previous token is expired
Experimental support for creating and verifying unique CSRF tokens per page
Experimental support for Ajax through the verification of headers dynamically injected by CSRFGuard JavaScript
Configurable actions including Log, Invalidate, Redirect, Forward, RequestAttribute, and SessionAttribute
Unprotected pages can be captured using same syntax used by the JavaEE container in web.xml
Library no longer intercepts HTTP responses produced by the web application
Developers can manually inject CSRF prevention tokens using the JSP tag library
Developers can automate injection of CSRF prevention tokens using dynamic JavaScript DOM Manipulation
Tokens are only injected into HTML elements that submit requests to the current origin (planned for XHR)
JavaScript token injection can be configured to inject into links, forms, and XMLHttpRequests

Please check out the following resources for more information regarding recent project updates:

Project Page - http://www.owasp.org/index.php/Category:OWASP_CSRFGuard_Project
User Manual - http://www.owasp.org/index.php/CSRFGuard_3_User_Manual
Code Repository - http://code.google.com/p/owaspcsrfguard/