I am looking for recommendations on how to implement our CSP policy. We have an Angular SPA application, that has an iframe without any src attribute. We populate the content of the iframe dynamically based on markup that we receive from an API. The markup that is returned from the API could have scripts that are not controlled by us. The SPA application will render the markup, including executing the scripts that get returned from the API as part of the markup.
The issue here is that a potentially malicious script could get returned from the API, which could hijack user information from the parent SPA application.
In this situation, how do we go about implementing CSP policy for the SPA application? I understand that there might not be a way to restrict hijack without doing some major architecture changes in the way that the content is rendered by the SPA. Any suggestions are welcome.
If the remote source returns specific scripts, you might be able to set a hash policy that allows that specific script. If they're returning a script that changes, you have to either a) block it, or b) trust them.
Example hash:
Content-Security-Policy: script-src 'sha256-B2yPHKaXnvFWtRChIbabYmUBFZdVfKKXHbWtWidDVF8='
Putting it another way: If it's a known script, you can allow that exact, known script. If it's an unknown script, how can you possible write a policy for the unknown?
There is also strict-dynamic, which basically says "allow unknown scripts that are loaded by this known script (e.g. Google APIs)", but indeed in that case you are trusting that other source to not serve you malicious code. What this does do is prevent other random unknown stuff from loading from other sources; it's a partial restriction.
Related
I'm trying to load some external JavaScript, but Chrome isn't having it.
To be clear, I'm using a bookmarklet to create a new script element, change the src attribute to my source code, and then append it to the header.
Here's the code:
javascript:var script=document.createElement("script");script.src="URL";document.getElementsByTagName('head')[0].appendChild(script);
Unfortunately, Chrome's Cross-Origin Read Blocking algorithm is preventing me from injecting the source into the header. I believe that this is due to the fact that said source document is simply plain text, and not an acceptable JavaScript file.
Is there any workaround for this?
There are many websites that because of CSP (Content Secrutiy Policy) not let you load scripts from other URLS. You should check the CSP headers of the website you trying to inject scripts into.
More info on CSP:
https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP
UPDATE
I see that your edit your question (after my initial answer) and now your asking specific about CORB issue. In that case you have to ensure that your script returing the correct content-type header. If you script doens't return text/javascript chrome will not execute it.
How do you serve the JavaScript file? if you will give more details we can try to help.
Usually servers are giving the correct header to JS files. There are some exception. For e.g. when user upload JS file to GitHub, GitHub will serve it without the content type header. This is because they don't want that a webmaster that trust only GitHub will have a risk that a user will execute user uploaded script (to GitHub) on his website.
More info:
https://www.chromium.org/Home/chromium-security/corb-for-developers
I understand the best way would be not to have the external JS at all, but alas, it's not possible.
Situation
The owner of a site wants (no ifs/ands/orButs) to get paid by a company that offers gambling ads. This company states that in order for them to offer said ads the owner of the site must add a JS code to the site. Said JS code is a few lines, but essentially it creates a tag <script> and loads a minified external JS file located in the publicity company's server. They do different kinds of ads (pop-ups, etc) and some other things that require the code.
There's no discussing not going through with this, I wanted to know if there were any kind of layers of security I might be able to add in order to protect site viewers. I know they are still in danger, but there's not much else I can do.
Things to do
Copy the external JS file and serve it from site owner's server (or is that a horrible idea? The thing is, at least this way they can't be changing it to their heart's content, since it's in the site owner's server).
Not loading the JS file in any page that has Login forms.
Only load the JS file where the publicity will be shown.
Not load the JS file is user if signed in
Modify JS file so that it has its own scope (function(){})() .
Anything else I could possibly do? Or am I simply fooling myself in thinking I can offer some feeble protection?
There are a few ways that may allow you to secure your page with external scripts.
First create a content security policy. This basically tells the browser where it can load different types of content from so if the third party starts loading content from new sources without telling you first they will be blocked.
Secondly the script-src tag. This allows you to specify a hash of the script tag and if it changes the browser won't run it.
There is a much better write up on these and more on Troy Hunt blog specifically this page https://www.troyhunt.com/locking-down-your-website-scripts-with-csp-hashes-nonces-and-report-uri/
Things to do:
Use a CDN that supports versions (almost every modern CDNs supports that) so you don't need to host these JS files yourself, and you don't need to worry about the fact that the file might change.
Only run your JS on login pages
For ads, use iframe elements, so the JS code for ads can't access external information
Use Subresource Integrity (SRI) on script tags
Example with jQuery
<script src="https://cdnjs.cloudflare.com/ajax/libs/jquery/3.3.1/jquery.min.js" integrity="sha256-FgpCb/KJQlLNfOu91ta32o/NMZxltwRo8QtmkMRdAu8=" crossorigin="anonymous"></script>
As Karl Graham mentioned, use Content Security Policy (CSP) in an HTTP Header, so content can't leak.
Make sure to use SSL Certificates (HTTPS), and to encrypt content when you do AJAX/Fetch requests so even if an external script listens to FetchEvents, it won't be able to read the data.
I'm almost certain that if you follow these rules, your external script won't be able to get your form content.
I am looking for an approach to allow only whitelisted scripts to run within a sandboxed iframe. I was thinking of an iframe-sandbox directive that allows only whitelisted scripts to run within an iframe. The analogy is the script-src directive in the Content Security Policy.
The problem:
<iframe sandbox="allow-same-origin allow-scripts" src="https://app.thirdparty.com" width="100%" height="800" frameBorder="0"></iframe>
The app in the iframe provides valuable functionality for my website. However, it pulls in external resources that I would like to control (i.e., block), e.g., AnalyticsJavaScript.com and TrackingPixel.com. I would like to allow scripts from app.thirdparty.com but block AnalyticsJavaScript.com and TrackingPixel.com.
Any help appreciated.
The answer to this is unfortunately complicated. With the advent of iframe sandboxing the question seems simple enough, but the spec that you're looking for is very much a work in progress. Thus, if you want decent browser support, the issue devolves into how to modify an iframe's content, which usually involves some sort of proxy.
Content Security Policy
The spec you really need is the CSP. At its simplest, you would allow specific scripts with the iframe atribute csp="...".
<iframe ...
src=""
csp="script-src https://app.thirdparty.com/"
...></iframe>
Any scripts from domains not specified (i.e. tracking scripts as in the question) would not be allowed in the response. Note that limiting scripts to those from a specified source does rely on cooperation with the third party app's server. If the server does not inform the user agent that it will adhere to the CSP restrictions then the response will be blocked.
The CSP is still a working draft and may change in the future. As stated in the comments, Chrome 61 and Opera 48 have implemented the CSP spec, but at this stage there is no sign from Firefox, Edge or Safari that they will also implement it. Unless you can guarantee that your users will only be using a browser that supports the spec, the tracking scripts will still be present for a very large percentage of users.
The remaining suggestions all involve modifying the iframe's content to remove the offending scripts.
Reverse proxy
Creating a reverse proxy to block a couple of tracking scripts in an iframe is probably equivalent to using a nuclear warhead to light a camp fire as far as overkill goes. But, if you are able to configure your server to this extent, it is the most reliable and seamless method for iframe content injection/modification/blocking that I've found.
The Wikipedia page states:
A reverse proxy is a type of proxy server that retrieves resources on behalf of a client from one or more servers. These resources are then returned to the client, appearing as if they originated from the proxy server itself.
Because the reverse proxy is an intermediary between the third party app and your site, it can transparently modify the responses to remove the undesired scripts. I'll use Apache in this example, but your implementation really depends on what server you're already using.
You need a subdomain for the proxy that points to your server IP, e.g. proxywebapp.yourdomain.com. On your server you would then create a virtual host in httpd.conf that uses the Apache mod_proxy module. Within your virtual host configuration you would then substitute the script calls to AnalyticsJavaScript.com and TrackingPixel.com with blanks. If the third party app must use HTTPS then reverse proxying gets trickier as you need an SSL virtual host and a SSL certificate for the proxy's FQDN.
<VirtualHost *:*>
ServerName proxywebapp.yourdomain.com
ProxyPreserveHost On
ProxyPass "/" "http://app.thirdparty.com/"
ProxyPassReverse "/" "http://app.thirdparty.com"
# in case any URLs have the original domain hard coded
Substitute "s|app.thirdparty.com/|proxywebapp.yourdomain.com/|i"
# replace the undesired scripts with blanks
Substitute "s|AnalyticsJavaScript/| /|i"
Substitute "s|TrackingPixel/| /|i"
</VirtualHost>
Your iframe would then point to proxywebapp.yourdomain.com.
<iframe ... src="proxywebapp.yourdomain.com" ...></iframe>
Again: total overkill but should work transparently.
Proxy scripts
A third option to consider is implementing a proxy script on your server between the iframe and third party app. You would add functionality into the proxy script that searches for and removes the undesired scripts before they reach the iframe. Additionally the proxy means the iframe's content will validate the same-origin policy, thus you could instead remove the undesired content with JavaScript in the frontend, although this may not guarantee that the scripts won't run before they are removed. There are many proxy scripts available online for all manner of backends (PHP, Node.js etc. ad nauseum). You would likely install the script and add it as the iframe's src, something like <iframe ... src="proxy.php?https://app.thirdparty.com/" ...>.
Unless properly configured for all cases, the proxy may not correctly transfer data between the third party app and its parent server. Testing will be required.
Writing your own server side proxy to remove a couple of scripts from an iframe is probably a bit excessive.
If you can't access the backend, it is possible to scrape the web app's content using JavaScript and a CORS or JSONP web app, and modify it to remove the scripts. Essentially making your own proxy in JavaScript. Such web apps (Any Origin, All Origins, etc) allow you to bypass cross-domain policy restrictions, but because they are third party you can no longer assume any of the web app's data is private. The issue with correctly communicating any data transfer between the app and its parent server will still be present.
Summary
A widely supported pure frontend solution is not feasible at the moment. But there are many ways to skin a cat and perhaps even more ways to modify an iframe's content, regardless of cross-domain restrictions.
Content Security Policy does look promising and is exactly what you're asking for, but currently its lack of widespread support means it can only be used in very niche situations. A reverse proxy that modifies content may take a lot of configuring and in this situation is like driving a full size semi-trailer over a Hot Wheels track, but will likely operate seamlessly. Content modification from a forward proxy is somewhat simpler to implement, but may break communications with the third party app's parent server.
You can't do this the way you want (for now). As mentioned in comments CSP:EE is a thing yet to come.
However you can try proxying the request and removing the unnecessary scripts from the body on the server side or on the client side, e.g.:
1) Get the needed page via XMLHTTPRequest
2) Remove unwanted
3) Inject into iframe on the page
"Workability" of this method depends purely on external app functionality. I.e. it will not work if the aforementioned app needs registration/authorisation of the end user to work, however this can still be suitable for some simple cases.
P.S.: you can implement a workaround to make such thing work via browser extension, however I'm sure this is not what you want.
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.
After reading this compendium of methods here Ways to circumvent the same-origin policy it's apparent that any workaround requires modification of the target iframe code to get communications across domains.
Unfortunately on this project I'm working on I may only modify the parent page's code, the iframe is provided from another source and is untouchable by us. Are there any methods that don't require modifications to the iframe code?
The only solution then is to fetch the iframe content from your server, either through a proxy or through specific code, and serve it yourself so that the browser only sees one origin.
But be aware that this usually breaks the rules or contract of normal use of the site providing the iframe. If they didn't include CORS headers to allow inclusion and access, there's probably a reason.
No, there cant be such a method, that would kill the security.