Tag Info

Hot answers tagged

35

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


34

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


15

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


15

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


14

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


10

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


9

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


9

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


8

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


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


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

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


5

First of all you should read Part2 of the Browser Security Handbook, specifically the same origin policy for DOM access and XMLHttpRequest. The same origin policy is bounded by the domain name, not the path and this fundamental rule will likely never change. If two web applications share the same domain then they will be able to read each-others data ...


5

Ahh! I think I can explain. foo.com can navigate the browser to any page or domain. Thus, foo.com can submit a form that posts to localhost, even though that's a different domain. No problem. After navigating to a new page, the browser will happily display the contents of the new page to the user. For instance, after submitting the form to localhost, ...


5

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


4

I want to identify browsers, servers, or implementations that are immune from related domain cookie attacks (e.g. a.example.com vs b.example.com). That is simple: there are none. It's a basic part of the design of cookies that a.example.com gets to write cookies scoped to example.com, that will be picked up by b.example.com. There are browser ...


4

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


4

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


4

Embedding an image in an email would (if unblocked) fire a HTTP GET for the resource linked in the src field. When it does so, one can get the ordinary "Google Analytics level" of information (+ IP), i.e. Referrer, Browser version, etc. If the resource does not exist, there will still be a log entry of the GET at the server side when trying to resolve it.


4

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


4

A chain is only as strong as its weakest link. So make sure you trust your Content Delivery Network (CDN). I guarantee it is more difficult for a hacker to penetrate Google's servers than yours. Cloudflare is another example of a security minded CDN. Mixed content and Insufficient Transport Layer Security can compromise accounts. Transmitting any page ...


4

You should use the img-tag instead of iframe or object. If you do so, the following security restrictions are applied (independent of the origin of the file) to the SVG: JavaScript is disabled. External resources (e.g. images, stylesheets) cannot be loaded, though they can be used if inlined through BlobBuilder object URLs or data: URIs. :visited-link ...


4

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


3

That is the point of CSRF, your browser makes the request as if it was initiated by a user. In a real CSRF attack situation the GET or POST will be inside in invisible iframe so that the victim isn't aware that they have been compromised. In this case the attacker's JavaScript or ActionScript running on the victim's browser cannot read the response of ...


3

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


3

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


3

The best way to approach this is to get a copy of the JavaScript from the 3rd party and then host it locally on your site. That way you don't run the risk of a compromise of the 3rd party affecting you directly (although it still could depending on what the JavaScript does I would think). Failing that I think you'd be down to auditing/reviewing the ...


3

It means that the standard defenses against XSS when serving user-uploaded content are not sufficient. The standard defence against XSS when serving user-uploaded content is to serve it from a different address (ideally different domain and IP address completely, but a subdomain stops some attacks at least). That is, you allow it to fall victim to XSS, ...


3

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



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