CSRF vulnerability in Tyler's GuestXHR protocol?

Hi Tyler,

I've been trying to understand the GuestXHR protocol you propose for
replacing CORS:

http://sites.google.com/site/guestxhr/maciej-challenge

I don't understand the message in step 5.  It seems like it might have
a CSRF vulnerability.  More specifically, what does the server do when
it receives a GET request for https://B/got?A=secret123?

The slides say "Associate user,A with secret123."  That sounds like
server B changes state to associate secret123 with the the pair (user,
A).  What stops an attacker from forging a cross-site request of the
form https://B/got?A=evil123?  Won't that overwrite the association?
There doesn't seem to be anything in the protocol that binds the "A"
in that message to server A.  (Of course, we could use the Origin
header to do that, but we're assuming that the Origin header isn't
present.)

More generally, how does B know the message https://B/got?A=secret123
has anything to do with "user"?  There doesn't seem to be anything in
the message identifying the user.  (Of course, we could use cookies to
do that, but we're assuming the cookie header isn't present.)

Can you help me understand how the protocol works?

Thanks,
Adam

P.S., It also seems that the protocol does not comply with the HTTP
specification because the server changes state in response to a GET
request.  Presumably, you mean to use a 307 redirect and a POST
request.  Unfortunately, that means the protocol will generate a
warning dialog in Firefox and will fail completely in Safari 4.

Received on Thursday, 5 November 2009 16:57:05 UTC