Hot answers tagged

42

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

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 ...


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 ...


11

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 ...


11

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 ...


8

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 ...


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

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 ...


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

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 ...


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

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....


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

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....


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" ...


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

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

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

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 ...


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 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/...


4

The CORS policy is enforced by the browser, not by the server. The server just sets a couple of HTTP headers telling the browser how it wants it to behave. There is nothing that forces a proxyserver to honor those headers, and it can add, edit or remove them like it can with any other headers. So the proxy can send the request but you can not, because as a ...


4

If you are trying to defeat CORS you are actively trying to create insecurity and vulnerability for your end users. CORS was not created because we delight in creating unnecessary hurdles to make developers' lives miserable. (We do, but that's not why we did it this time!) CORS helps protect end users. It's super important and it is the way of the future. ...


3

Does that mean that if I have a "secret image" on Facebook (or any other resource with cookie session auth) any malicious site that I accidentally visit will be able to load that image in a hidden tag e.g. and read it? You are correct until the last two words. Yes, any site you visit can load the secret image into your browser. But it can not read it (...


3

It's possible to exploit Access-Control-Allow-Origin: null because resources loaded over things like data URI's and sandboxed iframes use the null origin. A PDF documenting the exploit confirms that Originull used a data URI document to exploit this header to achieve cross-origin access. For this reason, the W3C recommends avoiding returning this value for ...


3

Are you trying to secure the client or the server? It is my understanding that CORS is intended to provide a way for client-side applications (e.g. scripts) to access resources outside of the "same-origin-policy". Standards-compliant browsers should not allow scripts to retrieve resources outside of their domains (e.g. via AJAX request) in the absence of ...


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