4 ms·
Three things standout to me that made this attack possible. 1. JetBrains setting too broad CORS headers. 2. JetBrains listening to 0.0.0.0 instead of only lis
by K0nserv 10y ago
Three things standout to me that made this attack possible.
1. JetBrains setting too broad CORS headers.
2. JetBrains listening to 0.0.0.0 instead of only listening to localhost. Seems like YCMD is also listening to 0.0.0.0 instead of only localhost though.
3. But the overlooked concern in my eyes is why web browsers support XMLHTTPRequests to localhost/127.0.0.1 at all. I can't imagine a valid use case for that outside of developers working against a local machine. Seems to me like XMLHTPPRequests to localhost should be rejected by browsers unless `--disable-web-security` or some other equivalent is used during startup.
- pilif 10y ago> I can't imagine a valid use case for that outside of developers working against a local machine it's very useful to talk to locally installed applications without having to write specific browser plugins for all browsers. Dropbox and Github are using it to detect the presence of their respective desktop apps. And I'm personally using it (with restrictive CORS header, referrer signature checking and only listening on localhost) to read a barcode scanner and put the data into a web application. We only had to write one app per OS we support instead of one app per OS and one extension per browser (which also means that this works in all HTML5 compatible browsers, not just those we deem worthy of our support).
- K0nserv 10y agoI should have been clearer about that, for extensions I agree that calling localhost is reasonable if you have a desktop app you want to talk to for example. My suggestion would be removing the capabilities of XMLHTTPRequests to localhost from websites wile retaining the possibility for extensions