5 ms·

With regards to point #2, it's definitely inconvenient to cross-site POST from the client side, but not hard: Create a form with a target pointing to the extern

With regards to point #2, it's definitely inconvenient to cross-site POST from the client side, but not hard: Create a form with a target pointing to the external destination and submit it via Javascript, wrap it inside an invisible frame for neatness. Don't let POST give you a false sense of security; checking the referrer can help in this particular case (it's tricky to forge the referrer from the client side) but you really need a robust check like a generated token to avoid malicious cross-site requests.

pmjordan 18y ago
Thanks for raising the form issue. Presumably this can be done surreptitiously in a hidden iframe? (submitting a form normally displays the response)
jeremyawon 18y ago
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 18y ago
  That's a pretty clever and elegant way to handle it, and seems to be pretty universally applicable, thanks!
- bluefish 18y 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 18y 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 18y ago
    you're right, hashing is overkill.
    - pmjordan 18y 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 18y 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 18y ago
    The cookie will be sent even with a form submit. JavaScript from another domain can't see it directly, however.

pmjordan 18y ago

Thanks for raising the form issue. Presumably this can be done surreptitiously in a hidden iframe? (submitting a form normally displays the response)

jeremyawon 18y ago

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 18y ago
That's a pretty clever and elegant way to handle it, and seems to be pretty universally applicable, thanks!
bluefish 18y 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 18y 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 18y ago
  you're right, hashing is overkill.
  - pmjordan 18y 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 18y 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 18y ago
  The cookie will be sent even with a form submit. JavaScript from another domain can't see it directly, however.