CSRF token

[Michal]

Hello,

I'd like my JavaScript client to include a CSRF token with each JSON-
RPC request, to prevent cross-site request forgery.

Where can I send the CSRF token?

My preferred way is in the request:
{ "jsonrpc": "2.0",
"method": "subtract",
"params": [42, 23],
"id": 1,
"csrfToken": "a secure string"
}

I could also use custom HTTP header:
POST /Endpoint HTTP/1.0
Content-Type: application/json-rpc
Content-Length: ...
X-Csrf-Token: a secure string

{ "jsonrpc": "2.0",
"method": "subtract",
"params": [42, 23],
"id": 1
}

Can I safely extend the JSON-RPC request as suggested in the first
case? (Doesn't it violate the spec? Can major clients/servers put up
with the extra csrfToken attribute?)
Is there something similar in existing JSON-RPC clients/servers/
specifications?
Should I propose an extension to the JSON-RPC 2.0 spec?

Regards,
Michal

[Matt (MPCM)]

Within the existing json-rpc spec, you could send it as a parameter in
your calls, assuming you control both ends of the communication.

I would lean towards headers (or in a non-http environment, including
it in the json-rpc request object). This is how most people use
session over http with json-rpc, in the available environments around
the payload.

If/as it works out, simply post about what you did and how it works
out. Sending some additional information like id strings, in out-of-
band or out-of-json-rpc may not warrant an extension effort on your
part.

These are my opinions of course, others might be able to speak about
implementation interaction issues you may face.

--
Matt (MPCM)

[Kris Zyp]

Personally, I prefer using headers for CSRF tokens, so as to be as
unobtrusive as possible with the request bodies. Actually, I believe
setting a header to any custom value creates a request that can not be
reproduced x-domain, so merely verifying a Content-Type of
application/json-rpc should provide CSRF protection (I think anyway).

Also, I think we have briefly discussed on this list that the most
correct media type to use for JSON-RPC would actually be
application/rpc+json (this is the normal media type for sub-media types
of a grammar like JSON or XML).

Kris

[Michal]

Thank you both, I'll use HTTP headers for the token.
I don't want to put it to params, as I may call the same methods via
different transports than HTTP (and then I wouldn't send CSRF token,
because there's no CSRF attack).

application/rpc+json looks reasonable. I haven't found the discussion
you mentioned. What about updating http://groups.google.com/group/json-rpc/web/json-rpc-over-http
-Content-Type SHOULD be 'application/json-rpc' but MAY be 'application/
json' or 'application/jsonrequest'
+Content-Type SHOULD be 'application/rpc+json' but MAY be 'application/
json-rpc' or 'application/json' or 'application/jsonrequest'
(etc. - Accept and examples)