69

Resources are cached by their URL, and the protocol (http:// or https://) is part of the URL. Since the protocol differs, the URL must also differ, and you have two separate cache entries.


62

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


46

It is perfectly fine if a http:// and a https:// resource provide different data, even if everything but the access method is the same. For example access to http:// will today often result in a redirect response while access to https:// provide the real content. A browser will therefore cache these resources independent from each other.


44

What does that really mean? Can you please give me a real life example? Attack example 1: Cross-Site Request Forgery (CSRF) with an HTML form On page at evil.com the attacker has put: <form method="post" action="http://bank.com/trasfer"> <input type="hidden" name="to" value="ciro"> <input type="hidden" name="ammount" value="...


42

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


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


27

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


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


17

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


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

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

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


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

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


10

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


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


8

Summary: The primary cache key for any standards-compliant browser is an absolute URI The absolute URI begins http: for all insecure requests and https: for all secure requests Consequently, a resource fetched securely can never use the same cache key as a resource fetched insecurely The current standard for HTTP is split across multiple "RFC" documents, ...


7

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


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


7

This is considered acceptable because scripts are limited in interacting with cross origin images unless crossorigin="anonymous" is set, which tells the browser not to send cookies or other credentials when retrieving the image. Without setting crossorigin="anonymous" scripts are allowed to retrieve dimensions, but not pixel data from the image due to the ...


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

From my understanding, the same-origin policy will protect AJAX users from each other, but not necessarily your main site. For example, user1.myapp.com will not be able to post requests to user2.myapp.com, but will be able to post requests to myapp.com. You could solve this by forcing the main site to use the 'www' subdomain (www.myapp.com) and forward any ...


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


6

The same-origin policy is a client-enforced restriction. Certainly, it's possible for a particular client to fail to enforce this restriction. Note that doing so would bring the client out of compliance with W3C standards for the XMLHttpRequest API and iframe behavior. Note that any program that can formulate an HTTP request can send a request to your site. ...


6

Going off your example of Twitter and Facebook, both of their army of scripts aren't reading the DOM or interacting with other scripts. If either tried to, say, get the value of a variable or something like that, then they'd be violating SOP. The origin of a script is where it's included. So if you included Google's analytics scripts on your page it can ...


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