35 ms·
Both of those requests can be sent. CORS just stops the response from being read. It’s up to web servers on localhost to assume they’re at just as much risk as
by minitech 6y ago
Both of those requests can be sent. CORS just stops the response from being read. It’s up to web servers on localhost to assume they’re at just as much risk as any other non-local service, and they often fail to do so. (See also DNS rebinding that nets an attacker the opposite set of permissions, in a sense.)
- johnmaguire2013 6y agoThat's not actually true, at least via Ajax. Certainly you can just throw a POST at the website, and we hope that any web server is secured with CSRF protection. Additionally, the SameSite changes recently introduced by Chrome should further mitigate this problem.[1] > The Cross-Origin Resource Sharing standard works by adding new HTTP headers that let servers describe which origins are permitted to read that information from a web browser. Additionally, for HTTP request methods that can cause side-effects on server data (in particular, HTTP methods other than GET, or POST with certain MIME types), the specification mandates that browsers "preflight" the request, soliciting supported methods from the server with the HTTP OPTIONS request method, and then, upon "approval" from the server, sending the actual request. Servers can also inform clients whether "credentials" (such as Cookies and HTTP Authentication) should be sent with requests.[2] [1] https://www.chromium.org/updates/same-site/faq https://www.chromium.org/updates/same-site/faq [2] https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS
- minitech 6y agos/CORS/Lack of CORS/, but you can probably tell from my comment as a whole that I was covering exactly what you’ve just mentioned. Forgetting CSRF protection and Host header checks are exactly the kinds of things developers who write software that starts local servers forget all the time.