Express doesn't allow changing the CSP header - node.js

For some reason the latest Express.JS versions are forcing a default, restrictive CSP (Content-Security-Policy) header value.
I'm trying to instantiate a middleware in order to change CSP to a more permissive one (that's currently on my needs for the project) but Express.JS seems to ignore every value for the Content-Security-Policy header. Calling res.setHeader("...", "some value") does work on that middleware when I change the key name to everything but "Content-Security-Policy". I'm not defining this header anywhere else, so it seems to come from Express.JS itself. What's exactly going on, how to correctly make Express.JS to recognize it?
Example: requesting the main page shows the default restrictive header for CSP, ignoring the value I set on line 29
Another example: changing the header to another name that's not CSP correctly enlists it to the headers

Related

How to define nonce for style-src-attr or script-src-attr?

I'm trying to lock down my pages with a content security policy (CSP). The default CSP is too restrictive (and I cannot change the code to make it compliant, as it comes from a 3rd party), so I'm trying to define the minimal set of permissions in the CSP. To that end, I'd like to use style-src-attr and script-src-attr. And I'd like to use these with a nonce. I can see how to specify the nonce for both of these in the CSP. What I'm not sure about is how to specify the nonce for the html element (in the case of style-src-attr) and the javascript object (in the case of script-src-attr). I looked for an example, but couldn't find anything. Please give an example of how this could be done.
I stumbled over this question in actually preparing a lecture on the topic. The answer to the question is: you cannot.
Looking at the CSP Spec (https://www.w3.org/TR/CSP3/#match-element-to-source-list), only script or style tags can be nonced. The -attr variants do not apply to stand-alone elements (script tags, style tags, or links to CSS files), as per the spec (https://w3c.github.io/webappsec-csp/#directive-script-src-attr)
The script-src-attr directive applies to event handlers and, if present, it will override the script-src directive for relevant checks.
Bottom line, in the current specificiation, it should not be possible to allow event handlers through nonces. It is possible to rely on unsafe-hashes and put the hashes of known event handlers in there, but even that is not fully supported in browser (FF and Safari lack support, see https://caniuse.com/mdn-http_headers_csp_content-security-policy_unsafe-hashes)

Cache-Control headers - ignore query parameters

I am setting up a Cloudfront distribution for my companies website.
We would like to set the caching time by using the Cache-Control headers on the server-side (Node.Js with Express), like this:
if (req.url.startsWith('/static')) {
res.setHeader('Cache-Control', 'public,max-age=500');
}
At first, this seems to work well, but one of the criteria for the cache is failing, and that is, to ignore query string parameters.
For example, the request "domain.com/static/logo" and "domain.com/static/logo?foo=bar" should be interpreted as the same resource, and cached as one.
I wonder if it is possible to cache a resource while ignoring its query string parameters, using only the Cache-Control headers.
Thank you.
Bydefault CloudFront does remove the query string and also doesn't consider it into the cache , this is a default behaviour of CloudFront so that there are not multiple cache copies based on different query string parameter.
If you don't seem this behaviour, you may have "Query string" set to Forward all and cache based on call in CloudFront's cache behaviour.
https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/QueryStringParameters.html

TYPO3: Suspicious values for "type" parameter. Security issue?

In the log module of a TYPO3 website I can see errors where people try to call the website with suspicious/random values for the "type" parameter which end up in an error message, since the type was not defined/configured.
Examples:
https://www.example.com/path/?type=694
https://www.example.com/path2/?type=219
Error message:
Core: Exception handler (WEB): Uncaught TYPO3 Exception: #1294587217:
The page is not configured! [type=694][]. This means that there is no
TypoScript object of type PAGE with typeNum=694 configured.
Does anyone knows if there is a security issue which I am not aware of? Do I need to do anything?
In general URLs like https://www.example.com/path/?type=694 can be regarded as save if the requested parameter-value for type is not configured with config.typeNum in TYPO3.
For most parameters there is an option to configure the allowed values in TYPO3, however it's explicitly not advised concerning config.typeNum, the reference for TypoScript states:
Do not include the type parameter in the config.linkVars list, as this can result in unexpected behavior.
Other parameters (NOT type! ) used with random values
So, assumed there is another parameter which is requested with values that are not configured in the TYPO3 installation. A common parameter is L which is used for the language of the requested page. If there is a page with 3 languages then the main-language has the parameter L=0, the 2nd language the parameter L=1 and the last language the parameter L=2.
In this case the allowed values can be configured in TypoScript with
config.linkVars = L(0-2)
If the allowed linkvars never represent a linear range, it can be configured like this:
config.linkVars = L(0|5|23)
A more general approach is possible too, so the values can be restricted at least representing integer-values:
config.linkVars = L(int)
References:
Configuration concerning config.linkvars
Configuration concerning languages
Additional considerations
It is possible to filter not allowed page calls on a higher level, in the server-configuration (i.e. in a file .htaccess). Approach of this configuration could be included in the list
not-allowed parameters (or values) are redirecting the user to the main-page or an error-page of TYPO3
not-allowed parameters (or values) are redirecting the user to a page outside TYPO3, perhaps a static page without dynamic content
not-allowed parameters (or values) are blocking the user from any server-access (usually for a define-able time of i.e. 10 minutes)
page-requests with not-allowed parameters (or values) are logged or just dropped
This list is probably not complete but enough still to make some consideration.
There exist several opinions about those efforts, one opinion is that the system TYPO3 respectively the admin(s) should be informed about any access and are able perhaps to resolve some issues where users see an error but should see a regular page.
There might be still more arguments why TYPO3-admins should be informed about some not-provided parameters or parameter-values, but there are a few arguments which should be considered:
DDOS attacks flood servers with requests till the server is unable to serve any request.
In TYPO3 every request is filling some space in database and harddisk.
firewalls also filter requests and no TYPO3-admin should be allowed probably to switch the firewall inactive, TYPO3 is without special steps not informed about requests the firewall blocks.
So, there might be some false parameters sent in good purpose, but many requests could have another purpose and it could be advisable to block or redirect some request-types. The server should be protected and the error-log by TYPO3 kept so far slim that logged errors are widely related to TYPO3-issues that could need interference of a TYPO3 admin.

How to allow a wildcard for part of a querystring in IIS request filtering

I have a querystring that is made up of 3 parts.
The first 2 parts are static but the last one is dynamic and can be any value.
Because keywords used in part of the querystring are blocked / denied by IIS I need to know how to allow a dynamic value for only the last part of the query string in Request Filtering in IIS 7.5
So for example:
in-content=knownvalue&out-content=knownwvalue&searchable= *this could be any word that is made up of characters, numbers, hyphens apostrophe's & signs etc.
Thanks in advance for any help guys.
Because keywords used in part of the querystring are blocked / denied by IIS I need to know how to allow a dynamic value for only the last part of the query string
I don't believe you can configure the default Request Validation on a per-parameter level at present, so to allow all input for a particular parameter you'd have to disable it.
(I would do that anyway because IIS Request Validation is a misguided bogus security measure that hides not solves injection problems.)
If you still wanted to do input filtering on a parameter-by-parameter basis afterwards, you could implement that in the application or by providing your own request validation (subclassing RequestValidation and pointing requestValidationType at that class). Application-specific input filtering is generally a good thing, but it is not the answer to injection XSS issues, for which the only effective solution remains correct escaping for the output context.

Express eTag always changing

I have a rest like API through Node Express.
The ETag is default, not explicitly turned on or off. However whenever I test hitting the server, it always gives me a new ETag, even if the returned JSON/HTML is exactly the same. I also checked the returned header and they look the same. I tested this with two types of content, an API and a static HTML content like a privacy page.
Any idea how to check what's making it different each time?
Express' default behavior is to provide a "strong"-ly validated etag which will only be the same as a previous response if the current response is precisely the same, byte-for-byte.
You could try setting express' etag to weally validate the response, which indicates to the browser that the current response is semantically equivalent as a previous one with the same value, that is, while they might not be byte-for-byte the same, they encapulate or represent the same meaning. To do this, use app.set('etag','weak')
Finally, if this doesn't work for you, you can create your own etag validation function using app.get('etag',function(body,encoding){...}) where you return a hash generated from your content; this allows you to control what express (and thus, the browser) considers being different means in the context of your response.
More than you ever wanted to know about etags can be found at Wikipedi:HTTP_ETag

Resources