I have a page that's loaded using https, and it embeds an iframe on the same domain, also loaded via https.
Inside the iframe, there are some XHR requests to an insecure http URL (the URL is actually to an IP address on the local network) that are being blocked.
Is there any way I can allow the requests to the local IP address? I only have access to edit the code in the parent frame. I can use php or javascript in the parent frame.
Unless you recompile your browser, CORS explicitly prohibits this and no browser would allow it, unless the local IP machine returns valid CORS headers.
See here for CORS headers info:
https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS#Simple_requests
Related
I'm running a local HTML "application" (HTML+JavaScript running in a browser via file:// protocol). Within that application I make JavaScript AJAX requests to a server. Is there a way to spoof the HTTP referer for those requests?
Currently, I have a browser extension installed which does the referer spoofing, however, this seems like overkill if the HTML is already executed by me using the file:// protocol (I guess it is forbidden for http(s)://-loaded HTML applications in order to give the user control over the referer policy). So is there a way for file://-protocol loaded pages? If no, why not?
So you can't make a request to another domain under the same origin policy. But does that apply to code you running inside the Chrome JS console with the page of that domain opened? And does that apply to a backend server app making a request to the other domain?
Question1: Chrome
When you run code inside Chrome JS console, you are running code in the context of a given page and you inherit the same security sandbox that the page has. All web pages are subject to CORS restrictions (cross origin resource sharing).
As a side note, cross origin request are allowed if the API you are calling explicitely allows them (which is implemented server side by setting some HTTP headers), or if you use another legacy cross origin technique (hacks) like JSONP.
Question 2: Server side
CORS is a browser thing, to protect web users against malicious JS acting on their behalf (for example, to reconfigure their home router), there is no such thing server side.
I'm attempting a slight variation of the Google+ web sign-in server side flow as described on the Google Developer's website.
Google's gapi code is giving this error message:
Uncaught SecurityError: Blocked a frame with origin "http://my-development-system.dev" from accessing a frame with origin "https://accounts.google.com". The frame requesting access has a protocol of "http", the frame being accessed has a protocol of "https". Protocols must match.
Am I right in saying that my local development system cannot be set up to use the https protocol?
This is not only to do with a differing protocol (HTTP on your site vs HTTPS on accounts.google.com), it is also because the domain does not match (and port for that matter), a restriction imposed by the Same Origin Policy.
This policy stops www.evil.com from loading a site such as www.bank.com inside a frameset (or popup window if framing is disabled) and then accessing the DOM. If the DOM could be accessed, this would be a massive security risk as any website could read your private data on another site.
It is possible to allow access by implementing a CORS policy and outputting server side headers to allow other specified domains to read content, however this would be on Google's side in your case. So unless https://accounts.google.com implements a CORS policy, you will not be able to make a client-side variation of the server side flow. Another barrier is that even if CORS was implemented it does not allow access to the DOM. However, you'd be able to retrieve content from another domain, protocol or port via AJAX calls. The target site would also have to output the Access-Control-Allow-Credentials: true header in order for authentication credentials (i.e. cookies in this case) to be sent with the request and the response read by your domain.
Can I use https for local development?
To answer your original question, the answer is yes. This can be a self-signed certificate for most purposes and it will not affect this particular error message in your browser (as you, as the browser user has chosen to accept and trust the certificate).
I was wrong in saying that
my local development system cannot be set up to use the https protocol
It can! Simply by using self certification SSL.
When script tries to access a frame from a different origin Chrome blocks it and throws exception as
"Uncaught SecurityError: Blocked a frame with origin 'provider domain' from accessing a frame with origin 'mydomain'. Protocols, domains, and ports must match".
I got this error after some update in google chrome. Any suggestions?
Direct Javascript calls between frames and/or windows are only allowed if they conform to the same-origin policy. If your window and iframe share a common parent domain you can set document.domain to "domain lower") one or both such that they can communicate. Otherwise you'll need to look into something like the postMessage() API.
This is a security update. If an attacker can modify some file in the web server (the JS one, for example), he can make every loaded pages to download another script (for example to keylog your password or steal your SessionID and send it to his own server).
To avoid it, the browser check the Same-origin policy
Your problem is that the browser is trying to load something with your script (with an Ajax request) that is on another domain (or subdomain).
To avoid it (if it is on your own website) you can:
Copy the element on your own server (but it will be static).
You can change your HTTP header to accept Cross-Origin content. See the Access-Control-Allow-Origin documentation for more information.
I'd like a post request to be sent once a certain text input field is changed, using javascript.
So here is my current code:
<input name="message" onchange="$.ajax({type: \"POST\", url: \"http://example.com/example.php\", data: \"message=\" + document.getElementsByName(\"message\")[0].value});" />
Now, it's working on a regular connection, but it's not working on a secured connection (SSL).
I mean, the page is secured, but the request is sent to a non secured page.
Is there a solution?
Set the target attribute of the form to point to a hidden iframe.
You won't be able to read the response, but you can make the request.
If you want to read the response, you will need to proxy the request through your own server.
As David points out, t is not possible to do an asynchronous POST to a service on another domain, due to the (quite sensible) limitation of the same origin policy. JSON-P only works because you're allowed to insert tags into the DOM, and they can point anywhere.
YOu can do cross-domain AJAX w/ GET using JSONP: JSONP CrossDomain
It also covers how to do JSONP w/ jQuery
same origin policy prevents a document or script loaded from one origin from getting or setting properties of a document from another origin. Two pages are considered to have the same origin if the protocol, port, and host are the same for both pages. http://rj3.net/mdc/sop
make sure you specify ssl in the ajax url, when the rest of your page uses ssl too e.g https
You can't send it from a https to a http site. any https asset (html or otherwise) can only be accessed by something on the same domain / ssl certificate. so, you won't be able to do what you are trying to do (https to http). so since your page is served on https the targeted http site can not access it due to the policy