How to prevent image upload XSS attacks? - security

I recently did a CTF challenge where we needed to do an XSS attack on a site with a Content Security Policy ... script-src 'self' ... . This was made possible because the website offered the possibility to upload images, which we used to upload a file containing Javascript code with a GIF header like GIF89a=alert(document.cookie)//;.
All we had to do after successfully uploading that image was call that image with something like http://website.com/<script src=url_to_our_image> and the code was executed despite the CSP.
Now my question: How could you prevent that? I assume you want to keep CSP at ... script-src 'self' ... (you want to trust your own scripts, right?). But what other option would then be left to prevent such an attack? Blacklisting some content of the image, so that it cannot contain code? (I heard that blacklists a generally a bad idea)

Related

CSP style-src: 'unsafe-inline' in a landing page

I use the Webflow tool to set up my website. I export the code to host it on my server.
I have set up the Content-Security-Policy header.
Problem : most of the styles are inline. I can't add the hash for all of them, there are too many ...
Is it so dangerous to put unsafe inline on style-src ?
Note that this is a 99.9% static site (just a contact form).
Thank you for your help!
The dangers of 'unsafe-inline' in style-src are discussed here: https://scotthelme.co.uk/can-you-get-pwned-with-css/
If you can restrict the rest of your CSP, the dangers will be limited, but there will always be someone who disagrees. If it is technically possible you could use nonces, as you could use the same nonce for all tags, but change it on every pageload. It seems like you don't want or can extract all the CSS to a separate file, which would of course be the simplest solution.

React JS Refuse to load the image because it violates the following Content Security Policy directive

I faced this problem when I try to reload my react application web page.
Note: In the development phase there was no issue with this kind of thing, but when I deploy it to production I faced this issue. Thank you.
Refused to load the image 'http://104.248.153.121:8080/favicon.ico' because it violates the following Content Security Policy directive: "default-src 'none'". Note that 'img-src' was not explicitly set, so 'default-src' is used as a fallback.
Here is an error image log: Error Log Refuse to load image
The Content-Security-Policy meta-tag allows you to reduce the risk of XSS attacks by allowing you to define where resources can be loaded from, preventing browsers from loading data from any other locations. This makes it harder for an attacker to inject malicious code into your site.
Sample that says content="default-src 'self'" means this:
<meta http-equiv="Content-Security-Policy" content="default-src 'self'">
How to allow multiple sources?
You can simply list your sources after a directive as a space separated list:
content="default-src 'self' https://example.com/js/"
Note that there are no quotes around parameters other than the special ones, like 'self'. Also, there's no colon (:) after the directive. Just the directive, then a space-separated list of parameters.

What is the current best-practice for using Content-Security-Policy with modernizr?

We want to secure our site with Content-Security-Policy, and even with the setting of allowing inline scripts (default-src 'self'; script-src 'self' 'unsafe-inline'), loading modernizr (2.6.2) produces 4 CSP violations:
I upgraded to the latest version (3.6.0), the develop version, and now it produces over 30 CSP violations:
I couldn't find any official statement on CSP on the modernizr site, it merely mentions that in 2012, they added a detect for Content Security Policy (https://modernizr.com/news/modernizr-262).
Reading various blogs and Stack Overflow questions, I find most up-to-date best-practice from 2017 to be:
If modernizr is injecting all that inline stuff than it seems like
your choices are to either (a) add all those hashes, (b) use
'unsafe-inline' (but which basically defeats the whole purpose of
CSP…), or (c) don’t use modernizr.
Although, the errors I am getting occur even when using unsafe-inline.
Has anyone found a workable solution to using both Content-Security-Policy and modernizr?
Try using this lenient CSP default-src * 'unsafe-eval' 'unsafe-inline' 'unsafe-dynamic' data: filesystem: about: blob: ws: wss: and start removing keywords until you start getting errors, with this method you can adjust your CSP to your needs.
It would be nice if there was some sort of CSP generator where you give it a website and it just knows which CSP you need in order to not keep erroring.
Remember that * means allow all domains, so replace this with all domains you intent to support.
This of course just fixes, or solves the issue, and it depends what it's at stake, what content does your website offer, and how vulnerable would users be if an XSS attack could be carried through. CSP protects merely against XSS attacks, this is just JavaScript that could be inserted by a third party, using HTTPS for example, will make it almost impossible for a MITM to inject arbitrary code.

Content Security Policy with Paypal button

I wanted to set Content Security Policy (CSP) to my with page, which has a paypal button, which has gif image serves from https://www.paypalobjects.com I included it to my img-src whitelist.
<input type="image" src="https://www.paypalobjects.com/en_GB/SG/i/btn/btn_buynowCC_LG.gif" border="0" name="submit" alt="PayPal – The safer, easier way to pay online.">
But the image is then temporarily redirect to random domains like https://akamai.mathtag.com, https://ak1s.abmr.net
How should I set CSP such that img-src includes redirect domains as well. I do not know all the redirect domains.
Please note, Paypal states that you should only hotlink the checkout button and not save it anywhere else:
PayPal requires that you use the PayPal Check out button and the PayPal mark image hosted on secure PayPal servers.
Obtaining an Express Checkout Button and PayPal Mark
It is unclear how enforced this is.
CSP requires that you know the domains you are referencing content from, which is one of its weaknesses.
In order to get around that, there's a few things you could do:
Remove the img-src whitelist from CSP altogether. This sounds sub-optimal, but unless someone is able to directly compromise your server ( in which case they could modify the CSP header anyways ), or they are able to exploit a Cross-Site Scripting attack on your site, the img-src is not a huge concern. I would worry more about the script-src section, which, if implemented properly, would likely prevent unauthorized images from being loaded anyways.
Create a whitelist based proxy for CSP purposes. Basically, the browser requests the image from your server, and your server then retrieves the images on the backend, following through the redirects, caches the image, and returns it to the user.
As SilverlightFox said, you could also store the image directly on your servers. This could be problematic if you ever need to access other images that don't comply with such a strict CSP. Also, if the buy button image changes and you are unaware of it/haven't updated it, that could create suspicion amongst potential customers who had seen the new buy button elsewhere.
Hope that helps!

Is it possible to create a content security policy that allows all websites to be accessed?

I have been having problems with scripts not getting loaded because of problems with content security policy settings and was wondering if there was a way to set a content security policy so that it lets all websites be accessible for downloading scripts?
If you're not sure exactly what Content Security Policy you need, it's fine to start with a policy that's very permissive, (which is at least better than no policy at all) and refine it.
For example,
Content-Security-Policy: default-src 'self'; script-src *
would allow you to include scripts from anywhere, but everything else, for example images, only from your own site.
I would also recommend you start with Content-Security-Policy-Report-Only, which reports errors but doesn't block the content. That way you can safely test and refine your policy before you enforce it.
See for example Scott Helme's blog article
https://scotthelme.co.uk/content-security-policy-an-introduction/

Resources