No CSRF in the presence of an XSS

Jeremiah Grossman published a list of some interesting unsolved websec problems.
Among them is how to protect a site against CSRF without having to deal with XSS stuff. That reminds me an interesting paper by Martin Johns which considers a JavaScript deferred loading mechanism. The session cookie is stored on the separate domain and thus unavailable for an XSS payload. There were some unsolved issues with that approach discussed by kuzza55 which I don't remember now (see the discussion).

My 5 cents

This night I got an idea I'll explain now. Night ideas are often silly so this one needs a review. Let's go step by step.

The first approximation does not consider usability issues; the possible improvements (as well as threats) are discussed later (in an other post).

Let us have a form on a site which is placed on the domain http://site.com and is vulnerable to XSS. Let's now split form in two parts. The first part is the form itself with an old good token. The second part is hosted at another domain, say, http://a.site.com. It consists of a button saying "Approve" and a hidden field with an other token (which is coupled with the first on on the server). This approvement form is injected into the first one using IFRAME.

User enters the data, then clicks "Approve". Token is sent (possibly asynchronously) to the server and the form identified by the coupled token is marked as trusted. Then the user clicks "Submit" and the request is accepted.