34 ms·
No, a preflight (OPTIONS) request is sent by the browser first prior to sending the request initiated by the application. I would be surprised if it is possibl
by tombakt 1y ago
No, a preflight (OPTIONS) request is sent by the browser first prior to sending the request initiated by the application. I would be surprised if it is possible for the client browser to control this OPTIONS request more than just the URL. I am curious if anyone else has any input on this topic though.
Maybe there is some side-channel timing that can be used to determine the existence of a device, but not so sure about actually crafting and delivering a malicious payload.
- deleted 1y ago[deleted]
- LegionMammal978 1y agoThe 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).
- kbolino 1y agoHere'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/CORS#simple_requests https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/COR...
- MajesticHobo2 1y agoThere 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 1y agoExactly. People who are answering must not have been aware of “simple” requests not requiring preflight.
- mirashii 1y agoYou 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 https://news.ycombinator.com/item?id=44169115
- notpushkin 1y agoYeah, I think this is the reason this proposal is getting more traction again.
- freeone3000 1y agoOh, you can only send arbitrary text or form submissions. That’s SO MUCH.
- tomrod 1y agoCorrect.
- drexlspivey 1y agoIt can send a json-rpc request to your bitcoin node and empty your wallet
- LegionMammal978 1y agoDo you know of any such node that doesn't check the Content-Type of requests and also has no authentication?
- drexlspivey 1y agoBitcoin Core if you disable authentication
- LegionMammal978 1y agoThere'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.cpp#L163-L169 https://github.com/bitcoin/bitcoin/blob/v29.0/src/httprpc.cp...
- drexlspivey 1y agoGood to know, I remember you used to be able to disable it via config but looks like I was wrong
- chuckadams 1y agoSome 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.
- Sophira 1y agoI 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 1y agoThis is a great example; thanks.
- bawolff 1y agoI think that is because it is so old that its basically old news and mostly mitigated. https://www.kb.cert.org/vuls/id/476267 https://www.kb.cert.org/vuls/id/476267 is an article from 2001 on it.
- deleted 1y ago[deleted]
- layer8 1y agoThere is a limited, but potentially effective, attack surface via URL parameters.
- rerdavies 1y agoI can confirm that local websites that don't implement CORS via the OPTIONS request cannot be browsed with mainstream browsers. Does nothing to prevent non-browser applications running on the local network from accessing your website. As far as I can tell, the only thing this proposal does that CORS does not already do is provide some level of enterprise configuration control to guard against the scenario where your users are using compromised internet sites that can ping around your internal network for agents running on compromised desktops. Maybe? I don't get it. If somebody would fix the "no https for local connections" issue, then IoT websites could use authenticated logins to fix both problems. Non-https websites also have no access to browser crypto APIs so roll-your-own auth (the horror) isn't an option either. Fustrating!
- dgoldstein0 1y agoI don't believe this is true? As others have pointed out, preflight options requests only happen for non simple requests. Cors response headers are still required to read a cross domain response, but that is still a huge window for a malicious site to try to send side effectful requests to your local network devices that have some badly implemented web server running.
- rerdavies 1y ago[edit]: I was wrong. Just tested that a moment ago. It turns out NOT to be true. My web server during normal operation is current NOT getting OPTIONS requests at all. Wondering whether I triggered CORS requests when I was struggling with IPv6 problems. Or maybe it triggers when I redirect index.html requests from IPv6 to IPv4 addresses. Or maybe I got caught by the earlier roll out of version one of this propposal? There was definitely a time while I was developing pipedal when none of my images displayed because my web server wasn't doing CORS. But. Whatever my excuse might be, I was wrong. :-/
- rafram 1y agoYou’re forgetting { mode: 'no-cors' }, which makes the response opaque (no way to read the data) but completely bypasses the CORS preflight request and header checks.
- chuckadams 1y agoThankfully no-cors also restricts most headers, including setting content-type to anything but the built-in form types. So while CSRF doesn't even need a click because of no-cors, it's still not possible to do csrf with a json-only api. Just be sure the server is actually set up to restrict the content type -- most frameworks will "helpfully" accept and convert form-data by default.
- jonchurch_ 1y agoThis is missing important context. You are correct that preflight will be skipped, but there are further restrictions when operating in this mode. They don't guarantee your server is safe, but it does force operation under a “safer” subset of verbs and header fields. The browser will restrict the headers and methods of requests that can be sent in no-cors mode. (silent censoring in the case of headers, more specifically) Anything besides GET, HEAD, POST will result in an error in browser, and not be sent. All headers will be dropped besides the CORS safelisted headers [0] And Content-Type must be one of urlencoded, form-data, or text-plain. Attempting to use anything else will see the header replaced by text-plain. [0] https://developer.mozilla.org/en-US/docs/Glossary/CORS-safelisted_request_header https://developer.mozilla.org/en-US/docs/Glossary/CORS-safel...
- rafram 1y agoThat’s just not that big of a restriction. Anecdotally, very few JSON APIs I’ve worked with have bothered to check the request Content-Type. (“Minimal” web frameworks without built-in security middleware have been very harmful in this respect.) People don’t know about this attack vector and don’t design their backends to prevent it.
- jonchurch_ 1y ago
- varenc 1y agoThis tag: <img src="http://192.168.1.1/router?reboot=1"> triggers a local network GET request without any CORS involvement.
- lyu07282 1y agoExactly you can also trigger forms for POST or DELETE etc. this is called CSRF if the endpoint doesn't validate some token in the request. CORS only protects against unauthorized xhr requests. All decades old OWASP basics really.
- formerly_proven 1y agoThat highly ranked comments on HN (an audience with way above average-engineer interest in software and security) get this wrong kinda explains why these things keep being an issue.
- lyu07282 1y agoI don't know why you are getting downvoted, you do have a point. Some of the comments appear knowing what CORS headers are, but neither their purpose nor how it relates to CSRF it seems, which is worrying. It's not meant as disparaging. My university thought a course on OWASP thankfully, otherwise I'll probably also be oblivious.
- _cenw 1y agoIf you're going cross-domain with XHR, I'd hope you're mostly sending json request bodies and not forms. Though to be fair, a lot of web frameworks have methods to bind named inputs that allow either.
- bawolff 1y agoThis misses the point a bit. CSRF usually applies to people who want only same domain requests and dont realize that cross domain is an option for the attacker. In the modern web its much less of an issue due to samesite cookies being default .
- thayne 1y agoIt depends. GET requests are assumed not to have side effects, so often don't have a preflight request (although there are cases where it does). But of course, not all sites follow those semantics, and it wouldn't surprise me if printer or router firmware used GETs to do something dangerous. Also, form submission famously doesn't require CORS.
- bawolff 1y ago> No, a preflight (OPTIONS) request is sent by the browser first prior to sending the request initiated by the application. Note: preflight is not required for any type of request that browser js was capable of making prior to CORS being introduced. (Except for local network) So a simple GET or POST does not require OPTIONS, but if you set a header it might require OPTIONS (unless its a header you could set in the pre-cors world)