I'm working on an extension that injects script in a page.
The extension is basically a content script that injects another script into the DOM. ( Why not just a content script? )
(There aren't any issues with my code, it works fine. The main purpose here is to learn about security issues in web development only)
The injected script is a source file in my extension and I get it with JQuery.get, using the address from chrome.extension.getURL('myscript.js').
Are there any security issues I should be aware of?
The page is not https, can this get return something different from my script?
I also insert HTML content using the same method. The HTML file is from my extension, just like the scritp. Is there any possibility of the responsetext be corrupted by a man in the middle??
What are the common practices to avoid such security issues if they exist?
Differently, if I create a script (document.createElement('script')) and set its source to my file. Would it be possible for someone to interfere when I inject this cript into the dom? (document.documentElement.appendChild(myScipt))
Also, what are the security issues involving this approach? Injecting a script that changes the XMLHttpRequest methods open and send in order to capture ajax calls, add listeners and send them with the same exact original arguments.
So, namely, say I have these:
var myScript = document.createElement('script');
myScript.src = chrome.extension.getURL('myscript.js');
var page = chrome.extension.getURL('mypage.html');
In such context, can a $.get('mypage.html') return anything different from my page due to a man in the middle? (In other words, could I unknowingly inject a malicious page?)
Could a document.documentElement.append(myScript) inject a different script? Could a supposed man in the middle get between the .src and change the actual script?
Since the script is meant to change the XMLHttpRequest prototype as described in the linked approach, could I ever send with arguments different from those passed by the original call?
Thank you!
First of all, Chrome is both the client and the server when you fetch a file from an extension, so you don't need https, it's worthless in this scenario. There is no man in the middle here.
One can think of another extension intercepting the ajax, but to do so that extension should already have proper permissions granted by the user, so it won't be an unauthorized interception. At least it won't be any less secure than any https ajax.
And, as you say, another man in the middle attack consists in redefining XMLHttpRequest, which you can do with an extension (with proper user authorization) or any other way to inject a script in the page (specially if the page is not a secure one).
I wonder if you can inject and run a script before the page loads, or at least before any other script execute, with the only purpose to "secure" the original XMLHttpRequest object (with something like mySecureAjax = XMLHttpRequest;)
You can execute before any script on the page, but you can't guarantee to execute before another extension's injection.
Related
Is there a way to block a particular line of code from being executed within a third-party website, appearing within an iFrame?
I have an embedded widget which is loading JQuery within the iFrame. I don't need the extra network request, because my site is already loading JQuery.
If I can block only one line of code (in this case, line 77) then I can prevent JQuery from being loaded again.
I imagine this action would take place prior to the iFrame being rendered.
The same-origin policy prevents you from touching any part of an iframe for a third-party website, so there's nothing you can directly do to prevent that request from being sent out. Even if you could, the iframe and your website have no shared state, so the other website will most likely break because it has no way to access your instance of jQuery. Think of what would happen if you loaded the third-party website in a new tab but blocked the request.
There are, however, a few things you can do to ensure the browser uses a cached copy of the library, which doesn't actually send a request anywhere:
If the external library is being loaded from a CDN, there's a good chance some other website has requested that same URL, so that user's browser has a cached copy of it.
Since you yourself use jQuery, you could use the other website's same version of jQuery. That way, a user's browser will have a cached copy of the file already from the CDN and no second request will be made.
Otherwise, if the website is using an old version of jQuery that you cannot yourself use or if it is being self-hosted without a CDN, there's nothing else you can do.
This is not a question if a web application can be safe/secure to use !!
But if I have a session or encryption key and like to hide it as good as possible on the client side with javascript - what is the best approach?
I wanted to use sessionStorage until I found out that any extension can read this from the content script at least in Chrome. In my view this is a big mistake from the developers as they hide the web pages javascript from the extension but allow it to see web-storage. Everywhere it is stated that the extension can only see the DOM but I do not think most people think that this also include web-storage!
So how can I secure a session key so it is away from reach of an extension? Unable to encrypt it as I then just need to hide the key. The problem is that the session have to be valid for all pages of the site so I can not just keep it in javascript as it is refreshed on each page load.
A cookie is in my view just as bad!
NB: Do not know if this is also a problem for other browsers
An extension, given permission to access your page, can do anything.
A code injected as a <script> tag from a content script into the DOM will execute regardless of your CSP in the context of your page, will full access to your JS context.
That is not to even to mention chrome.debugger API.
So no, you cannot secure your client-side data from extensions that user consented to run on your page, just as you can't secure your data from the browser itself.
I've seen a couple of pages load their javascript files into a page via new Image.src ='';
<script type="text/javascript">
new Image().src = "XXXX\/js\/jquery-1.7.2.min.js";
</script>
I was just wondering the benefits or purpose of this.
It's a quick and dirty way of initiating an HTTP request (as the comments on the question suggest).
There may be a minor advantage gained by initiating the download at the top of the page and then including <script src='the-same-file.js'></script> at the bottom of the page so that the file can be loaded from the browser cache.
This might allow the latency of the download to be parallelized with a parsing task. For example, the download initiated in the head might run while the body is still being parsed.
Why not just reference the file in the head using the src attribute?
If neither [the defer or async] attribute is present, then the script is fetched and
executed immediately, before the user agent continues parsing the
page.
Source (suggested reading)
In other words, this method attempts to allow the browser to download the file without incurring the blocking behavior until later in the process.
However
If this is really necessary, I would consider the defer attribute which is intended for such purposes rather than the new Image() hack.
This "optimization" could backfire depending on cache headers. You could end up making two HTTP requests or even downloading the file twice.
"In the Wild"
A quick investigation of several major sites (Google search, Gmail, Twitter, Facebook, Netflix) shows that this technique is not used to fetch JavaScript files and used very sparingly overall.
For example, Facebook appears to use it not for caching/performance but for tracking purposes when the site is (potentially maliciously) loaded into a frameset. By creating an Image instance and setting the source, they initiate an HTTP request to a page which tracks the clickjacking attempt.
This is an isolated case; under normal circumstances this script will never be run.
I am quite new to web application development and I need to know how would I make other sites use it.
My webapp basically gets a username and returns some data from my DB. This should be visible from other websites.
My options are:
iframe. The websites owners embed an iframe and they pass the userid in the querystring. I render a webpage with the data and is shown inside the iframe.
pros: easy to do, working already.
cons: the websites wont know the data returned, and they may like to know it.
javascript & div. They paste a div and some javascript code in their websites and the div content is updated with the data retrieved by the small javascript.
pros: the webside would be able to get the data.
cons: I could mess up with their website and I don't know wow would I run the javascript code appart from being triggered by a document ready, but I wouldn't like to add jquery libraries to their sites.
There must be better ways to integrate web applications than what I'm thinking. Could someone give me some advice?
Thanks
Iframes cannot communicate with pages that are on a different domain. If you want to inject content into someone else's page and still be able to interact with that page you need to include (or append) a JavaScript tag (that points to your code) to the hosting page, then use JavaScript to write your content into the hosting page.
Context Framework contains embedded mode support, where page components can be injected to other pages via Javascript. It does depend on jQuery but it can always be used in noConflict-mode. At current release the embedded pages must be on same domain so that same-origin-policy is not violated.
In the next release, embedded mode can be extended to use JSONP which enables embedding pages everywhere.
If what you really want is to expose the data, but not the visual content, then I'd consider exposing your data via JSONP. There are caveats to this approach, but it could work for you. There was an answer here a couple of days ago about using a Web Service, but this won't work directly from the client because of the browser's Same Origin policy. It's a shame that the poster of that answer deleted it rather than leave it here as he inadvertently highlighted some of the misconceptions about how browsers access remote content.
I learned the Javascript concept of same source of origin, which means Javascript code could only access the host where it is downloaded from.
My confusion is, I have developed Javascript code, store the code locally into a .js file and call Javascript code from another local html file. When I use IE to open the local html file, I find the Javascript could access any host, like Google and Bing.
Here is my code. My confusion is, seems the Javascript same original security restriction does not apply to locally running Javascript?
Javascript XMLHttpRequest issue
thanks in advance,
George
The same origin policy means that xmlhttp requests can be done to the same domain from which the js is loaded and executed, it is enforced by all browsers, also, if you are developing ajax code, there is no sense in executing it from a different domain from the one you will load the pages.
IE makes some exceptions on the SOP from local files, but these are edge situations and you shouldn't bother with them.
When you say 'access any host' what do you mean?
Do you mean that you receive notification of when your code loads a URL on google, or do you mean you can interrogate the HTML DOM of the page that loads.
I very much doubt you can do the later. I recall from experience doing this (a while ago mind) that receiving notification that a page has loaded should be possible - it's just that you simply can't see or modify anything ON that page.