I got an interesting email from devloop today about a way to circumvent certain forms of CSRF protection. I’ve actually talked about this before but I never had a concrete example to show off. The basic premise is that if you have a two step process and the session is stored in a cookie and not on the page, you don’t need XSS to bypass it, you only need a series of CSRF (or same site request forgeries) to initiate the attack. Here is devloop’s email (modified for formatting):
Hi RSnake !
I’m one of your reader and also the developper of a web application vulnarability scanner called Wapiti ( http://wapiti.sourceforge.net/ ) Got my blog at http://devloop.lyua.org/blog/ (french)
I wanted to tell you about a Cross Site Request Forgery I found on the Last.fm website. This website allows users to create and join groups.
I study a little how the inscription to a group work and I was looking like a simple url will make the victim join to a group.
I created a group called “CSRF” ( http://www.last.fm/group/CSRF ) Tipically a user that want to join a group must go to the group homepage, click the “Join this group” link to go to the page http://www.last.fm/group/CSRF/join/. Then the user must confirm the inscription clicking on a submit bouton with an empty <form> with action=http://www.last.fm/group/CSRF/join/?confirm=yes
At this time I was thinking that users will join the CSRF group just by going to this page. But Last.fm got a kind of CRSF protection. Users were asked for a new validation, this time goin to http://www.last.fm/group/CSRF/join/?confirm=apply.
If the user go to http://www.last.fm/group/CSRF/join/?confirm=apply first, he will be redirected to http://www.last.fm/group/CSRF/join/?confirm=yes.
The solution was to make sure users go to the two urls. So I posted a news on the forum and in my journal section with to <img> linking to the urls [img]http://www.last.fm/group/CSRF/join/?confirm=yes[/img] [img]http://www.last.fm/group/CSRF/join/?confirm=apply[/img] (Last.fm allows some BB code)
I started with one unique member for the group (me) and now I got 14 users in the group http://www.last.fm/group/CSRF/members
I hope to get more users soon, as friends of the victims may be be infected to just by looking at the CSRF group page.
Bye ! and keep posting on your blog.
This is exactly what I was talking about. In some applications that I’ve seen (but can’t post for NDA reasons) a type of click protection is used to prevent users from going from page to page. However, the cookie to allow the activity is stored upon user submission of the first CSRF.
That allows the attacker to force you to perform the action through a series of clicks, without actually needing the page to render (as it breaks inside of an IMG tag). All the attacker really needs is to get you to visit the page so you pick up the proper headers (the authorization token) so that the second request is sent as an authorized user. Lesson learned? The one time use authorization token to stop CSRF has to be something that the page emits, not just something that the server headers emit. And even then you have to make sure there is no XSS on the same host or on the same IP even so they can’t read it. Tricky.