Im developing a game with JavaScript and canvas. And recently since i implemented clicks i have been receiving this message in firebug:
CSP WARN: allow directive is deprecated, use the equivalent default-source directive instead
Its not affecting the game at all, but i was wondering what it meant? and could it affect my game eventually?
I found this online, but i can't make any sense of it, and im not totally sure if its talking about the same message that im receiving
LINK
Thanks
CSP is Content Security Policy, these are HTTP headers that can for example restrict JavaScript execution in the browser. The warning points out a non-critical problem with the policy.
To look at the headers you could use curl -I on your server. The "Content-Security-Policy", "X-Content-Security-Policy" and "X-WebKit-CSP" fields are relevant.
Since you don't know about CSP I assume you are not administrating the web server, you might want to talk to the person in charge.
That is old syntax for CSP. You don't say: "allow 'self'" anymore. You say:
Content-Security-Policy: default-src 'self'
Related
I am building a web application that uses voice recognition & text-to-speech that performs actions/displays a wide variety of data through an HTML page (built with JS (jQuery for AJAX)/HTML/CSS.) This web application is being hosted on HTTPS server that is not on my local network.
I have set up and configured some smart lights called "Philips HUE Lights" that are equipped with a RESTful API that can only be controlled through the local network (not visible outside of the local network.)
I am able to send commands to the device by visiting the CLIP debugger/API tool (local ip) "http:////debug/clip.html" that is included with their product. I am able to send HTTP commands to the "Philip HUE Bridge" which is the device that issues the commands to the lights. All of the commands work when I use their API tool (GET, "PUT, POST, DELETE) visiting the locally hosted url shown above.
However when I try using a jQuery AJAX request "GET"/"PUT" from my web application that is hosted on my HTTPS server, the command fails. I have tried setting the AJAX function header property with "Access-Control-Allow-Origin: *". I have also tried setting the "crossDomain" property to true in the AJAX function. I also have tried setting the "dataType" property to both "json" and "jsonp" and it still won't work.
I am visiting my HTTPS web application through a computer that is connected to the local network that the "HUE Bridge" is connected to. Given that I am using a computer on the same network, I thought this might work...
I have read a lot of other posts/information on the internet but can't seem to find a definitive answer. I wanted to ask some of you more seasoned people:
Is what I am trying accomplish even possible given the scenario I described above? Or will I have to achieve this in a different manner?
Any help/suggestions are much appreciated. Thanks.
You are running into "Mixed Content" security issues.
Basically when you are hosting a page on a secure URL (https) you cannot access unsecure (http) resources without getting a mixed content error.
This error is visible in the console of your browser (usually accessed by F12), when something is not working during webdevelopment always check the console for errors.
To hack around this you can temporarily disable the security and allow the unsecure request. For example Chrome shows a shield in the addressbar which you can click to temporarily disable the warning. Firefox shows a clickable warning overlay on the lock icon in the addressbar.
This might be a temporary workaround for development, but you cannot expect your users to disable security.
A solution should be to send a Content-Security-Policy header. Based on documentation from http://content-security-policy.com/ the following header should allow XMLHttpRequests to any resource:
Content-Security-Policy: connect-src *
However since I do not have enough control to modify the headers on the webserver where my files are hosted I could not test this.
Before using this method make sure you understand the security implications when you send this header.
I'm creating something like an app ecosystem where each app runs in a sandboxed iframe and processes sensitive data. I want to allow scripts, but I don't want the iframe to communicate with any 3rd party server or it might leak this data.
Is there a way to enforce a whitelist like you can with Chrome extensions? Am I going about this the wrong way?
You will want to limit what domains can be connected to for all things, not just XHR (an img tag can leak data just as well). Modern browsers offer a feature to do this called Content Security Policy.
In particular, to whitelist domains, you will want to return a header like the following:
Content-Security-Policy: default-src 'self' safedomain.com securedomain.com
Like anything security related, make sure you read up on the topic and understand the implications of what you are dealing with. Copy-pasting code from a Stack Overflow answer is not enough.
Also remember that some older browsers do not support this feature and will silently not enforce it, so you will probably want to detect this and prevent those browsers from exposing sensitive data.
I'm using a script that detects Javascript errors and reports them to my backend. However I am getting cryptic "script error" messages, which is not very helpful for debugging.
According to Cryptic "Script Error." reported in Javascript in Chrome and Firefox the reason is because the script that threw the error is served from a different origin than my site.
Since I'm using a CDN all of my scripts are effectively served from another domain. Is there a way to get more useful error messages while still using a CDN?
Also everything is served over SSL so I would like to retain this ability.
I had a similar problem: my scripts are served by a subdomain and fall under the same origin restriction. However, I solved this by:
1) adding every script tag like this:
<script type="text/javascript" src="http://subdomain.mydomain.tld" crossorigin="*.mydomain.tld" />
2) modifying the apache httpd.conf by adding the following inside every vhost (you must enbable mod_headers):
<IfModule mod_headers.c>
Header add Access-Control-Allow-Origin "*.mydomain.tld"
</IfModule>
On one of my server I was not able to make this functional except by replacing
*.mydomain.tld
by
*
Be aware of the flaws with potentially allowing * to phish extended information. Documentation on CORS, same-origin, img & fonts, cdn is available but very fewer about script tag crossorigin details is available.
Hope this helps ...
Try using jsonp for the dataType attribute in jQuery.ajax. The remote server will also need to support jsonp. It will get around the browser security preventing XSS.
Alternatively, you could use an IFrame and use jQuery within each window, but use HTML5 postMessage to communicate back and forth between the windows on two different domains.
Or, if you control both servers you can set the headers for same origin.
Jsonp has been my weapon of choice for this kind of problem. The others are just a legitimate.
I am posting this question on Super User as well. In my opinion this question overlaps the two...
I am creating a simple JavaScript wrapper for CouchDB's REST-ful interface, but I am stuck on same-origin policy issues.
So far I've been developing my code to work locally - and only as a proof of concept - on Mozilla FireFox. My server is running on localhost, port 5984.
To disable cross-origin policy in Mozilla FireFox you can use the PrivilegeManager, but it only gets me half-way in the sense that I can't do PUT requests against my server...
/*
* Including this in my JavaScript file only seems to disable cross-origin
* policy checks for POST and GET requests in Mozilla FireFox.
* PUT requests fail.
*/
netscape.security.PrivilegeManager.enablePrivilege(
"UniversalBrowserRead UniversalBrowserWrite"
);
Is there any way that I can configure my server to hide it's location so I won't have to implement browser-specific work-arounds to avoid same-origin policy issues? If not: what browser work-arounds exist to disable same-origin policy completely?
Unfortunately, any browser workarounds to disable same-origin policies are likely to be treated as serious security bugs and fixed as soon as possible.
See if you can come up with a way to work within the same-origin policy without trying to bypass it.
Can you serve your example scripts on the target server? Could you build a reflection script that would load the target script on your server after a local script on the users computer uploaded whatever they modified?
There should be a good solution that doesn't involve bypassing the same-origin policy. Trying to hack your way around it is a good way to ensure that your code doesn't work properly in future browsers.
I strugled with that issue too, trying to run automated tests on a local html file connecting to a virtualized CouchDB server, here's my solution:
I created a small implementation (and open sourced it) of the simplest solution when you can't enable CORS on the server,
you need to upload a .js and an .html file to the target server, (you can use any security mechanism to restrict access to this file if you want). Or you can change some simple parameters on the html file to restrict by domain.
On your page you use the same script to create an invisible iframe where the hosted .html is loaded, and proxy certain methods (sort-of RPC) thru that iframe using window.postMessage(), by default jQuery ajax methods can be proxied without extra configuration.
All this with one line of js code :)
FrameProxy at GitHub
(fell free to use it and fork it!)
This error just started popping up all over our site.
Permission denied to call method to Location.toString
I'm seeing google posts that suggest that this is related to flash and our crossdomain.xml. What caused this to occur and how do you fix?
Are you using javascript to communicate between frames/iframes which point to different domains? This is not permitted by the JS "same origin/domain" security policy. Ie, if you have
<iframe name="foo" src="foo.com/script.js">
<iframe name="bar" src="bar.com/script.js">
And the script on bar.com tries to access window["foo"].Location.toString, you will get this (or similar) exceptions. Please also note that the same origin policy can also kick in if you have content from different subdomains. Here you can find a short and to the point explanation of it with examples.
You may have come across this posting, but it appears that a flash security update changed the behaviour of the crossdomain.xml, requiring you to specify a security policy to allow arbitrary headers to be sent from a remote domain. The Adobe knowledge base article (also referenced in the original post) is here.
This post suggests that there is one line that needs to be added to the crossdomain.xml file.
<allow-http-request-headers-from domain="*" headers="*"/>
This likely causeed by a change made in the Flash Player version released in early April, I'm not too sure about the specifics, but I assume there were security concerns with this functionality.
What you need to do is indeed add that to your crossdomain.xml (which should be in your servers webroot)
You can read more here: http://www.adobe.com/devnet/flashplayer/articles/flash_player9_security_update.html
A typical example of a crossdomain.xml is twitters, more info about how the file works can be found here.