Nginx – CSP nginx nonce

hashjavascriptnginx

I have some problems with adding CSP to my site. I configured Content-Security-Policy-Report-Only in my nginx configuration. And i get this.

adsbygoogle.js:37 [Report Only] Refused to apply inline style because it violates the following Content Security Policy directive: "style-src http://example.com". Either the 'unsafe-inline' keyword, a hash ('sha256-c+dT7QO/wB/DJJUeioTL/YNq09s5o1WF1vk5RjJU/4I='), or a nonce ('nonce-…') is required to enable inline execution.
(anonymous function) @ adsbygoogle.js:37

I searched solutions about that. But everywhere i see something like: "turn on 'unsafe-inline'". But its unsafe method. I think i can use "nonce-". But I dont know how to realize it in nginx conf. Can you help me?

Best Answer

It is not enough to modify your nginx configuration in order to use nonces.

Nonces must be generated for each request, so that attackers cannot know them (otherwise, they can just inject a script/resource with the same nonce).

Hence:

If you’re using nginx as a reverse-proxy, your application (behind nginx) must be modified in such a way that it will generate a nonce, add that nonce to all <script> blocks and <style> blocks in its output and serve the corresponding CSP header.
If you’re using nginx to serve static files, move <script> and <style> contents into separate files, compute their hash, and use the hash instead.

Now, having answered the generic question, let’s talk specifics. From your error message, I think you’re talking about //pagead2.googlesyndication.com/pagead/js/adsbygoogle.js. That script seems to be using inline styles, but isn’t under your control, so you can’t use nonces. Aside from asking Google to change the script, I don’t see what you could do.

Correct way in new versions of nginx

Turn out my first answer to this question was correct at certain time, but it turned into another pitfall - to stay up to date please check Taxing rewrite pitfalls

I have been corrected by many SE users, so the credit goes to them, but more importantly, here is the correct code:

server {
       listen         80;
       server_name    my.domain.com;
       return         301 https://$server_name$request_uri;
}

server {
       listen         443 ssl;
       server_name    my.domain.com;
       # add Strict-Transport-Security to prevent man in the middle attacks
       add_header Strict-Transport-Security "max-age=31536000" always; 

       [....]
}

Is Using nginx $request_id for CSP Nonce Value a Good Idea?

If you compile nginx with the NGX_OPENSSL flag, $request_id value will be sufficient for a CSP nonce because it's a 128-bit cryptographically strong random number returned by OpenSSL's RAND_bytes(). Otherwise, the value will be pseudo-random which means that an attacker who deduces the state of your server's PRNG may be able to forge the correct request_id / CSP nonce in their XSS payload. In practice, I wouldn't worry about this too much because the attack is not straightforward and would require sending a lot of traffic to the server, but it's worth keeping this in mind.

One thing to watch out for is making sure that the request_id value isn't used for anything else that might be sensitive in your application, because you will be exposing it to the user in the source of the HTML page.

Best Answer

Related Solutions

NGINX Redirect – How to Rewrite All HTTP Requests to HTTPS While Maintaining Sub-Domain

Correct way in new versions of nginx

Is Using nginx $request_id for CSP Nonce Value a Good Idea?

Related Topic