Jump to content
parrishk

HTTP Security Headers

Recommended Posts

Good afternoon,

 

I recently implemented OWASP's HTTP Security Headers Best Practices on our Passwordstate install.

 

This may be something you want to consider implementing out of the box to further increase the overall security of the platform when deployed.

From what I can see, the following settings would work for most installs. Sure, there will need to be some tweaks for those that have additional requirements/integrations.

 

Here is a link to OWASP's HTTP Security Header Best Practice: https://www.owasp.org/index.php/OWASP_Secure_Headers_Project#tab=Best_Practices

Scott Helme's SecurityHeaders.com checker: https://securityheaders.com


Here are the settings I found to work:

Strict-Transport-Security: max-age=31536000
X-Frame-Options: SAMEORIGIN
X-XSS-Protection: 1; mode=block
X-Content-Type-Options: nosniff
Referrer-Policy: strict-origin
Content-Security-Policy: default-src 'self'; script-src 'self' 'unsafe-inline' 'unsafe-eval'; style-src 'self' 'unsafe-inline' fonts.googleapis.com; img-src 'self'; connect-src 'self'; font-src 'self' fonts.gstatic.com fonts.googleapis.com; form-action 'self'; connect-src api.pwnedpasswords.com
Feature-Policy: accelerometer 'none'; camera 'none'; geolocation 'none'; gyroscope 'none'; magnetometer 'none'; microphone 'none'; payment 'none'; usb 'none'

 

The one thing that caused some flags was the "unsafe-inline" and "unsafe-eval" in the CSP policy. This is something that would have to be reworked on your end...

 

I hope others find this useful as well.

 

Kyle

Share this post


Link to post
Share on other sites
On 8/7/2018 at 5:57 AM, parrishk said:

I recently implemented OWASP's HTTP Security Headers Best Practices on our Passwordstate install.

 

For a laymen like me, can you explain what it achieves? I might look to implement on our instance when we rebuild it for DR.

Share this post


Link to post
Share on other sites

Hello Sarge,

 

I would say the primary goal for this would be to reduce the risk of Cross-site Scripting (XSS) attacks on the site.

 

Quote

Cross-site scripting (XSS) is a type of computer security vulnerability typically found in web applications. XSS enables attackers to inject client-side scripts into web pages viewed by other users. A cross-site scripting vulnerability may be used by attackers to bypass access controls such as the same-origin policy. Cross-site scripting carried out on websites accounted for roughly 84% of all security vulnerabilities documented by Symantec as of 2007.[1]  [[Cross-site scripting]] ([https://en.wikipedia.org/w/index.php?title=Cross-site_scripting&oldid=853211838 this version])

 

This isn't really specific to Passwordstate but should be a best-practice for any web application/service.

 

In the end, your are identifying "approved" sources for scripts, fonts, styles, etc that can run on your site. If something tries to run not whitelisted then it will prevent the script from running.

 

These XSS attacks may originate from malicious browser extensions, users or other vulnerabilities within the site.

 

Scott Helme has a great writeup on each of these headers if you want to read more into it. https://scotthelme.co.uk/hardening-your-http-response-headers/

 

I hope that helps!

Share this post


Link to post
Share on other sites

This is great news!

 

CSP is the most involved of the headers to implement because it "could" prevent parts of the site from functioning/loading.

 

Best option is to set it to "report only" and begin to whitelist the resources as needed. https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy-Report-Only.

Once these are good you can remove the report only option.

 

Thanks for the update!

 

Kyle

 

 

Share this post


Link to post
Share on other sites

×
×
  • Create New...