Security hole where a site may steal user scripts about dotjs HOT 6 CLOSED

Instead of using the Referer, a better way to secure the scripts would be to do away with the wildcard Access-Control-Allow-Origin: * and instead dynamically set the Access-Control-Allow-Origin header to be the same as the origin for the requested script (via the Origin request header), and for the server to check of the request URI matches the Origin. For example, making a request from https://example.com/ to http://localhost:3131/example.com.js should return a response with Access-Control-Allow-Origin: https://example.com

from dotjs.

Are you able to provide a proof of concept? Maybe this is naïve, but wouldn't a firewall prevent web pages from hitting your localhost?

from dotjs.

No, the firewall shouldn't matter because it's the web browser on your own system that is accessing your local web server, so there's no firewall to go through.

Here's a proof of concept: http://jsfiddle.net/westonruter/446tk/ This is what I had done via XHR in the console when I first discovered this issue, and since I've uninstalled dotjs, so I can't verify this test case works personally. But, if you see the script spitting out the contents of your default.js along with the contents for any example.com.js you may have, then there is a leak.

from dotjs.

There are also some semi-related issues regarding the use of expand_path:

• Forward slashes are removed from the input string, which prevents directory traversal on Unix-based systems. However, on other OSes (ie: Windows), backslashes are also valid directory separators.
• Even on Unix-based systems, expand_path allows for the ~ special character. The WEBrick server will return a 500 error with the text "Is a directory - /home/username" (where username is the username of the user running the server) if the path "~" is used. ~random_username lets you enumerate usernames on the system. There is no file disclosure though.

from dotjs.

Hi, I am able to confirm the security hole mentioned using the current Chrome Beta (13.0.782.55) with dotjs 1.3.

You actually have to modify the above proof of concept (http://jsfiddle.net/westonruter/446tk/) by removing the line that says xhr.setRequestHeader('Pragma', 'no-cache');, since setting this header is requiring the ajax request to become 'preflighted' by an HTTP OPTIONS request which in turn is not getting the necessary response containing Access-Control-Allow-Origin: * by djsd's WEBrick. However by removing the unnecessary header CORS is doing its magic and the content of user's scripts may be stolen.

As far as I can see the simplest solution is to remove the Access-Control-Allow-Origin: * header altogether as it is not actually needed by the extension. Instead it might be necessary to require permission performing XHRs against localhost in the manifest file according to http://code.google.com/chrome/extensions/xhr.html, even though the extension actually seems to run without explicitly stating this.

Since this solution is working without a problem here, I am going to prepare a corresponding pull request.

from dotjs.

Fixed by #46

from dotjs.