Extra Security

[secweb]

Over the weekend I installed Kali Linux and ran a few vulnerability scanners against my new (currently local) site.

 

A few things kept popping up (using Nikto and OWASPs ZAP):

 

1. The anti-clickjacking X-Frame-Options header is not present.

2. The X-XSS-Protection header is not defined.

3. X-Content-Type-Options Header Missing

 

 

 

How important are these, and is it best to handle them in my PHP code?

 

 

1. X-Frame-Options

This is the method I've found for this:

header('X-Frame-Options: SAMEORIGIN');

2. X-XSS-Protection

Just finally found this, not sure if it works yet though:

header("X-XSS-Protection: 0");

3. X-Content-Type-Options

Also just finally found this:

header('X-Content-Type-Options: nosniff');

Is there any other security checks I should be making?

 

Can you suggest any other good scanners or tools?

[scootstah]

X-XSS-Protection is supposed to be 1 if you want it enabled.

header("X-XSS-Protection: 1");

Also it's probably better to set these at the web server level to ensure they're always present.

[secweb]

Thankyou, yes I finally noticed that too...

 

Here's how that ended for .htaccess:

 

Header always set X-Frame-Options "SAMEORIGIN"
Header always set X-Xss-Protection "1; mode=block"
Header always set X-Content-Type-Options "nosniff"

[Jacques1]

The X-Frame-Options header should be set to NONE. Do you even have a frame which includes one of your own pages? Then relax the policy for this specific page rather than globally.

 

Using SAMEORIGIN is risky, because it can be used to defeat the clickjacking protection via nested frames. The X-Frame-Options only takes the top-level frame context into account, so if you have a frame containing an external site, then that site may frame your site despite the SAMEORIGIN restriction. Intermediate frame contexts aren't checked.

 

A much better solution is Content Security Policy (CSP). It handles nested frames correctly and also provides advanced protection against cross-site scripting. The frame-ancestors directive of the CSP header is actually the successor of the X-Frame-Options header. Note, however, that CSP isn't supported by all browsers, so it's a good idea to use both headers at the same time.

[secweb]

Thankyou...no-one even lists "none" as an option! But it works for whatever reason.

 

 

I'll look into further tonight, however this works from within PHP in my quick test:

 

header("Content-Security-Policy: frame-ancestors 'none'");

 

Some of the better links with examples I found:

 

https://www.owasp.org/index.php/Content_Security_Policy_Cheat_Sheet

http://content-security-policy.com/

http://www.html5rocks.com/en/tutorials/security/content-security-policy/

 

 

Again, many thanks

[scootstah]

It should be DENY, not NONE.

 

Source: https://developer.mozilla.org/en-US/docs/Web/HTTP/X-Frame-Options

[secweb]

For X-Frame-Options yes, but for CSP using DENY didn't work for me whereas NONE did

[scootstah]

Yes sorry, I was talking about X-Frame-Options.

[Jacques1]

It should be DENY, not NONE.

 

Sorry, I mixed up the two headers. So, yes, it's DENY for the X-Frame-Options header, and frame-ancestors 'none' for CSP.

 

CSP also allows you to virtually eliminate the risk of XSS attacks by blocking all scripts and style sheets except those coming from a trusted source. Ideally, you'd have a separate domain serving only static content:

Content-Security-Policy: default-src https://static.yoursite.com; img-src * data:; connect-src 'self'; child-src 'self'; frame-src 'self'; frame-ancestors 'none'

Note, however, that strict CSP has some implications:

• You need clean HTML markup without tons of inline scripts and stylesheets, because those are blocked as well. It's possible to whitelist specific inline scripts and styles by hashing their content, but legacy websites may be too difficult to clean up.
• Only modern browsers (and not IE) benefit from CSP, and not every browser supports every directive.

[secweb]

A 20 minute video about CSP at DefCon: