CSRF chat

Monday, 11 February 2008

You may think adding tokens to your forms will completely protect you from CSRF, you’d be wrong. I’ve shown in previous blog entries how you can use CSS overlays to bypass tokens. I decided to create a real world example which uses these techniques to create something cool. The world’s first CSRF chat! I got a couple of friends to try it out on various browsers and we could successfully communicate in pretty much real time.

Try it out here:-
CSRF chat

The technique uses delicious as a central hub to store the chat data, using a bookmarked url as a username and the description as chat data. A login is performed first using a hidden iframe with one delicious account shared between chat users. Another iframe is then used to load the messages, using JSON which is provided by delicious the chat data is then displayed. Confirmation is required because delicious uses tokens, I simply overlay the request using yet another iframe which displays the save button from the delicious web site.

Big thanks to David, Ronald, Mario and everyone else who helped test the chat room.

The entry 'CSRF chat' was posted on February 11th, 2008 at 1:34 pm and last modified on February 11th, 2008 at 2:41 pm, and is filed under csrf, Security. You can follow any responses to this entry through the RSS 2.0 feed. Both comments and pings are currently closed.

10 Responses to “CSRF chat”

  1. John Ther writes:
    No. 1 — February 11th, 2008 at 2:06 pm

    Good stuff Gareth, good CSS Overlay demonstration. Although it’s matter of time someone to change password and settings and other stuff for xsschat from delicious 🙂

  2. Gareth Heyes writes:
    No. 2 — February 11th, 2008 at 2:07 pm

    Thanks John yeah you’re right but it’s all in the name of fun 🙂

  3. Chris Shiflett writes:
    No. 3 — February 11th, 2008 at 6:48 pm

    Very creative. 🙂

    For my own clarification, and perhaps that of others, this technique requires the ability to manipulate the page, correct?

    An anti-CSRF token should be pretty strong unless there are lurking XSS problems, which I think we all agree is easier said than done. It’s nice to be clear about where the risk lies.

    Thanks!

  4. Gareth Heyes writes:
    No. 4 — February 11th, 2008 at 7:01 pm

    @chris

    The only requirement is central storage of data. This could be WordPress blog, GMail account, delicious account, flickr account etc. You must also be able to read that data externally, in this case I used the delicious JSON functionality.

    Delicious contains a form token to prevent posting of new urls to an account, however I simply bypass this by asking the user to confirm the post.

  5. Gareth Heyes writes:
    No. 5 — February 11th, 2008 at 7:13 pm

    btw I’m not saying tokens themselves are useless but in this instance they are. To defend against this type of attack a simple framebreaker would help.

  6. Gareth Heyes writes:
    No. 6 — February 12th, 2008 at 10:10 am

    The account has been deleted now, I can’t be bothered setting up another one. I may change the POC to allow multiple chatrooms or if anyone wants to take the code and improve it then please do.

  7. blog writes:
    No. 7 — May 9th, 2008 at 11:39 am

    thanks you.. john 🙂

  8. yakup writes:
    No. 8 — October 27th, 2008 at 11:49 pm

    Positive comment. thanks you.

  9. Forex writes:
    No. 9 — November 2nd, 2008 at 9:59 am

    Thanks you. i look this 😉

  10. aşk-ı memnu writes:
    No. 10 — January 20th, 2009 at 10:49 pm

    Thank you. good document. i add u favoritesites..

«
»