How secure is the "same origin policy"?

I am aware that to read the contents of an iframe, the domains, p开发者_开发知识库rotocols, and ports must match.

However is this enough to guarantee that an "unknown malicious website" will not be able to get past this restriction?

Basically I'm worried that a very smart anonymous hacker would be able to have an iframe on HIS website, pointing the iframe's url to my webpage, and extract the contents of my webpage.

This is the resource you're looking for:

https://code.google.com/p/browsersec/wiki/Part2#Same-origin_policy

It's quite detailed, but that's kind of the point. It's actually a few years out of date so you won't find IE9 in there either.

It goes into detail about the major browsers/vendors and what their specific SOP rules mandate. For instance, what DOM controls you can do, what HTTP headers you can do, what you can do with cookies, etc.

The same origin policy only applies to people who have it enabled in their browsers. Browsers allow cross domain access if the person disables the security feature.

If you use a frame buster, you can limit the attack, but there is no way to 100% protect yourself when a user removes the security.

The Same Origin Policy is very secure and the internet as we know it would fall apart without it. What you are desribing is a clear violation of the Origin inheritance rules. For added security i would set the x-frame-options to prevent chickjacking.

The same original policy has historically done a good job protecting secrets associated with a domain, but XSS and other injection attacks are widespread in certain kinds of websites, especially social ones that mix content from different sources. HTTPOnly cookies are a decent way to protect against one kind of credential theft via injection, but only on relatively modern browsers.

The same-origin-policy does not stop abuses of authority not related to secrets associated with a domain.

1. Drive by malware downloads such as those that affected the NYTimes
2. History sniffing to build a dossier of private info on browsers.
3. Intranet port scanning to learn about local networks.
4. Phishing to redirect to a fake version of a site to steal credentials.

These attacks can be combined. A smart attacker could use history sniffing to detect that a user uses your website, and then phish that user to get access to credentials for your site. The same origin policy will not prevent this, though some browsers have implemented specific protections; Mozilla implemented history sniffing safeguards.

The same origin policy is intended to protect users that are visiting another site from XSRF-style attacks against your site. It is not intended in any way to protect the content on your site (e.g., iframes or a proxy would allow your content to be loaded into another web page).

For example, if you were running a banking site, it would protect someone who is visiting evil.com from automatically transferring all their funds to an offshore account via an AJAX request, because the request would have originated from a different domain.

So it's important to understand that the policy is enforced by the browser, not the server. If a user were to disable the policy in their own browser, they are only opening themselves to potential attacks. It has no effect on how secured your content is, however.