4 ms·

Thanks for commenting ... When we discussed it in #documentcloud, that was the consensus we came to as well -- it's a bit silly to slightly tweak your JSON in t

Thanks for commenting ... When we discussed it in #documentcloud, that was the consensus we came to as well -- it's a bit silly to slightly tweak your JSON in this fashion, when browsers are still opening holes to make it executable in other ways: http://directwebremoting.org/blog/joe/2007/03/06/json_is_not_as_safe_as_people_think_it_is_part_2.html http://directwebremoting.org/blog/joe/2007/03/06/json_is_not... Doing a `while(1);` would be much more robust.

tosh 16y ago
wouldn't it be possible for the attacker to alter the meaning of 'while' beforehand?
- nbpoole 16y ago
  The assumption is that a browser won't let you re-define the meaning of low-level constructs like "while" and "1". The assumption is somewhat reasonable, but it could be violated in the future, which is why the Browser Security Handbook advocates against it.
  - tosh 16y ago
    +1 thank you for the clarification
coderrr 16y ago
It seems to me the suggestion to require the 'X-Requested-With:XMLHttpRequest' header to be set is the best way to handle this, much better than some JS tweaking. It doesn't make any assumptions about javascript syntax or implementations. And the only way I can think to get around it is some http request splitting exploit via a proxy. If you only return data to XHRs then you're protected by same origin policy and all <script> tags will get no data. -EDIT- When I first read "a better option is to require custom XMLHttpRequest headers" I thought this is what they were talking about. After a second look they probly mean setting a custom header yourself using the XHR object. This would work too but now I'm wondering if there's some way around my solution. Because why would they advocate a custom header if checking the X-Request-With header alone is enough? - EDIT - Was just in the shower and remembered why they probly don't advise to just check the X-Requested-With header. There are ways for an attacker to get around the XHR same origin policy with dns pinning/rebinding attacks. If you required a custom header with a session cookie which the attacker didn't have access to this would mitigate that kind of attack. EDIT: Nevermind, as long as you're checking the Host header a dns rebinding attack wouldn't matter.
- jashkenas 16y ago
  This sounds like an even better fix -- nicely done.
  - mrkurt 16y ago
    You could just use the Origin header from CORS: http://www.w3.org/TR/cors/#origin-request-header http://www.w3.org/TR/cors/#origin-request-header
    - coderrr 16y ago
      But how many browsers actually send the Origin header currently? I just checked Firefox and Chrome and neither sent it on a <script> or XHR request.
      - nbpoole 16y ago
        It definitely isn't set via <script>. I know it's sent when you make an XHR request via jQuery, so I assume you can set it as a custom header if you're rolling your own XHR.
        coderrr 16y ago
        Ah sorry, I was only checking same domain XHRs, which doesn't seem to send the Origin header. That combined with the fact that Origin isn't sent for <script> tags seems like it can't be used to prevent CSRFs.
        nbpoole 16y ago
        It might not send it automatically (I don't know, I haven't tested it), but since you're the one building the XHR, you can send the header if you want. The same origin policy won't let you see the results of a cross-domain request, so it seems like requiring the header is an effective technique. Obviously this is only true for read operations: anything that updates state would still be vulnerable to CSRF (since you don't need to be able to read the result to make the request).

tosh 16y ago

wouldn't it be possible for the attacker to alter the meaning of 'while' beforehand?

nbpoole 16y ago
The assumption is that a browser won't let you re-define the meaning of low-level constructs like "while" and "1". The assumption is somewhat reasonable, but it could be violated in the future, which is why the Browser Security Handbook advocates against it.
- tosh 16y ago
  +1 thank you for the clarification

coderrr 16y ago

It seems to me the suggestion to require the 'X-Requested-With:XMLHttpRequest' header to be set is the best way to handle this, much better than some JS tweaking. It doesn't make any assumptions about javascript syntax or implementations. And the only way I can think to get around it is some http request splitting exploit via a proxy. If you only return data to XHRs then you're protected by same origin policy and all <script> tags will get no data. -EDIT- When I first read "a better option is to require custom XMLHttpRequest headers" I thought this is what they were talking about. After a second look they probly mean setting a custom header yourself using the XHR object. This would work too but now I'm wondering if there's some way around my solution. Because why would they advocate a custom header if checking the X-Request-With header alone is enough? - EDIT - Was just in the shower and remembered why they probly don't advise to just check the X-Requested-With header. There are ways for an attacker to get around the XHR same origin policy with dns pinning/rebinding attacks. If you required a custom header with a session cookie which the attacker didn't have access to this would mitigate that kind of attack. EDIT: Nevermind, as long as you're checking the Host header a dns rebinding attack wouldn't matter.

jashkenas 16y ago
This sounds like an even better fix -- nicely done.
- mrkurt 16y ago
  You could just use the Origin header from CORS: http://www.w3.org/TR/cors/#origin-request-header http://www.w3.org/TR/cors/#origin-request-header
  - coderrr 16y ago
    But how many browsers actually send the Origin header currently? I just checked Firefox and Chrome and neither sent it on a <script> or XHR request.
    - nbpoole 16y ago
      It definitely isn't set via <script>. I know it's sent when you make an XHR request via jQuery, so I assume you can set it as a custom header if you're rolling your own XHR.
      - coderrr 16y ago
        Ah sorry, I was only checking same domain XHRs, which doesn't seem to send the Origin header. That combined with the fact that Origin isn't sent for <script> tags seems like it can't be used to prevent CSRFs.
        nbpoole 16y ago
        It might not send it automatically (I don't know, I haven't tested it), but since you're the one building the XHR, you can send the header if you want. The same origin policy won't let you see the results of a cross-domain request, so it seems like requiring the header is an effective technique. Obviously this is only true for read operations: anything that updates state would still be vulnerable to CSRF (since you don't need to be able to read the result to make the request).