Todo #6647
open
Enable Additional Security Headers
Added by Chris Buechler over 8 years ago. Updated over 3 years ago.
0%
Description
The nginx instance for the web GUI should enable CSP. Just adding the following works:
add_header Content-Security-Policy "default-src 'self';";
though I suspect that may break some edge case I'm not thinking of. The captive portal nginx instance shouldn't have that set, as people routinely include external resources that would be broken by that.
Adding upgrade-insecure-requests while there wouldn't hurt either.
Updated by
Updated by Renato Botelho about 7 years ago
- Target version changed from 2.4.0 to 2.4.1
Updated by Jim Pingle about 7 years ago
- Target version changed from 2.4.1 to 2.4.2
Updated by Jim Pingle about 7 years ago
- Target version changed from 2.4.2 to 2.4.3
Updated by JohnPoz _ almost 7 years ago
While I am by no means an expert on what specific headers are appropriate... And the webgui really should be limited to local access from secure network and machine. This sort of came up in this thread.
https://forum.pfsense.org/index.php?topic=144026.0
There are maybe a few other headers that could be added to the webgui.. I have not researched in any sort of detail all the best practice, There are some listed here that are also missing that might make sense to add.
http://www.globaldots.com/8-http-security-headers-best-practices/
From a curl to the webgui and looking at the headers, along with the CSP I would think
X-XSS-Protection "1; mode=block"
And possibly
Referrer-Policy
Should also be added.
edit: Also I am not a chrome user but isn't there a Expect-CT that chrome is going to start enforcing for trust?
Thanks!
Updated by Jim Pingle over 6 years ago
- Target version changed from 2.4.3 to 2.4.4
We have our own internal controls to handle refererring URLS, so that header isn't desirable.
Reading about X-XSS-Protection, it seems like it's not all that great either, as it opens up other potential attacks.
CSP sounds desirable but we'd need to test it more thoroughly than we have time to do before this release. We can try it out for the next one, though.
Updated by Jim Pingle over 6 years ago
- Assignee deleted (
Renato Botelho) - Priority changed from Normal to Very Low
- Target version changed from 2.4.4 to Future
I tried several combinations of CSP options but every one broke the GUI in some way.
The strings I tried included with/without the following strings: "default-src 'self' data: 'insecure-inline' 'unsafe-eval'"
Notable problems include:- "Community Edition" formatting broken, text too large
- IPsec widget tabs not rendered
- Traffic graphs did not function
Likely other broken items I didn't see. I didn't dig too deep since there were obvious issues even on the dashboard.
Can revisit in the future.
Updated by Jim Pingle about 6 years ago
- Subject changed from Enable CSP for GUI to Enable Additional Security Headers
Fixed the subject to be more general since this is covering more than just CSP at this point.
We had someone asking about X-CSRF-Token and it's just not necessary. We use CSRF Magic which handles all the forms and other parts needed to verify CSRF tokens. X-CSRF-Token is an alternate way to implement the protection that some find easier, and it might be if we were doing it all by hand, but the library does all the heavy lifting here so it is not needed.
Updated by James Vaughan about 6 years ago
This 2016 presentation by two security researchers at Google might be useful when considering a CSP:
https://speakerdeck.com/mikispag/making-csp-great-again-michele-spagnuolo-and-lukas-weichselbaum
(a recording on YouTube is also available).
Essentially they talk about current CSPs and how they're quite flawed; policies can be strict but the maintenance can be arduous. They then go on to propose a common policy which makes uses of strict-dynamic which has the potential to be relatively universal. It does however, require that a random nonce is generated per server response in order to mark script blocks as "safe".
Their suggested policy won't catch 100% of things, but it will (according to them) raise the bar significantly.
Updated by Bill Marquette over 5 years ago
A quick test with the below inserted into head.inc
header("Content-Security-Policy: default-src 'self' 'unsafe-inline' 'unsafe-eval'");
does appear to allow the UI to render and be usable. However, that policy is of questionable value as it will only prevent scripts being loaded from other sites, while still allowing any injected JS to run. At best it might limit the XSS payload to whatever can be input via a GET request (or POST in case of a stored XSS).
Nonces as described above and SHA256 hashes as described here (https://www.troyhunt.com/locking-down-your-website-scripts-with-csp-hashes-nonces-and-report-uri/) might reduce the pain of migrating all the inline JS into a standalone file, but ultimately won't help for the dynamically generated JS generated on many pages (firewall_rules.php being a prime example).
Updated by Viktor Gurov over 3 years ago
PCI DSS Compliance scan requires Content-Security-Policy HTTP Header