Project

General

Profile

Todo #6647

Enable Additional Security Headers

Added by Chris Buechler about 2 years ago. Updated 28 days ago.

Status:
New
Priority:
Very Low
Assignee:
-
Category:
Web Interface
Target version:
Start date:
07/26/2016
Due date:
% Done:

0%

Estimated time:

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.

History

#1 Updated by Jim Thompson almost 2 years ago

  • Assignee set to Renato Botelho

#2 Updated by Renato Botelho about 1 year ago

  • Target version changed from 2.4.0 to 2.4.1

#3 Updated by Jim Pingle about 1 year ago

  • Target version changed from 2.4.1 to 2.4.2

#4 Updated by Jim Pingle 12 months ago

  • Target version changed from 2.4.2 to 2.4.3

#5 Updated by JohnPoz _ 8 months 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!

#6 Updated by Jim Pingle 7 months 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.

#7 Updated by Jim Pingle 3 months 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.

#8 Updated by Jim Pingle about 1 month 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.

#9 Updated by James Vaughan 28 days 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.

Also available in: Atom PDF