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?

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?