Cenzic 232 Patent
Paid Advertising
sla.ckers.org is
ha.ckers sla.cking
Q and A on cross site request forgeries and breaking into sessions. It's one of the attacks that XSS enables and the attack of the future. For Session, fixations, hijacking, lockout, replay, session riding etc.... 
Go to Topic: PreviousNext
Go to: Forum ListMessage ListNew TopicSearchLog In
Javascript CSRF protection
Posted by: Tentacle
Date: July 04, 2008 02:52AM

In order to protect against CSRF, I've made a very simple protocol. All interfaces (actions on certain URI) that need protection have to be POST and called via AJAX.

The system is fairly simple. The webapplication sends AJAX command to the server to perform whatever user wanted. The server invents a random token and returns back to AJAX application requesting confirmation (the response contains a 'confirmationrequired' identifier). The ajax application shows a confirm dialog, and when confirmed calls back that same URL, including the token previously received.

This works like a charm, and it will even work without AJAX, ie. if you show an intermediary form with hidden inputs containing the token, requesting the user to click ok to confirm his action. You click something, the application asks you if you are sure (having just received a token from the server), you click ok and the application sends back your confirmation with the token. With little effort you can write a class or a set of procedures that would facilitate confirmation requirement in your server-side application.

I was wondering, for certain actions, that are not as critical as to require user attention, but _should_ be protected against CSRF (if nothing then to avoid severe annoyance with user profiles modified by an unfunny hax0r), this could be automated, ie the user clicks, teh ajax interface sends command, receives token, and quietly responds.

What do you guys think? Are there any inherent vulnerabilities to this that I cannot see with my limited experience?

Options: ReplyQuote
Re: Javascript CSRF protection
Posted by: Tentacle
Date: July 09, 2008 06:28AM

I guess if the application is immune to XSS, then there is no risk of injecting a spoofed confirmator that would quietly execute the request and confirm it behind the user's back.

What I am really worried about is if this can be done cross-domain? If the user surfs to a malicious site, can that site somehow execute a cross-domain ajax request and do basically the same?

Options: ReplyQuote

Sorry, only registered users may post in this forum.