I'm getting this error :
Uncaught SecurityError: Blocked a frame with origin "https://lss-servicedesk.techteam.com"
from accessing a frame with origin "http://mydomain.com".
The frame requesting access has a protocol of "https", the frame being accessed has a protocol of "http".
Protocols must match.
<FORM ACTION=https://lss-servicedesk.techteam.com/CAisd/pdmweb.exe METHOD=POST onsubmit="return checkform(this);">
Is there any way to get around this problem ? thanks in advance...
You're getting 2 errors here. The first one is a cross-domain problem, and you won't be able to fix that. It is impossible for your site to access the loaded iframe's site at all. Otherwise, the browser would be really insecure, allowing one site to very easily get the user's settings on another site by just loading an iframe. So, you can't change anything within the iframe. The only thing you can do to the iframe's contents is iframeElement.src = '//otherurl.com'; - changing the source url of the iframe.
To fix the second problem, you can do the following: Instead of using http:// or https:// in the url you're defining in your scripts or forms, you can just use //. That will automatically 'fill in' the same protocol as the one you're using now. So, if you're on http:// at the moment, it'll load the iframe in http:// too, and vice versa.
I had the same issue with two different domains going to my webserver. Both of them had DNS settings set to redirect domain.com (without www) to http://www.domain.com. The one domain had issues similar to yours but it turned out that it was due to a DNS error where we had set FRAME to yes. After settings FRAME to no, it solved both issues (frame error and http/https error). It is a little thing but it caused the exact same error so just wanted to mention it as another possibility for anybody else who should stumble across this thread.
Related
I have a confusion about the Same Origin Policy(SOP).
For example, http://bad.com/bad.html with a bad.js, and http://good.com/good.html with a good.js. I open both urls in my chrome with two tabs(tab1, and tab2).
In the good.html(opened in tab2), there is a element <input id="token-id" type='text' name='token' value='123abc'>
Now the question is if there is no SOP, whether it's possible to read the element input value from bad.html(opened in tab1) with some code like document.getElementById('token-id').value() in bad.js.
Another question is if the above question's answer is 'no', I can't understand this sentence in wiki https://en.wikipedia.org/wiki/Same-origin_policy#Security_Concerns.
Regarding the sending of new transactions, even CSRF protections by the banking site have no effect, because the script can simply do the same as the user would do
As we can't get the csrf token. why it does't work. Server can figure the real post request by verify the csrf token.
Do I misunderstand the csrf protection or the SOP itself?
Thanks if anyone can help me figure out these confusion.
Now the question is if there is no SOP, whether it's possible to read the element input value from bad.html(opened in tab1) with some code like document.getElementById('token-id').value() in bad.js.
No — since there is no reference to the other tab.
If the tab being read from was opened via window.open from the tab doing the reading (instead of manually), then the token could be read.
Happily, the Same Origin Policy does exist, so we don't need to worry about that.
Regarding the sending of new transactions, even CSRF protections by the banking site have no effect, because the script can simply do the same as the user would do
The CSRF token contains information only available to the browser and the friendly site.
Since the attacking site can't read the token, the attacking site can't construct a request that includes it. The friendly site can determine that the request constructed by the attacking site is untrustworthy because it doesn't include the token.
If the Same Origin Policy didn't exist, then the attacking site could read the token, which would render the token useless.
Since the Same Origin Policy does exist, that isn't a concern.
You are misunderstanding some things, the SOP says that if you open http://bad.com/bad.html and that page loads and executes bad.js, that javascript can make an AJAX request to bad.com, but any request pointing to good.com will be blocked unless good.com accepts it explicitly (by using CORS protocol).
The reason is that any request to any site may include the cookies that the browser has stored related to that site, so bad.com could use the session that you did not close on good.com to do something harmful.
So regarding your questions: No, a tab is not aware of other tabs unless they are related (parent - child), so a page cannot modify the behavior of another one. And the SOP ensures that a page cannot impersonate as another one
I am trying to build a phonegap app, which acts as a mini browser for a clients website. The clients customers would open this app, it would have a list of favorites. They could click on one of these favorites and it'd open that favorite within the minibrowser.html page. The minibrowser.html, has a favorites button at the top, then it has an iframe that should act as the browser. I open the favorites by changing the iframes src. I can capture the title/url with this code
$iframe.on('load', () => {
try {
console.log($iframe[0].contentDocument.title);
currentUrl = $iframe[0].contentDocument.URL;
console.log(currentUrl);
} catch (e) {}
});
But the problem occurs when the webpage within the iframe trys to access window.top with this line
window.top.scrollTo(0,1);
That throws the error:
Uncaught SecurityError: Blocked a frame with origin "https://webapp.company.com" from accessing a frame with origin "file://". The frame requesting access has a protocol of "https", the frame being accessed has a protocol of "file". Protocols must match.
Is there anyway to spoof window.top for the iframe? Is there anyway of doing this without hosting the phonegap code on webapp.company.com. I do not have access to webapp.company.com
Due to the nature of the HTTPS protocol, it's mandatory for the server to specify if it's accepting third-party frame distribution (something like what you're trying to do). This is done as it's a major flaw when it comes to security.
Imagine, a person may use a simple variant of this hack to show a part of the Facebook page, and capture your account details. This policy prevents that.
A simple workaround would be to use some sort of URL shortener, or a proxy forwarder.
For a quick example: http://codepen.io/nakshatra334/pen/OMgLLP and open up the console; you'll see the content security policy.
The header, X-Frame-Options is denying this as people may use this for illicit purposes.
Good day.
Site https://mult-privet.com/
In my Chrome console, I see this error:
[blocked] The page at 'https://yandex.st/share/ya-share-cnt.html?url=
https%3A%2F%2Fmult-privet.com%2F&services=yaru,
vkontakte,facebook,twitter,odnoklassniki,moimir'
was loaded over HTTPS, but ran insecure content
from 'http://connect.odnoklassniki.ru/dk?st.cmd=extOneClickLike&uid=odklocs0&
ref=https%3A%2F%2Fmult-privet.com%2F':
this content should also be loaded over HTTPS.
Why should this URI also be loaded over HTTPS ?
Why am I getting this error, and how do I remove it?
On the right side of the Chrome address bar, click on the shield icon, then click "Load unsafe script". Done!
Why this content should also be loaded over HTTPS ?
Because:
if you have unsecured content being injected into an otherwise secure page, the unsecured content can be intercepted, replaced and thus render the secure content insecure
the browser can't honestly continue to tell the user that the page is secure when parts of it are not
Tell me please why i get this error
You are loading HTTP without SSL content into an HTTP with SSL page.
and how remove this?
Use HTTPS for everything on the page.
Why you are getting this error
Quentin's answer explains this pretty well. I would clarify that you are getting a mixed content error.
How to fix this error
Although Quentin's answer offers the most ideal fix, it is sometimes more convenient to solve mixed content errors using a protocol-relative URL, where the http[s]?: prefix is removed from the URL. For example, change this:
http://connect.odnoklassniki.ru/dk?st.cmd=extOneClickLike&uid=odklocs0&
ref=https%3A%2F%2Fmult-privet.com%2F
to this:
//connect.odnoklassniki.ru/dk?st.cmd=extOneClickLike&uid=odklocs0&
ref=https%3A%2F%2Fmult-privet.com%2F
by removing the http: prefix. It will let the browser determine the protocol. When using the protocol relative URL in the above example, if you are on an SSL encrypted page the browser will access the https://connect.odnoklassniki... URL, and on a non-SSL page, it will access the http://connect.odnoklassniki... URL, assuming that both protocols work for the URL.
There are, however, some pitfalls in using protocol-relative URLs, like ensuring that the server behind the URL is capable of serving both http and https protocols. This SO post addresses more reasons to use protocol-relative URLs.
Despite of the fact that I have seen many articles (including in stackoverflow) demonstrating up how to bypass javascript's same origin policy assigning document.domain property, its not working. I also read in W3C specs that document.domain property is read-only and not all browsers accept setting it and I think that is the cause I can't get that working!
I have a page (domain d1.y.com.br) and I need to invoke a button in an embedded iframe's page (domain d2.x.com.br). I'm setting the parent document.domain attribute to subdomain 'x.com.br' but I'm still receiving the 'access denied' error message in firebug console.
I have also read about JSONP but its not the case here. I really need to interact with iframe's DOM and not only get data from there (using proxy service).
Does really exist any way to bypass same origin policy to interact with the iframe's DOM ???
The proper way to send data between iframes (especially across domains) is using postMessage(). https://developer.mozilla.org/en-US/docs/Web/API/window.postMessage
That effectively "bypasses" the problem by having the recipient of the message verify that the caller has the correct domain - based on whatever rules it wants.
I have some JavaScript that is sharing a request between two separate servers on the same domain.
Is .com a requirement for the domain in JavaScript?
In this case both the servers are on the .abc.tyy domain with the tyy being what would normally be .com
Wondering if I can only use .com for the domain? I am getting a permission denied error, but this code works fine on other separate servers on the same domain(.com).
Updated:
Here is exactly how I'm using this:
123.abc.tyy has a script that loads properties that I want to access.
The script on 123.abc.tyy at opening script tag, sets the document.domain to 'abc.tyy'.
When I call the 'getUser()' function in 123.abc.tyy's script FROM 234.abc.tyy I am getting a permission denied error.
The way I am calling 'getUser()' is:
I access http://123.abc.tyy in a browser, and the site allows me to specify a URL to load in one of it's frames. I point that URL to http://234.abc.tyy/BeginLoadPatient.aspx" in that page I am doing the following:
window.location = 'http://234.abc.tyy/LoadPatient.aspx?PatientId=' + getUser() '; with getUser being a function originating in 123.abc.tyy
If I add 234.abc.tyy and 123.abc.tyy to my trusted sites, everything works fine - is this skipping over the same origin policy?
No, the SOP doesn't care what the domain is, only that it represents the same origin. (Could it be that you have the .com domain hard-coded somewhere?)
Note that there's more than the domain to consider. The Same Origin Policy looks at protocol, port, and host as well. So aaa.abc.tyy and bbb.abc.tyy are different origins.
If you're in control of the servers involved, you might look at Cross-Origin Resource Sharing, but unfortunately CORS is only implemented in modern browsers (and on those versions of IE where it's supported, it's only supported if you use it explicitly).
Another option, of course, is JSON-P, which has the advantage of working cross-browser right now.
Another thing to look at is document.domain, details here and here.
Update after your edits:
The script on 123.abc.tyy at opening script tag, sets the document.domain to 'abc.tyy'.
When I call the 'getUser()' function in 123.abc.tyy's script FROM 234.abc.tyy I am getting a permission denied error.
You'll need to set document.domain to "abc.tyy" in BeginLoadPatient.aspx as well.
If I add 234.abc.tyy and 123.abc.tyy to my trusted sites, everything works fine - is this skipping over the same origin policy?
I wouldn't be at all surprised (although to me it would be pretty dodgy), but have no first-hand knowledge of it. Would be easy to test.