I am working on implementing Nonce for a setup that has an Apache 2.4.43 server and utilises HTML, CSS and JavaScript.
Since we would like to have a server-side implementation, I am using Apache module mod_unique_id to generate a unique key.
However the generated key is not base64-encoded (https://httpd.apache.org/docs/2.4/mod/mod_unique_id.html).
Trying to manipulate the generated key and encoding it using base64 in .conf file like this does not seem to work:
RequestHeader set %{UNIQUE_ID}e "expr=%{base64:%{reqenv:UNIQUE_ID}e}"
The generated nonce still has unacceptable characters sometimes.
Any ideas and suggestions on what more is required here?
Also, the generated nonce has to be added to the "script" tags loading the JavaScript code and the "link" tags loading the stylesheets (not sure if link tags allow nonce attributes) in index.html.
An example of how to effectively have this done from within .conf would be very helpful.
UPDATE:
I could not find a way to base64 encode the Apache-generated key in httpd.conf.
Finally ended up modifying the source code of the Apache module.
However, I am still looking for a way to insert nonce into script tags in index.html that is loading external scripts and stylesheets.
Related
An automated scanning tool is flagging the fact that our Javascript bundle is not being returned with a Content-Security-Policy header even though the document itself has the header.
My understanding is that the Content-Security-Policy header controls the loading of resources within a document. Does it provide any benefit when added to the resources themselves?
The short answer is generally no.
The long answer is you need to set your content-types properly. There is a scenario if you don't set correctly content-type it lead issues unless js files are not static, rendered in the background. If an attacker could find the manipulate first bytes of dynamic JS files, they could run those file context as an HTML. So if you don't use dynamic JS files or those files don't allow to manipulate first bytes. You don't need to set CSP policies.
We're trying to implement CSP into one of our sites and although we understand how to allow or not allow scripts, we're still confused on the nonce/sha* part. We have outside scripts such as bootstrap and jquery that come with the integrity="sha*" and that inline scripts or styles should be avoided. Everything inline should be refactored into an external file.
The question we have is, do we create a sha* key/nonce-* for every js or css file in our site (not external) or just putting 'self' after script-src/style-src in the Content-Security-Policy is sufficient?
Thanks for any help on this.
You don’t need nonces for linked JavaScript files; they authorize inline Script tags. The “self” (or URL) authorize the linked files. The cleanup you have to do is get rid of “onclick” attributes in the HTML. The SHA hashes are there to verify the integrity of the linked files.
So:
Clean up inline “onclick” (and similar), and “style” attributes.
Use nonces for inline script (and style) tags.
Use SHA hashes for linked scripts from outside sources
I host a website that allows users to download a file that is stored on a content distribution network (CDN). The link to the file on the CDN from my site is something like <a href=https://cdndomain.com/path/to/file>. I’d like to have a way for my users to ensure that file has not been manipulated by the CDN.
Of course, I can publish a hash of the file on my site (which of course is secured by SSL/TLS). Then, after the user downloads the file, they can take a hash of the file and verify that it matches the hash published on my site. This is not uncommon. But, many of my users are not savvy enough to understand this process. And, even for those that are, this process is somewhat cumbersome. I’m looking for a more automated/convenient way to ensure that file has not been manipulated.
I know that Content Security Policy (CSP) and Subresource Integrity (SRI) are now supported by Chrome, Firefox, and Safari. Using CSP/SRI, sites can ensure that .js files, .css files, etc., hosted elsewhere and referenced by <script> or <link> tags have not been manipulated, by including hashes of the target files in the <script> or <link> tags using the integrity attribute, e.g.:
<script src="https://code.jquery.com/jquery-3.2.1.slim.min.js" integrity="sha384-KJ3o2DKtIkvYIK3UENzmM7KCkRr/rE9/Qpg6aAZGJwFDMVNA/GpGFF93hXpG5KkN" crossorigin="anonymous"></script>
or
<link rel="stylesheet" href="https://maxcdn.bootstrapcdn.com/bootstrap/4.0.0-beta.3/css/bootstrap.min.css" integrity="sha384-Zug+QiDoJOrZ5t4lssLdxGhVrurbmBWopoEl+M6BdEfwnCJZtKxi1KgxUyJq13dy" crossorigin="anonymous">
This is very convenient, because the browser checks that the hash of the target file matches the hash specified in the integrity attribute ‘behind the scenes’, without any user intervention. After downloading the file from the CDN, the browser takes a hash of the file and checks that this hash matches the hash provided in the integrity attribute of the <script> or <link> tag. If the hashes does not match, the browser warns the user and does not execute the script or apply the css stylesheet.
I’m looking for something similar for a resource referenced in an <a> tag – whereby I can specify a hash of the target resource in the <a> tag, and the browser would perform a similar check after downloading the resource from the CDN, but before making it available to the user, and warn the user if the hashes do not match. But according to the MDN docs referenced above, CSP and SRI only apply to <script> tags and <link> tags, not to <a> tags.
Does anyone know of a solution?
Neither SRI nor CSP is really made for that; the item isn't actually being loaded on the page so neither of them will actually fire not that there's a way to specify requirements on an <a> tag anyway.
It's not quite the security vector either of these are made for either; these are meant to stop malicious code from being run in the browser. Once you've downloaded a file you're pretty much on your own unless it triggers the built-in Chrome "suspicious download" warning.
I would say your options are:
A) Provide a page where the user can upload the file to generate said hash for them and, while you're under the hood, might as well actually match it and generate a message that says "this matches the hash of X file!"
B) Ditch the CDN. They are by definition a Man In The Middle, so to fully trust TLS you'd need to deliver the file directly to the user or at least have full control of the CDN.
Which you pick depends on a combination of how much effort you want to put and how practical it is to ditch your CDN. Obviously A) lets you keep your CDN but is far more programming, B) is basically free of programming but could be extremely easy or completely impossible logistically.
Take a look at this script https://github.com/ShopupStore/IntegrityChecker , Even though it is for image, you will get the Idea for implementing it for tag. This script uses sha256 polyfill for the purpose, The final markup may look like this
<a data-href="https://cdn.example.com/1.jpg" data-hash="496aa8990b87f584dffc43e5953d38abcbc30a2edab131fd304fec43d6d9b289" data-fallback="https://example.com/1.jpg" class="link">
i've been Googling on how to get the ContentType of a file to be uploaded but to no avail. I need to get this done using Classic ASP. What i always see from Google is
response.ContentType = something
My main objective is to validate an image before uploading it. Only valid images are .jpg, .gif and .png. Thus, the valid ContentTypes are "image/jpeg", "image/gif" and "image/png".
I do not want to just rely in the file extension as a hacker can simply change the extension say .exe to .jpg.
Please help, thank you!
ADDED:
I am simply using this html control:
<input type="file" name="inputfile" />
Browsers may upload a filetype in the Content-Type header of the multipart/form-data subpart for the field.
Classic ASP does not natively support file uploads - what are you using to receive them? There are many libraries/controls that implement this and any mechanism to retrieve that subpart header will be dependent on what that code is.
Howewver, the point is largely moot because:
(a) the file upload Content-Type header is massively unreliable. Browsers can and will send wrong values at a whim, and there's typically little a user can do to correct the issue. (For example on Windows the applications that are installed can easily hijack MIME type associations away from the defaults, and even on a clean install IE will typically send the wrong type for JPEGs.)
(b) an attacker can spoof a Content-Type just as easily as they can spoof a file extension.
There is rarely a good reason to pay attention to the submitted Content-Type. At best you can use it as a convenience default value for something the user can manually override.
What is your purpose in checking the type of a file?
if you are trying to prevent injection onto the filesystem of directly executable files (eg xxx.asp), the right thing to check is the file extension, and generally place very strong restrictions on what can be in the filename at all (because typically servers decide what files to execute server-side based on name and location). This is actually quite hard to get 100% right, so it is generally best not to use user input as a basis for local filenames at all (instead use a generated filename like 123.jpeg for an object stored in the database as primary key 123).
if you are trying to prevent uploading broken images or unsupported image formats, you should check the content of the file to see if it's a valid image, using an image loading library.
if you are trying to prevent people uploading HTML or plugin content to do cross-site-scripting attacks, there is very little you can do about that by checking the file, its name, or its conetnt. It's possible to create ‘chameleon’ files are valid images whilst at the same time also containing content that a browser might interpret as script under some circumstances. If you have to allow general file uploads from untrusted users then the best thing to do is serve them off a different domain, so that cross-site-scripting into it doesn't give up anything valuable.
I have a rich-text editor on my site that I'm trying to protect against XSS attacks. I think I have pretty much everything handled, but I'm still unsure about what to do with images. Right now I'm using the following regex to validate image URLs, which I'm assuming will block inline javascript XSS attacks:
"https?://[-A-Za-z0-9+&##/%?=~_|!:,.;]+"
What I'm not sure of is how open this leaves me to XSS attacks from the remote image. Is linking to an external image a serious security threat?
The only thing I can think of is that the URL entered references a resource that returns "text/javascript" as its MIME type instead of some sort of image, and that javascript is then executed.
Is that possible? Is there any other security threat I should consider?
Another thing to worry about is that you can easily embed PHP code inside an image and upload that most of the time. The only thing an attack would then have to be able to do is find a way to include the image. (Only the PHP code will get executed, the rest is just echoed). Check the MIME-type won't help you with this because the attacker can easily just upload an image with the correct first few bytes, followed by arbitrary PHP code. (The same is somewhat true for HTML and Javascript code).
If the end-viewer is in a password protected area and your app contains Urls that initiate actions based on GET requests, you can make a request on the user's behalf.
Examples:
src="http://yoursite.com/deleteuser.xxx?userid=1234"
src="http://yoursite.com/user/delete/1234"
src="http://yoursite.com/dosomethingdangerous"
In that case, look at the context around it: do users only supply a URL? In that case it's fine to just validate the URLs semantics and MIME-type. If the user also gets to input tags of some sort you'll have to make sure that they are not manipulatable to do anything other then display images.