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?
Related
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
I have a web method that I want to call from my C# app and was provided with a Javascript example, showing how to call the method. I have established that running the Javascript from my desktop runs into CORS problems - i was able to run the sample when I put the javascript on the server and ran it from the same folder as the web method.
Will my C# app run into the same CORS issue? or will it be ok because only the browsers have the built in CORS security?
--Edit--
I've been using System.Net.Http.HttpClient and http://restsharp.org/
Am I correct in assuming that these two objects are wrappers around a web browser? and that they will have issues with CORS?
I really don't want to have to write Sockets code.
Due to security reasons browsers restrict cross-origin HTTP requests initiated from within scripts on the browser. For example, XMLHttpRequest follows the same-origin policy. That means a web application using XMLHttpRequest could only make HTTP requests to its own domain. This prevents application from being vulnerable to CSRF attacks. However, there are cases when applications need to access resources from different domain. This is when CORS comes into play to allow cross-domain requests.
Having said all that, your C# app should be able to call the WEB API without any CORS issues as long as it's a socket to socket communication (not via browser).
Some where in deep recess of my mind I remember browser related cors will always be blocked unless noted or changed like for example if you're in chrome and have the cors extension allow browser cors control, but on the server side, their is nothing preventing servers from interacting with one another.
but it depends on what is allowed on the headers
I'll try to produce some documentation that confirms that.
https://spring.io/understanding/CORS
The request includes an Origin header that indicates the origin of the client code.
The server will consider the request's Origin and either allow or disallow the request. If the server allows the request, then it will respond with the requested resource and an Access-Control-Allow-Origin header in the response. This header will indicate to the client which client origins will be allowed to access the resource. Assuming that the Access-Control-Allow-Origin header matches the request's Origin, the browser will allow the request.
On the other hand, if Access-Control-Allow-Origin is missing in the response or if it doesn't match the request's Origin, the browser will disallow the request.
webui-aria2 is a tool that allows controlling aria2 (powerful download tool) through rpc methods from a browser.
Using http://ziahamza.github.io/webui-aria2/, one can control aria2, provided the application is launched with the --enable-rpc option. aria2 basically starts an HTTP server listening on localhost:6800.
Great but I am surprised that the browser (both webkit and gecko) allows a page hosted on github.io to make requests to localhost. How come it does? Isn’t this a serious vulnerability?
Requests to localhost from github.io will be treated like any other cross origin request.
JavaScript embedded on the site can't read the data across origins unless either:
Explicit permission is given with CORS or
A hack such as JSONP is used
Presumably the server uses one of those techniques.
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.