Comments on: Hacking CSRF Tokens using CSS History Hack

By: donb

donb — Fri, 02 Apr 2010 17:28:55 +0000

All of this discussion is very interesting. It looks like the world is still safe when CSRF is implemented with long tokens.

By: Des attaques en CSS !

Des attaques en CSS ! — Sun, 22 Nov 2009 05:48:36 +0000

[...] n’est que plus récemment que ces failles ont trouvés une utilitée autre que celle de ravir les publicitaires: le bruteforcing de token. Combiné cette [...]

By: Software Quality Digest - 2009-07-27 | No bug left behind

Software Quality Digest - 2009-07-27 | No bug left behind — Mon, 27 Jul 2009 17:10:48 +0000

[...] Hacking CSRF Tokens using CSS History Hack – “In this exploit, we discover the csrf token by brute forcing the various set of urls in browser history. We will try to embed different csrf token values as part of url and check if the user has visited that url. If yes, there is a good chance that the user is either using the same CSRF token in the current active session or might have used that token in a previous session. Once we have a list of all such tokens, we can just try our csrf attack on the server using that small list.” [...]

By: BryanSul

BryanSul — Wed, 22 Jul 2009 15:26:25 +0000

@ShawnM: There are a few benefits to URL tokens: they actually do a great job protecting against XSS (reflected and local), open-redirect phishing and browser history theft as well as XSRF; and better still you can implement them on existing apps without having to make any code changes. There are definitely a number of disadvantages as well (search engines can’t index sites protected this way) and the defense is far from perfect (referer leakage as you mentioned, among other problems) but these problems can be mitigated to certain degrees. I’m releasing a PoC defense library for ASP.NET with my talk next week, please download it and let me know where it falls down. I don’t think this is the end-all solution to XSS and XSRF but I do think it can work well in certain situations.

Btw also very much looking forward to your and Nathan’s talk too

@Inferno: Nope, I’m not a big tweeter If I have something to say I usually just drop it on the SDL blog.

By: Twitted by timfaas

Twitted by timfaas — Wed, 22 Jul 2009 13:57:49 +0000

[...] This post was Twitted by timfaas [...]

By: ShawnM

ShawnM — Wed, 22 Jul 2009 09:27:25 +0000

Sorry to spam the crap out of this blog entry.

Thinking about Bryan’s post. I’m not sure I can see how tokens in URL can be inherently better than POSTs, but I will agree they aren’t worse, if they’re nonces, and if they’re not leaked in referer via included offsite content.

I think something we can all agree on is that the path to doing this the right way is reasonably well understood, but from the attacker perspective there are many, many cases where it’s not what’s been implemented. I like unified approaches in APIs where some kind of tokenization is pervasive unless the dev explicitly calls for a request not to be tokenized (i.e. for SEO and usability or something).

By: |1|\||)0

|1|\||)0 — Wed, 22 Jul 2009 08:47:48 +0000

IMHO a data-changing action shouldn’t ever be allowed without valid lead-up to that action. E.g. submitting a new password for an account shouldn’t occur if the previous request wasn’t a legitimate request for the ‘change password form’ page, which itself wouldn’t have been served if the request prior to that wasn’t a legitimate request for the Account Management page. That “business process” of sorts is tracked in the session, not via data passed to and from the client, resulting in a reality-check of the interaction between the User and web application leading up to the data-changing request. This imposes the necessity to make a series of requests to perform a data-changing action, the web application can then impose extra checks such as ensuring that the timing between those requests reflects a real human user (i.e. response time + “think time”). That said, it would still be possible to scrape an initial anti-CSRF token from the web app (say thru an XSS vulnerability or sniffing) and then conduct the series of requests necessary to lead up to and utilise the data-changing request…Yet, using CAPTCHA for the anti-CSRF token is a great means of dealing with the inherent XSS problems regarding anti-CSRF tokens (as long as the CAPTCHA image can’t be re-served to the attacker), plus ensures that a real-human is making the request. Using CAPTCHA this way sortof* makes the “business process” checks more overkill than essential and also can be problematic in terms of legitimate automated use of the web app (e.g. business process monitoring).
*Since CAPTCHA can in some cases be bypassed via automation (neural networks), that business process reality-check provides an extra measure of scrutiny and makes it very hard/time-expensive to brute-force CAPTCHA.
Use of BACK/FORWARD browser buttons can be elegantly dealt with by sending the User to the non-data-changing-start of a business process from which he/she proceeds, rather than ending the session outright.
My view is that session-wide anti-CSRF tokens (“stale” tokens) are the bare-minimum solution. The best solution so far is an RSA-style token on any data-changing requests (benefit here is the web app never served the token out so it cant be scraped/sniffed). And an effective middle-ground is using “fresh” tokens served via CAPTCHA and entered via a form that gets POSTed.

By: Interesting Information Security Bits for 07/21/2009 | Infosec Ramblings

Interesting Information Security Bits for 07/21/2009 | Infosec Ramblings — Tue, 21 Jul 2009 21:00:06 +0000

[...] put together a couple things and came up with a fairly scaring attack on CRSF tokens. Hacking CSRF Tokens using CSS History Hack | SecureThoughts.com Tags: ( hacking crsf [...]

By: ShawnM

ShawnM — Tue, 21 Jul 2009 19:41:15 +0000

@BryanSul Nathan and I are interested in your talk and interested in the debate as well. =)

By: Researcher raids browser history for webmail login tokens « NoticFresh Weblog

Tue, 21 Jul 2009 18:10:23 +0000

[...] Researcher raids browser history for webmail login tokens Source: TheRegister & SecureThoughts [...]