[LegionMammal978]

The idea is, the malicious actor would use a 'simple request' that doesn't need a preflight (basically, a GET or POST request with form data or plain text), and manage to construct a payload that exploits the target device. But I have yet to see a realistic example of such a payload (the paper I read about the idea only vaguely pointed at the existence of polyglot payloads).

[MajesticHobo2]

There doesn't need to be any kind of "polyglot payload". Local network services and devices that accept only simple HTTP requests are extremely common. The request will go through and alter state, etc.; you just won't be able to read the response from the browser.

[EGreg]

Exactly. People who are answering must not have been aware of “simple” requests not requiring preflight.

[Sophira]

I can give an example of this; I found such a vulnerability a few years ago now in an application I use regularly.

The target application in this case was trying to validate incoming POST requests by checking that the incoming MIME type was "application/json". Normally, you can't make unauthorized XHR requests with this MIME type as CORS will send a preflight.

However, because of the way it was checking for this (checking if the Content-Type header contained the text "application/json"), It was relatively easy to construct a new Content-Type header that bypasses CORS:

Content-Type: multipart/form-data; boundary=application/json

It's worth bearing in mind in this case that the payload doesn't actually have to be form data - the application was expecting JSON, after all! As long as the web server doesn't do its own data validation (which it didn't in this case), we can just pass JSON as normal.

This was particularly bad because the application allowed arbitrary code execution via this endpoint! It was fixed, but in my opinion, something like that should never have been exposed to the network in the first place.

[apitman]

This is a great example; thanks.

[freeone3000]

Oh, you can only send arbitrary text or form submissions. That’s SO MUCH.

[tomrod]

Correct.

[mirashii]

You don't even need to be exploiting the target device, you might just be leaking data over that connection.

https://news.ycombinator.com/item?id=44169115

[notpushkin]

Yeah, I think this is the reason this proposal is getting more traction again.

[kbolino]

Here's a formal definition of such simple requests, which may be more expansive than one might expect: https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/COR...

[chuckadams]

Some devices don't bother to limit the size of the GET, which can enable a DOS attack at least, a buffer overflow at worst. But I think the most typical vector is a form-data POST, which isn't CSRF-protected because "it's on localhost so it's safe, right?"

I've been that sloppy with dev servers too. Usually not listening on port 80 but that's hardly Ft Knox.

[drexlspivey]

It can send a json-rpc request to your bitcoin node and empty your wallet

[LegionMammal978]

Do you know of any such node that doesn't check the Content-Type of requests and also has no authentication?

[drexlspivey]

Bitcoin Core if you disable authentication

[LegionMammal978]

There's no such thing, short of forking it yourself. You can set the username and password to admin:admin if you want, but Bitcoin Core's JSON-RPC server requires an Authorization header on every request [0], and you can't put an Authorization header on a cross-origin request without a preflight.

[0] https://github.com/bitcoin/bitcoin/blob/v29.0/src/httprpc.cp...

[drexlspivey]

Good to know, I remember you used to be able to disable it via config but looks like I was wrong

[bawolff]

I think that is because it is so old that its basically old news and mostly mitigated.

https://www.kb.cert.org/vuls/id/476267 is an article from 2001 on it.