361–370 of 392 posts
Earlier quoted context omitted.
This sounds crazy to me. Why should websites ever have access to the local network? That presents an entirely new threat model for which we don’t have a solution. Is there even a use case for this for which there isn’t already a better solution?
>for which we don’t have a solution It's called ZTA, Zero Trust Architecture. Devices shouldn't assume the LAN is secure.
I wish they'd (Apple/Micrsoft/Google/...) would do similar things for USB and Bluetooth. Lately, every app I install, wants bluetooth access to scan all my bluetooth devices. I don't want that. At most, I want the app to have to declare in their manifest some specific device IDs (short list) that their app is allowed to connect to and have the OS limit their connections to only those devices. For for example the Bose…
I am still holding out hope that eventually at least Apple will offer fake permission grants to applications. Oh, app XYZ "needs" to see my contact list to proceed? Well it gets a randomized fake list, indistinguishable from the real one. Similar with GPS. I have been told that WhatsApp does not let you name contacts without sharing your address book back to Facebook.
Earlier quoted context omitted.
Doesn't CORS just restrict whether the webpage JS context gets to see the response of the target request? The request itself happens anyway, right? So the attack vector that I can imagine is that JS on the browser can issue a specially crafted request to a vulnerable printer or whatever that triggers arbitrary code execution on that other device. That code might be sufficient to cause the printer to carry out your ev…
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 abo…
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)
Earlier quoted context omitted.
This expectation is that this should not work - well behaved network devices shouldn't accept a blind GET like this for destructive operations. Plenty of other good reasons for that. No real alternative unless you're also going to block page redirects & links to these URLs as well, which also trigger a similar GET. That would make it impossible to access any local network page without typing it manually. While it cle…
"No true Scotsman allows GETs with side effects" is not a strong argument It's not just HTTP where this is a problem. There are enough http-ish protocols where protocol smuggling confusion is a risk. It's possible to send chimeric HTTP requests at devices which then interpret them as a protocol other than http.
Earlier quoted context omitted.
This tag: triggers a local network GET request without any CORS involvement.
Exactly 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.
You cant do a DELETE from a form. You have to use ajax. If cross DELETE needs preflight.
To nitpick, CSRF is not the ability to use forms per se, but relying solely on the existence of a cookie to authorize actions with side effects.
Earlier quoted context omitted.
I 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.
If 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.
In the modern web its much less of an issue due to samesite cookies being default .
Earlier quoted context omitted.
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 abo…
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).
https://www.kb.cert.org/vuls/id/476267 is an article from 2001 on it.
I wish they'd (Apple/Micrsoft/Google/...) would do similar things for USB and Bluetooth. Lately, every app I install, wants bluetooth access to scan all my bluetooth devices. I don't want that. At most, I want the app to have to declare in their manifest some specific device IDs (short list) that their app is allowed to connect to and have the OS limit their connections to only those devices. For for example the Bose…
I am still holding out hope that eventually at least Apple will offer fake permission grants to applications. Oh, app XYZ "needs" to see my contact list to proceed? Well it gets a randomized fake list, indistinguishable from the real one. Similar with GPS. I have been told that WhatsApp does not let you name contacts without sharing your address book back to Facebook.
Earlier quoted context omitted.
> If it is truly static site/page, download it and open from local disk. And nudge vendor to release it as archive which can be downloaded and unpacked locally. Depending on the browser, file:/// is severely limited in what CORS requests are allowed. And then there's products like Plex, where it's not a static site, but you still want a central dashboard that connects to your local Plex server directly via CORS.
Why local Plex which you need to install & run (it is already Server) cannot provide its own UI to browser, without 3rd party sites? It is absurd design, IMHO. I'll never allow this in my network. It looks security nightmare. Today it shows me dashboard (of what? Several my Plex servers?), tomorrow it is forced to report pirated movies to police. No, thanx.
So manufacturers create all kinds of crazy workarounds, like plex's, to be able to present an HTTPS web page that is easily accessible and can just talk to the device. (Except it's still not that simple, because you can't easily make an HTTP request from an HTTPS context, so plex also jumps through a bunch of hoops to co-ordinate some HTTPS certificate for the local device, which requires an internet connection).
It's a complete mess, and browsers really seem to be keen on blocking any 'let HTTPS work for local devices' solution, even if it were just a simple upgrade to the status quo that would otherwise just be treated like HTTP. Nor will they stop putting useful APIs behind a 'secure context' like an HTTPS certificate implies any level of trust except that a page is associated with a given domain name.
(Someone at plex seems to have finally gotten through to some of the devs at Chrome, and AFAIK there is now a somewhat reasonable flow that would allow e.g. a progressive webapp to request access to a local device and communicate with it without an HTTPS certificate, which is something, but still way to just host the damn UI on the device without limiting the functionality! And it's chrome-only, maybe still in preview? Haven't gotten around to trying to implement it yet)
See this long, painful, multi-year discussion on the topic: https://github.com/WICG/private-network-access/issues/23