Cross-site scripting (XSS) and cross-site request forgery (CSRF) have been well-known attack vectors for a long time. In my previous articles, I describe how XSS vulnerabilities can be used to attack popular open source web applications and application frameworks, and how some web applications are compromised by CSRF attacks because of implementation flaws on the server side.

Attackers can also combine these two vulnerabilities to launch attacks that bypass prevention measures. This article illustrates how an attacker could execute a XSS attack to get the anti-CSRF token, which could then be used in a CSRF attack to gain administrator privileges in the application.

Continue reading …

Cross-Site Request Forgery (CSRF) is an attack that tricks the victim’s browser into executing malicious requests designed by the attacker.  A successful CSRF attack can force the victim’s browser to perform state-changing requests like transferring funds or changing his email address. Clearly these are attacks that need to be prevented.

Continue reading …

When Juliano and Thai disclosed the CRIME attack last year, it was clear that the same attack technique could be applied to any other compressed data, and compressed response bodies (via HTTP compression) in particular. But it was also clear that—with our exploit-driven culture—browser vendors were not going to do anything about.

Progress will be made now that there is an exploit to worry about because, this year at Black Hat, a group of researched presented BREACH, a variant of CRIME that works exactly where it hurts the most, on HTTP response bodies. If you’re not already familiar with the attack I suggest that you go to the researchers' web site, where they have a very nice paper and a set of slides.

Continue reading …

Interest in the QualysGuard Web Application Scanning (WAS) module has been growing since its new UI was demonstrated last week at BlackHat. Along with such interest come questions about how the scanner works. The ultimate goal for WAS is to provide accurate, scalable testing for the most common, highest profile vulnerabilities (think of SQL injection and XSS) so that manual testing can skip the tedious and time-consuming aspects of an app review and focus on complex vulns that require brains rather than RAM.

One complex vuln in particular is CSRF. Automated, universal CSRF detection is a tough challenge, which is why we try to solve the problem in pieces rather than all at once. It’s the type of challenge that keeps web scanning interesting. Here’s a brief look at the approach we’ve taken to start bringing CSRF detection into the realm of automation.

First, the test assumes an authenticated scan. If the scan is not given credentials, then the tests won’t be performed. Also, tests are targeted to specific manifestations of CSRFrather than the broad set of attacks possible from our friendly sleeping giant.

Tests roughly follow these steps. Fundamentally, we’re trying to model an attack rather than make inferences based on pattern matching:

1. Identify forms with a "session context". This is a weaker version of (but hopefully a subset of) a "security context", because lots of times security requires knowledge about the boundaries within an app and the authorized actions of a user. This knowledge is hard to come by automatically. Never the less, some utility can be had by looking at forms with the following attributes:

• Only available to an authenticated user.
• Are not "trivial" such as search forms or logout buttons.
• Have an observable effect, either on the session or the HTTP response. (Hint: Here’s where the automated scan becomes narrow, meaning prone to false negatives.)

2. Set up two separate sessions for the user (i.e. login twice). Keep their cookie jars apart. We’ll refer to the sessions as Aardvark and Bobcat (or A & B or Alpha & Bravo, etc.). Remember, this is for a single user.

3. Obtain a form for session Aardvark.

4. Obtain a form for session Bobcat.

5. Swap the forms between the two sessions and submit. (Crossing the streams, like Egon told you not to do.)

• The assumption is that any CSRF tokens in Aardvark’s form are tied to the session cookie(s) used by Aardvark and Bobcat’s belong to Bobcat. Things should blow up if the tokens and session don’t match.

6. Examine the "swapped" responses.

• If the form’s fields never change between sessions, then this is a good indicator that no CSRF token is present. You have to run tests with a browser in order to make sure there’s no JavaScript dynamically changing the form when the page loads or the form is submitted.
• If the response has a clear indication of error, then the app is more likely to be protected from CSRF. The obvious error is something like, "Invalid CSRF token". Sadly, the world is not unicorns and rainbows for automated scanning and errors may not be so obvious or point so directly to CSRF.
• If the response is similar to the one received from the original request, then it appears that the form is not coupled to a user’s session. This is an indicator that the form is more probably vulnerable to CSRF.

What it won’t do, because these techniques are noisy and unreliable (as opposed to subtle and quick to anger):

• Look for hidden form fields with names or values that match CSRF tokens. If an obvious token is present, that doesn’t mean the app is actually validating it.
• Use static inspection of the form, DOM, or HTML to look for any examples of CSRF tokens. Why look for text patterns when you’re trying to determine a behavior? Not everything is solved by regexes. (Which really is unfortunate, by the way.)
• Attempt to evaluate the predictability of anything that looks like a CSRF token.
• Submit forms without loading the complete page and its resources in a browser; otherwise JavaScript-based countermeasures would not be noticed.

Nor will it demonstrate the compounding factor of CSRF onother vulnerabilities like XSS. That’s something that manual pen-testing should do. In other words, WAS is focused on identifying vulns (it should find an XSS vuln, but it won’t tie the vuln to a CSRF attack to demonstrate a threat). Manual pen-testing more often focuses on how deep an app can be compromised — and the real risks associated with it.

What it’ll miss:

• Situations where sessions cookie(s) are static or relatively static for a user. This impairs the "swap" test.
• CSRF that can affect unauthenticated users in a meaningful way. This is vague, but as you read more about CSRF you’ll find that some people consider any forgeable action should be considered a vuln. This speaks more to the issue of evaluating risk. You should be relying on people to analyze risk, not tools.
• CSRF that affects the user’s privacy. This requires knowledge of the app’s policy and the impact of the attack.
• Forms whose effect on a user’s security context manifests in a different response, or in a manner that isn’t immediately evident.
• CSRF tokens in the header, which might lead to false positives.
• CSRF vulns that manifest via links rather thanforms. Apps put all kinds of functionality in hrefs rather than explicit form tags.
• Other situations where we play games of anecdotes and what-ifs.

What we are trying to do:

• Reduce noise. Don’t report vulns for the sake of reporting a vuln if no clear security context or actionable data can be provided.
• Provide a discussion point so we can explain thebenefits of automated web scanning and point out where manual follow-up will always be necessary.
• Learn how real-world web sites implement CSRF in order to find common behaviors that might be detectable via automation. You’d be surprised (maybe) at how often apps have security countermeasures that look nothing like OWASP recommendations and, consequently, fare rather poorly.
• Experiment with pushing the bounds of what automation can do, while avoiding hyperbolic claims that automation solves everything.

The current state of CSRF testing in WAS should be relied on as a positive indicator (vuln found, vuln exists) more so than a negative indicator (no vuln found, no vulns exist). That’s supposed to mean that a CSRF vuln reported by WAS should not be a false positive and should be something that the app’s devs need to fix. It also means that if WAS doesn’t find a vuln then the app may still have CSRF vulns. For this particular test a clean report doesn’t mean a clean app; there’re simply too many ways of looking at the CSRF problem to tackle it all at once. We’re trying to break the problem down into manageable parts in order to understand what approaches work. We want to hear your thoughts and feedback on this.