I want to load a page from a domain inside an iframe in another domain's page, and then access its content with JS. of course, this would be XSS so I'd get the "Permission denied to get property HTMLDocument..." error. The thing is, I want to do this on my own browser, not in a public access site (i.e. I don't need it to protect me from myself), so I'd gladly turn this kind of security off for a while. I'm using firefox 3.5 and would like to know if this can be done, with this or other browsers.
问题:
回答1:
Update Nov.2016 A simpler way to disable same-origin policy in Chrome is to start it with the following flags:
google-chrome --disable-web-security --user-data-dir
Update:
Be aware of the scope where you request elevated privileges. Method one works as expected, the catch is to request elevated privileges in the same scope where you will use it (in the same function, in global scope ...), it won't work in any other scope.
I updated the example with working code.
It's in the documentation:
Privileges are granted only in the scope of the requesting function. This scope includes any functions called by the requesting function. When the script leaves the requesting function, privileges no longer apply.
http://www.mozilla.org/projects/security/components/signed-scripts.html
I am trying to do the same for my company intranet sites (we have a 47 different domanis based on the server location and it will be easy to disable 'same origin policy" for those sites only in employes Firefox).
Acording to the documentation from mozilla site, these methods should work ... I have found from googling, that this was true for Firefox 2, I tested in FF3 & FF4 and doesn't seem to work. You should try this, maibe il will work for you,i'm still looking for a solution
Method 1.
Edit
about:config
and setsigned.applets.codebase_principal_support
totrue
(this will allow unsigned scripts to ask for elevated privileges)In your parent script request elevated privileges:
<html><head><script
type="text/javascript">
function xss()
{
try {
netscape.security.PrivilegeManager.enablePrivilege("UniversalBrowserRead");
} catch (e)
{
alert(e); // console.log(e) if you have firebug
}
alert(document.getElementById('frame').contentWindow.document); // console.log()
}
</script></head>
<body onLoad="xss();"> <iframe id="frame"
src="http://example_1.com"></iframe>
</body></html>
3 . Now when you load the page FF will ask your permision to give the script privileges:
Allow it, and you should get an alert with text: [object HTMLDocument]
Before doing any modification if I try to access ....contentWindow.document
i get this error:
Error: A script from "http://example.com" was denied UniversalBrowserRead privileges.
After I got this:
Permission denied for <http://example.com> to get property Window.document from <http://example_1.com>.
If you like working in command line, you can skip step 1 and 3 and edit presf.js file ( on Linux: /home/$yourUser/.mozilla/firefox/$yourProfile/prefs.js ) and add 4 lines
user_pref("signed.applets.codebase_principal_support", true);
user_pref("capability.principal.codebase.p0.granted", "UniversalBrowserRead");
user_pref("capability.principal.codebase.p0.id", "http://example.com");
user_pref("capability.principal.codebase.p0.subjectName", "");
Method 2.
Try to add a policy to allow sites to bypass SOP for this edit prefs.js and add these lines:
user_pref("capability.policy.policynames", "example");
user_pref("capability.policy.example.HTMLDocument", "allAccess");
user_pref("capability.policy.example.sites", "http://example.com http://example_1.com");
Unfortunately even method 2 fails to do the job.
I'm still looking for a solution, If I will find anything new, I will update the answer.
回答2:
I know this is going to sound smart-alecky, but I really don't mean it that way. It's an honest suggestion if it'll work for you, because I doubt that any browser will let you edit settings to make it this vulnerable.
Use an older browser. If necessary, install an older OS on a virtual machine to get a browser old enough not to have this defense.
回答3:
Greasemonkey's version of XMLHttpRequest allows requests to cross same-origin policy boundaries. This might do the trick, since it's just for your own local development.
Also, early versions of Greasemonkey inadvertently exposed this function to content scripts, which was, of course, a major security error. It would be possible to develop an extension that did the same thing or that only exposed the custom function in certain situations.