Hot answers tagged same-origin-policy
16
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 ...
13
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 ...
8
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 ...
7
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 ...
6
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.
...
5
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 ...
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 ...
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
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, ...
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
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, ...
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
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. ...
3
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 ...
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
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 ...
2
There are a couple of ways, which allow a web application to transmit information to another server using the browser as relay. The same origin policy prevents other websites from accessing a sensitive website, but there are a number of access types that are not restricted.
For example:
The img-tag can be used to load an image from any server: <img ...
2
This depends largely upon implementation and security measures in place by the browser. In reality? Chrome or Firefox or Opera will probably prevent this kind of attack. It used to be an issue years ago, but generally now it is not. Could it still happen? Potentially. It would require finding a security bug in the browser and exploiting it to do this, ...
2
It's all a part of supporting cross domain ajax requests. You can do a GET, but the x-access-control-* headers determine whether the client can read the response or not.
If this was not possible, an attacker could still achieve the same by doing form submits with Get as method, or setting iframes/script/img tags with src attributes pointing to the same GET ...
2
The command document.myform.submit() triggers a browser action and navigation event. This means it is not restricted by the same origin policy. If instead you had tried to send the request as an XHR and interpret the result using the same running JS code, then you might have run into difficulty.
2
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 ...
1
Document types (or DOCTYPE) is a declarative and semantical element which is part of the W3C specification regarding markup languages documents (such as XHTML).
Their presence (or non-presence) within a markup document does not influence a whatever security aspect when they are being rendered and processed by a web browser.
If you are writing an XHTML 1.1 ...
1
The short answer is to put your application on its own domain. Don't share the domain with anyone you trust.
For example, instead of hosting your content at http://shared-hosting.tld/~gima/, host it at http://gima.shared-hosting.tld/ or http://gima.org/. Any good hosting company should support this. (If they don't, pick a different hosting company!) If ...
1
The sandbox attribute will prevent top navigation by default and can be configured to allow scripting using allow-scripts. The same origin policy in all current browsers should prevent any iframes that have content from a different origin (host) from accessing your application using JavaScript, the sandbox attribute will do it even for same-origin iframes.
...
1
Yes it will work and I see no reason why it would be illegal.
However, you've already hit upon the main problem with doing this - the person reading the email must push "Show pictures in this email" (or equivalent) for it to work.
There are companies out there that offer this service, such as SpyPig and DidTheyReadIt
1
Theoretically, the Same Origin Policy, and the HttpOnly and Secure attributes, induce the same general model, which is that your HTTP site and your HTTPS site will be seen by the browser as two distinct animals, thus cleanly separated. In practice, this is not entirely true; for instance, while the cookies from the HTTPS site will have the "secure" flag ...
1
If you visit this demo you'll see that the code detects itself in a frame (can be modified to detect what page its on) than changes the url. A url which may impersonate the parent site. (sidenote i notice google and yahoo came up blank and i believe its bc their headers send "X-Frame-Options:SAMEORIGIN")
I dont know much about controlling windows so it may ...
1
I don't think this has anything to do with Active Directory. It is a question about internal web applications.
Yes, I imagine there is some security benefit to placing the internal apps on totally separate domains. However, this may be annoying from a usability perspective (it may be more convenient for your users to have all the services under a single ...
1
The browser can't tell if .onion is a "special" tld or a "normal" one so there is no reason for him to change his SOP.
It's like asking if there is a different behavior with *.com than with *.us ;)
If you use Tor as a proxy it's just like a "normal" socks proxy. The sites should work as expected without any changes.
Only top voted, non community-wiki answers of a minimum length are eligible
