A message from our CEO about the future of Stack Overflow and Stack Exchange. Read now.

Hot answers tagged

47

I'll start my answer by saying that many people misunderstand the Same Origin Policy and what CORS brings to the table. Some of the up-voted answers already here are stating that the Same Origin Policy prevents cross-site requests, and therefore prevents CSRF. This is not the case. All the SOP does is prevent the response from being read by another domain (...


25

If I understand you correctly, you are saying why is the browser blocking access to a resource that can be freely obtained over the internet if cookies are not involved? Well consider this scenario: www.evil.com - contains malicious script code looking to exploit CSRF vulnerabilites. www.privatesite.com - this is your external site, but instead of locking ...


16

No. There is no security hole in just pretending CORS doesn't exist. CORS is an opt-in policy. As long as your server never sends any CORS headers (never opts in), browsers will continue to use the standard same-origin policy. You can pretend CORS doesn't exist, to keep your life simple: that's a perfectly reasonable strategy. CORS is optional: you can ...


12

What initially bothered me with CORS policies was their indiscriminate application regardless of resource/type, I feel that sentiment resonates with your question quite well. W3 spec actually advises that: A resource that is publicly accessible, with no access control checks, can always safely return an Access-Control-Allow-Origin header whose value ...


12

You're mixing things up. CORS is not meant to protect your application from crafted http requests, it's meant to protect you from a certain kind of attacks that "steals" the user's cookies or access tokens, by checking what sites can access your resource. It's mostly used to protect your server/application from cross-site request forgery, where a malicious ...


12

It's important to include the Vary: Origin header to prevent caching. The header indicates that the response is in some way dependent on the origin and should therefore not be served from cache for any other origin. If the header is missing, cache poisoning attacks might be possible as explained in the article by the example of XSS via a reflected custom ...


11

There are a few things that will mean exploitation is unlikely. To start with access-control-allow-credentials: true access-control-allow-origin: * is an invalid combination: Important note: when responding to a credentialed request, server must specify a domain, and cannot use wild carding. The above example would fail if the header was ...


11

I'm Ysrael and I'm the researcher that found this vulnerability. Let's divide your question into 2 parts: A. How did the Origin of the browser become null? B. How the null Origin affect Facebook servers? Let's start with A. The Origin is part of the CORS mechanism and it is intended to tell the server where the request comes from. When the server gets the ...


8

For your own good. If you disable CORS the following can happen: I send you link to a page called hackfacebook.com for example. When you visit my page, I then request the facebook.com page using an AJAX request which if you are logged in returns the page content as well as your session cookie. I now as the owner of hackfacebook.com have your login session....


8

This is the expected behavior. Before CORS it was already possible to make cross-site requests using HTML forms, cross-origin inclusion of images ... . But it was not possible to do cross-site XHR (Ajax) and thus workarounds were done by developers using the allowed methods. CORS changed this by loosening the original restrictions and allowing cross-...


7

The attack I think the attack they are trying to protect against is the following. Imagine santaclause.com serves an image at santaclause.com/naughty_or_nice.png to logged in users. The image is a green checkmark if the logged in user has been nice, and a red X if they have been naughty. Mallory wants to know if Alice has been nice or not. So on evil.com ...


7

What exactly would that image request URL look like? It need not be anything complicated or abnormal. There are two main ways this could work (were it not for the restrictions in the browser): In the first, there is a specific URL for the profile image of the current user, say http://mydatingsite.com/currentuser/profileimage.jpg. This might be an odd way ...


6

I'm not sure about OpenID, but for OAuth there is no CORS involved for the actual authentication part, though it may be required on the resource server depending on the type of client that is connecting. In RFC 6749, which defines the OAuth 2 framework, there are four different methods defined for the application to gain authorization (here, client means ...


6

The answer really depends on what API you created and how it works. This Site gives a very good explaination on the goods and bads of CORS. In short the author creates a fictional API that is used to send e-mails from another domain. He states: If you are using authentication based on session cookies, you probably shouldn’t allow CORS requests by everyone....


6

That paragraph is tersely written, and the use of "redirects to another resource at a new origin" in the first sentence isn't quite right. Here's a simple contrived example. Let's say you are malicious, and there is a web application that uses the services of a privileged API via CORS, so the web application's Origin is trusted by the privileged API. And ...


5

If the domains were the same, so the cookies were set on http://example.com/home/, and didn't have HTTP Only set, but there was an XSS vulnerability in http://example.com/vulnerable/, then the cookies can be accessed by the attacker - they can inject an iframe into the page, and use a script resembling document.getElementsByTagName("iframe")[0]....


5

https://xrmtfgxgjkzw.com is just an example generated by Burp. What it is in fact saying is that any website on the internet that the user is visiting can grab content from your site (possibly private to a user) if they are also logged into it. Scenario is as follows: Bob logs into your site, example.com. Bob gets an email from the attacker saying he can ...


5

You can use the following content types without CORS access: application/x-www-form-urlencoded multipart/form-data text/plain You can try a couple of things: Try sending valid JSON with another content type. Some implementations don't look at the content type. Try sending valid form data with the correct content type. Some implementations accept multiple ...


5

The CORS policy prevents a malicious website from gaining access to data on other domains. For example, foo.com should not be able to read the contents of bar.com via an ajax request or similar mechanism. If you set the Access-Control-Allow-Origin header to *, it allows any domain on the internet to send a request to your domain. By default, when no Access-...


5

Based on what you ask I think you are confusing concepts a bit: CSRF is a method to execute an authenticated action cross-site, i.e. triggered by an attacker but executed with the authentication of an already logged in user due to the automatic sending of existing session cookies or basic authentication credentials. CSRF is only about executing the action ...


5

So my understanding of why this is allowed is so that the implementation of CORS wouldn't break existing and well understood functionality which was already allowed by browsers. This also means that preflights aren't required for text/plain and multipart/form-data in addition to application/x-www-form-urlencoded These are referred to as "simple requests" ...


5

The simple answer is “no”. Cross-Site Request Forgery (CSRF) tokens are a generalized defense against CSRF, but other conditions must be at play to be vulnerable. For example, the attacker needs to be able to predictably make a valid request to the site. There are also other design factors that can be used to mitigate against the threat of CSRF. Auth/...


5

First thing: unless the CORS headers also allow credentials or are on a server that isn't supposed to be accessible from arbitrary IP addresses (or returns different content depending on the request source), this isn't really a vulnerability at all. If the browser cannot make authenticated requests (or at least not see the responses), then it can't do ...


4

So in this case when the attacker's script says document.cookie now, will the attacker be able to read the session cookie of the victim? No, the AJAX request can be sent and read due to the XSS flaw, however cookies from the AJAX request cannot. document.cookie will only reveal the cookies available to the initial exploited page (some_page.html). ...


4

TLDR: Nope, and if you think you need that, you're probably doing something wrong. There is literally no possible way to prevent non-browser access to anything that is also exposed to browsers. As far as a server is concerned, a web browser is just a program that sends and receives HTTP (and related protocols) traffic. That's it. You can do that using curl, ...


4

What attacks are mitigated by requiring CORS for subresource integrity verification? The Same Origin Policy is the cornerstone of the client-side security model of the web through the isolation of user data. As you already know, CORS relaxes the default SOP restrictions. Without relaxing these restrictions, the origin site has no right to inspect responses, ...


4

No, this is NOT (necessarily) safe. The other answers are mostly correct, except they are making two (common, but incorrect) assumptions: that localhost is always 127.0.0.1, and that a webserver running on your machine is one you wanted to run. THESE ARE NOT SAFE ASSUMPTIONS. Some machines, due to either deliberate modification for some purpose or simply ...


4

If the server simply mirrors the Origin provided by the client into the Access-Control-Allow-Origin header of the response without further checks then it essentially allows any third party to access the resource cross-origin, i.e. it would be a security issue if cross-origin access should be restricted. But, if this mirroring is only done after additional ...


4

You should only specify the origin header in your request. The application will respond with the Access-Control-* headers. Try only specifying the origin header and see what the result looks like. As far as if the headers are not returned at all, the web server doesn't have to respond with a CORS policy. If it doesn't then the browser will not allow cross ...


4

The statement, "every site without a CSRF token is vulnerable to a CSRF attack", is not accurate. It certainly does not apply to static websites that have no server-side functionality, where CSRF is not even applicable/possible. Additionally, the OWASP CSRF Prevention Cheat Sheet mentions some other CSRF-prevention mechanisms that do not use CSRF tokens: ...


Only top voted, non community-wiki answers of a minimum length are eligible