secweb Posted September 14, 2015 Share Posted September 14, 2015 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? Quote Link to comment Share on other sites More sharing options...
scootstah Posted September 14, 2015 Share Posted September 14, 2015 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. Quote Link to comment Share on other sites More sharing options...
secweb Posted September 15, 2015 Author Share Posted September 15, 2015 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" Quote Link to comment Share on other sites More sharing options...
Jacques1 Posted September 16, 2015 Share Posted September 16, 2015 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. Quote Link to comment Share on other sites More sharing options...
secweb Posted September 16, 2015 Author Share Posted September 16, 2015 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 Quote Link to comment Share on other sites More sharing options...
scootstah Posted September 16, 2015 Share Posted September 16, 2015 It should be DENY, not NONE. Source: https://developer.mozilla.org/en-US/docs/Web/HTTP/X-Frame-Options Quote Link to comment Share on other sites More sharing options...
secweb Posted September 16, 2015 Author Share Posted September 16, 2015 For X-Frame-Options yes, but for CSP using DENY didn't work for me whereas NONE did Quote Link to comment Share on other sites More sharing options...
scootstah Posted September 16, 2015 Share Posted September 16, 2015 Yes sorry, I was talking about X-Frame-Options. Quote Link to comment Share on other sites More sharing options...
Jacques1 Posted September 16, 2015 Share Posted September 16, 2015 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. Quote Link to comment Share on other sites More sharing options...
secweb Posted September 17, 2015 Author Share Posted September 17, 2015 A 20 minute video about CSP at DefCon: Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.