112

Why is the same origin policy important? Assume you are logged into Facebook and visit a malicious website in another browser tab. Without the same origin policy JavaScript on that website could do anything to your Facebook account that you are allowed to do. For example read private messages, post status updates, analyse the HTML DOM-tree after you entered ...


61

In theory your suggestion is perfectly reasonable. If browsers blocked all cross origin POST requests by default, and it required a CORS policy to unlock them, a lot of all the CSRF vulnerabilities out there would magically disappear. As a developer, you would only need to make sure to not change server state on GET requests. No tokens would be needed. That ...


41

What does that really mean? Can you please give me a real life example? Attack example 1: Cross-Site Request Forgery (CSRF) with AJAX On page at evil.com the attacker has put (jQuery because lazy): $.post('http://bank.com/transfer', { to: 'ciro', ammount: '100' }) The attacker then convinces you to visit evil.com (YOU'VE GAINED A PRIZE!) Without further ...


41

Review: Same-origin policy First, let's clarify that the behavior observed here (the iframe does not render) is much stricter than the default same-origin policy. If you already understand that, skip down to "What's actually happening," below. To review, the same-origin policy prevents scripts from having programmatic access to the contents of cross-origin ...


38

The administrators of security.stackexchange.com have configured the site to not let it be framed on other sites. This is usually done to prevent clickjacking attacks, to prevent others from embedding security.stackexchange.com into a page full of ads, and to save traffic. You may read more about X-Frame-Options header here. This protection is off by ...


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


23

The cookie path doesn't provide any security (in most real-world situations). It is important to understand that the cookie spec is ancient technology. It dates back from the earliest days of the web. The security model of the web has evolved since then, and become more carefully thought-out. The security model for cookies hasn't evolved correspondingly. ...


22

The problem is not the request method: CSRF could also be done with a GET request. The problem is instead that authentication information like (session) cookies or the Authorization header are automatically included with the cross-site request, thus making CSRF possible. Therefore the mitigation would not be to prohibit such methods to be used within cross ...


19

Don't worry. I found it tricky to wrap my head around too. It turns out that Google Analytics can, in theory, do anything they want to your users. (<script> tags create an exception to same-origin policy restrictions) That's one of the biggest reasons XSS attacks are a Bad Thing™ and one reason Mozilla designed Content Security Policy which is now on ...


18

Your premise is wrong. Script tags and JSON don't bypass the same-origin policy. The same-origin policy says that evil.com should not be able to read the responses for arbitrary resources on victim.com. Note that Javascript from evil.com can trigger nearly arbitrary requests to be sent to victim.com (e.g., by creating an IFRAME pointing to http://victim....


18

Let us start by defining the term "origin". The origin of a page is decided by three unique factors: hostname, protocol and port number. For example, http://test.com and https://test.com have different origins as the protocol is different. Similarly http://one.test.com and http://two.test.com have different origins as the hostnames are different. The origin ...


16

The request can still be sent, just not read: Cross-origin writes are typically allowed. Examples are links, redirects and form sumissions [sic]. Cross-origin reads are typically not allowed. So only the reading of the response is protected by the Same Origin Policy, not the making of the request itself, although only certain headers can be used ...


15

This is a fairly common practice called a web bug, it is the main reason that mail clients do not automatically load external images (the second being to protect you from viewing unwanted spam images that could be unsettling; e.g., pornography). Basically when you load an email with external images enabled and a link to an image like <img src='http://192....


13

I don't see a reason to allow query strings to be passed cross domain. Is there a legit reason why most browsers allow this? There is nothing special about query strings. You could just as well exfiltrate the information in a path part, evil.example.com/PresidentSkroob/12345... or even the domain name. eg imagine setting the address to PresidentSkroob.12345....


12

It seems to me you're discussing two things: sandboxing on the desktop and then strategies for user content access in sandboxed applications. Sandboxing There are many sandboxing models out there, including the ones used by OSes: Windows 8 WinRT Store Apps OS X Sandboxed Store Apps iOS Apps Android Apps Some apps are shipped sandboxed, for instance ...


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

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


10

You said you are going to load the third-party content in an iframe, but will the third-party content be hosted from the same domain as your main content, or will it be served from a separate domain? If the third-party content is hosted on the same domain as your main page, then no, your approach is totally insecure. Content in an iframe has full scripting ...


10

JavaScript cannot read the content of other sites due to the same-origin policy. This is one of the most fundamental principles of web security and goes way beyond CSRF protection. Without the same-origin policy, any website could read our e-mails through our webmailer, have a look at our PayPal account, get our private information from Facebook etc. So ...


10

The goals of the SameSite flag are: prevent cross origin timing attacks (see eg here) prevent cross origin script inclusion (see here) prevent CSRF: SameSite cookies are only sent if the site the request originated from is in the same origin as the target site (in strict mode for GET and POST, in lax mode only for POST requests). limited privacy protection


9

Very common implementation is sharing sessions in the same process. E.g: you are logged into your bank account in tab A. When you copy the URL and paste it in the tab B (of the same browser-window), then: you are still logged in. The situation should be different when you start another process of your browser and paste the URL into another browser-window. ...


9

I partly disagree with Anders on But that is not how the internet was built back in the day, and there is no way to change it now. The developers of major browsers do have pretty much power to change the Internet and guide web developers to the direction they want. Obsoleting cross-site POST data would be possible, if it was seen as a major threat. ...


8

The actual answer should be, as always: it depends on your usage scenario. The Strict value will prevent the cookie from being sent by the browser to the target site in all cross-site browsing context, even when following a regular link. For example, for a GitHub-like website this would mean that if a logged-in user follows a link to a private GitHub ...


7

The Same-Origin Policy prevents scripts from reading content from a location that the script does not originate from. CSRF attacks rely on the fact that you can transmit requests to another domain, and reading the response doesn't matter. Many CSRF prevention techniques exploits the fact that the attacker cannot read the page before making the request. ...


7

The purpose of the same-origin policy is to protect the user (client) and not you (the server). Thus, it's irrelevant in this case. Attackers can use tools like wget, cURL, and even simply inject custom JavaScript in modern browsers using readily-available tools such as Developer Tools. Therefore, it doesn't matter if old browsers have certain behaviours or ...


7

Yes, you can use a custom header such as X-Requested-With to protect AJAX requests from CSRF. A customer header is not allowed cross-domain without CORS being enabled on your server. The Origin header could also be used, however the logic for this is not straightforward. If you wanted to add extra security to the custom header in the spirit of defence in ...


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

Yes, you do have to worry. While the subdomains are mostly isolated from your main domain (thanks to the same-origin policy, there are some exceptions that could pose a risk. One risk has to do with cookies. Script on bob.myapp.com can set a cookie for myapp.com. This cookie will be sent to myapp.com when the user visits myapp.com. This can be used for ...


6

When you execute a .html file using the file:// URI that script is run in the "file" zone. Which means that you can read files on the local file system using an XHR. (This is subject to change, and is also easy to verify) As with most "standards" it depends on what browser you are using. If you are using Firefox on any system, including android, ...


6

Yes, browsers enforce cookie domain scoping. There are a number of rules around when cookies may be sent, but the most basic rule is that cookies are only attached to requests to the same domain from whence they were set. Additionally, if the cookie has a path attribute it will only be sent with requests that match that path within requests to domain ...


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