3 ms·

for what it might be worth to others: i've generally found that the client already has a cookie-session established in situations where cross-site ajax calls a

for what it might be worth to others: i've generally found that the client already has a cookie-session established in situations where cross-site ajax calls are a concern. so, my approach is to require a hash of <request text>+<session id cookie> as a per-call signature. javascript on another domain can't access the session id cookie and so won't be able to generate this signature.

pmjordan 17y ago
That's a pretty clever and elegant way to handle it, and seems to be pretty universally applicable, thanks!
bluefish 17y ago
This is also known as Cross Site Request Forgery or CSRF: http://en.wikipedia.org/wiki/Cross-site_request_forgery http://en.wikipedia.org/wiki/Cross-site_request_forgery
anamax 17y ago
> so, my approach is to require a hash of <request text>+<session id cookie> as a per-call signature. javascript on another domain can't access the session id cookie and so won't be able to generate this signature. If the security relies on other javascript not being able to access the session cookie, why is it insecure to use said session cookie by itself as the per-call signature? Who can see the signature but not the session id cookie?
- jeremyawon 17y ago
  you're right, hashing is overkill.
  - pmjordan 17y ago
    No, it isn't, as the cookie is sent with any request to your domain, regardless of the source. The hashing uses the fact that the cookie is inaccessible to JavaScript running in other domain contexts.
    - jeremyawon 17y ago
      the sid is inaccessible to js running in another domain context, so anamax is pointing that it suffices to just retransmit the sid as one of the request parameters, rather than generating and including sig=hash(request+sid). you're right that the remotely invoked request will include the sid as part of the http cookies header - it's what goes into the get/post request parameters which differentiates the domain context of the invoker. and if someone can't generate and include a sig because they can't access the sid, then the challenge might as well just be including the sid. the only draw back i see is that i wouldn't have had an excuse to learn how to implement sha ;) *edit: jim_lawless points out below that you might not want a sid showing up in web server logs. my system frequently rotates the clients sid, so it's not a concern to me - but if you do use less transient sid cookies you might want to implement the hash signature approach after all?
- pmjordan 17y ago
  The cookie will be sent even with a form submit. JavaScript from another domain can't see it directly, however.

pmjordan 17y ago

That's a pretty clever and elegant way to handle it, and seems to be pretty universally applicable, thanks!

bluefish 17y ago

This is also known as Cross Site Request Forgery or CSRF: http://en.wikipedia.org/wiki/Cross-site_request_forgery http://en.wikipedia.org/wiki/Cross-site_request_forgery

anamax 17y ago

> so, my approach is to require a hash of <request text>+<session id cookie> as a per-call signature. javascript on another domain can't access the session id cookie and so won't be able to generate this signature. If the security relies on other javascript not being able to access the session cookie, why is it insecure to use said session cookie by itself as the per-call signature? Who can see the signature but not the session id cookie?

jeremyawon 17y ago
you're right, hashing is overkill.
- pmjordan 17y ago
  No, it isn't, as the cookie is sent with any request to your domain, regardless of the source. The hashing uses the fact that the cookie is inaccessible to JavaScript running in other domain contexts.
  - jeremyawon 17y ago
    the sid is inaccessible to js running in another domain context, so anamax is pointing that it suffices to just retransmit the sid as one of the request parameters, rather than generating and including sig=hash(request+sid). you're right that the remotely invoked request will include the sid as part of the http cookies header - it's what goes into the get/post request parameters which differentiates the domain context of the invoker. and if someone can't generate and include a sig because they can't access the sid, then the challenge might as well just be including the sid. the only draw back i see is that i wouldn't have had an excuse to learn how to implement sha ;) *edit: jim_lawless points out below that you might not want a sid showing up in web server logs. my system frequently rotates the clients sid, so it's not a concern to me - but if you do use less transient sid cookies you might want to implement the hash signature approach after all?
pmjordan 17y ago
The cookie will be sent even with a form submit. JavaScript from another domain can't see it directly, however.