4 ms·

Seems like an ugly hack just to avoid Javascript in an extremely nuanced scenario.

tyingq 6y ago
It's more of a deliberate hack that takes advantage of "form submission is not subject to the Same-Origin Policy". So it opens up CSRF in cases where the target might have assumed they were safe. Maybe you could, for example, figure out someone's logged-in Google ID this way (made up example, they likely catch this).
- patrickthebold 6y ago
  You can actually just make an XMLHttpRequest that's the same as what the form would do; CORS won't block the request going through to the server, it just blocks the javascript seeing the response: https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS#Simple_requests https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS#Simpl...
  - horsawlarway 6y ago
    This is not correct. The only time the request is made by default is when it falls in to the "simple" category, which as far as I'm aware, is limited to - GET requests - That only include known header fields In all other cases, you fall into the other bucket. In that case the browser will make a preflight options request (without any data) to check the CORS response headers configured by the server. Only then, if allowed by the response headers, will the browser actually make the POST. --- Ok, I went and looked, apparently you can send POSTS, you just can't send application/json, only one of the default form content types (text/plain is one, though). So I'm wrong - At least for Firefox, this would likely be the same request with the same behavior.
    - tyingq 6y ago
      "At least for Firefox, this would likely be the same request with the same behavior." Well, the form post returns the response, which opens up more csrf problems. Edit: uh, nope. Not sure where my head was. See below.
      - patrickthebold 6y ago
        Does it? I mean, the returns the response to the browser, but I believe the browser then renders that new page, which should be harmless since the server isn't going to return a malicious page.
        tyingq 6y ago
        Argh, yes, of course you're correct...
forgotmypw17 6y ago
JavaScript workaround techniques are always interesting and often useful to those who want to provide nojs users with full functionality.
barnaclejive 6y ago
Read the article

It's more of a deliberate hack that takes advantage of "form submission is not subject to the Same-Origin Policy". So it opens up CSRF in cases where the target might have assumed they were safe. Maybe you could, for example, figure out someone's logged-in Google ID this way (made up example, they likely catch this).

patrickthebold 6y ago
You can actually just make an XMLHttpRequest that's the same as what the form would do; CORS won't block the request going through to the server, it just blocks the javascript seeing the response: https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS#Simple_requests https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS#Simpl...
- horsawlarway 6y ago
  This is not correct. The only time the request is made by default is when it falls in to the "simple" category, which as far as I'm aware, is limited to - GET requests - That only include known header fields In all other cases, you fall into the other bucket. In that case the browser will make a preflight options request (without any data) to check the CORS response headers configured by the server. Only then, if allowed by the response headers, will the browser actually make the POST. --- Ok, I went and looked, apparently you can send POSTS, you just can't send application/json, only one of the default form content types (text/plain is one, though). So I'm wrong - At least for Firefox, this would likely be the same request with the same behavior.
  - tyingq 6y ago
    "At least for Firefox, this would likely be the same request with the same behavior." Well, the form post returns the response, which opens up more csrf problems. Edit: uh, nope. Not sure where my head was. See below.
    - patrickthebold 6y ago
      Does it? I mean, the returns the response to the browser, but I believe the browser then renders that new page, which should be harmless since the server isn't going to return a malicious page.
      - tyingq 6y ago
        Argh, yes, of course you're correct...

forgotmypw17 6y ago

JavaScript workaround techniques are always interesting and often useful to those who want to provide nojs users with full functionality.

barnaclejive 6y ago

Read the article