HTTP Strict Transport Security (HSTS)

The HTTP Strict Transport Security feature lets a web site inform the browser that it should never load the site using HTTP, and should automatically convert all attempts to access the site using HTTP to HTTPS requests instead.

Example Use case:
If a web site accepts a connection through HTTP and redirects to HTTPS, the user in this case may initially talk to the non-encrypted version of the site before being redirected, if, for example, the user types http://www.foo.com/ or even just foo.com.

Problem:
This opens up the potential for a man-in-the-middle attack, where the redirect could be exploited to direct a user to a malicious site instead of the secure version of the original page.

Risk:
For HTTP sites on the same domain it is not recommended to add a HSTS header but to do a permanent redirect (301 status code) to the HTTPS site.

Bonus:
Google is always “tweaking” their search algorithms, and, at least at present time, gives greater weight to secure websites.


# Optionally load the headers module:
LoadModule headers_module modules/mod_headers.so

<VirtualHost *:443>
# Guarantee HTTPS for 1 Year including Sub Domains
Header always set Strict-Transport-Security "max-age=31536000; includeSubdomains; preload"
</VirtualHost>

Then you might (optionally, but recommended) force ALL HTTP users to HTTPS:

# Redirect HTTP connections to HTTPS
<VirtualHost *:80>
ServerAlias *
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{HTTPS} off
#RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
RewriteRule ^(.*)$ https://%{HTTP_HOST}$1 [redirect=301]
</IfModule>
</VirtualHost>

That’s it…

REFERENCES:

Security through obscurity – hiding your server version information

I’ve recently spent a lot of time reviewing the OWASP documentation, and (like many corporations) realized that I’d neglected to keep up with this configuration item.

By sharing the exact version of each piece of server software you are using, “hackers” are able to quickly identify unpatched systems and their known vulnerabilities.

To make their work harder, there are a few simple steps that the server admin can take to remove this information from the HTTP Headers and error pages.

Apache HTTPd:

  1. sudo vi /etc/apache2/conf-enabled/security.conf
  2. Add:

    ServerTokens ProductOnly
    ServerSignature Off
  3. If using virtual hosts, add the following to each one:
    ServerSignature Off
  4. sudo service apache2 restart

Apache Tomcat:

  1. vi /opt/tomcat7/conf/server.xml
  2. Find the <Connector > entry and add:
    server="Apache"
  3. cd /opt/tomcat7/lib
  4. mkdir -p org/apache/catalina/util
  5. vi /opt/tomcat7/lib/org/apache/catalina/util/ServerInfo.properties
    server.info=Apache Tomcat
  6. sudo service tomcat7 restart

PHP “X-Powered-By: PHP/5.x.x-1ubuntuX.X”

  1. sudo vi /etc/php5/apache2/php.ini
    expose_php = Off
  2. sudo service apache2 restart

REFERENCES:

Preventing Blackberry browser from messing up your UI

I’ve previously given steps to prevent phone numbers (and other elements) from being automatically reformatted by Skype Toolbar and IOS Safari, there is still a small segment of the user population that uses Blackberry devices that can similarly benefit from a little code.

The following stops auto detection and formatting of phone and email addresses on devices with the BlackBerry Browser.

HTML:

<meta http-equiv="x-rim-auto-match" content="none" />

WML:

<meta name="x-rim-auto-match" http-equiv="x-rim-auto-match" forua="true" content="none" />

REFERENCES:

Content-Security-Policy HTTP Header

There’s yet another new means to ‘help’ client User-Agents with preventing XSS on your websites.

In it’s simplest form you can simply use the following HTTP Header(s), the second one is for earlier versions of Webkit (Chrome/Safari):

Content-Security-Policy: default-src 'self'
Webkit-CSP: default-src 'self'

You can also add to the above to permit assets to load from other sources.
For example, if you were to permit javascript files from example.com you could include:

Content-Security-Policy: default-src 'self'; script-src http://example.com

Additionally, while failures are noted in the client’s browser console (that most users are not aware of), you can have them sent back to your server by adding a ‘report-uri’ attribute with an appropriate handler:

Content-Security-Policy: default-src 'self'; report-uri http://example.com/csp-report.php

REFERENCES:

Google ChromeFrame

There was some debate back when this was first revealed in 2009, but the use of ChromeFrame is still relevant for some organizations that are stuck on older browsers for legacy applications.


<meta http-equiv="X-UA-Compatible" content="chrome=1" /><!-- this is for all versions of IE -->
<meta http-equiv="X-UA-Compatible" content="chrome=IE6" /><!-- this is for IE6 and lower -->
<meta http-equiv="X-UA-Compatible" content="chrome=IE7" /><!-- this is for IE7 and lower -->
<meta http-equiv="X-UA-Compatible" content="chrome=IE8" /><!-- this is for IE8 and lower -->
<meta http-equiv="X-UA-Compatible" content="chrome=IE9" /><!-- this is for IE9 and lower -->
<meta http-equiv="X-UA-Compatible" content="IE=Edge,chrome=IE6" /><!-- this is for IE9 and lower, passes Edge to others -->

NOTES:

  1. Installation can be done without Administrative rights on the Windows OS.
  2. Installation will append the ‘chromeframe’ version to the ‘User-Agent’ HTTP header sent by the browser to allow it to be parsed.

REFERENCES:

Morfeus scanner

I was scanning my server log files the other day and found that this old “bot” is still making the rounds. It help’s to shut the door on this with some configuration. It’s specifically looking for PHP vulnerabilities and is easily identified by the expletive in it’s User-Agent HTTP request headers.

REFERENCES:

X-XSS-Protection HTTP Header

This HTTP Header is a feature added by MSIE8 to force it to restrict some XSS vectors that can be disabled by the user. Generally you can add it into your webserver configuration.

X-XSS-Protection: 1; mode=block

REFERENCES:

Cross-Origin Resource Sharing (CORS) Header

Crossdomain access can be enabled in JavaScript with a mechanism similar to that in Flash. Instead of hosting a crossdomain.xml file though, crossdomain access is enabled per file, through an additional HTTP response header:

Access-Control-Allow-Origin: *

CORS is a more modern equivalent to JSONP for cross-domain XmlHttpRequests(AJAX) with options to limit domains, subdomains and ports.

Initial browser support:

  • Firefox 3.5
  • Chrome 4
  • Safari 3.2
  • MSIE 8

REFERENCES:

X-Download-Options:noopen to download files

There are a couple of steps required to force a browser to save/download content instead of displaying it in the browser window.


X-Download-Options: noopen
X-Content-Type-Options:nosniff
Content-Disposition: attachment; filename=example.txt
Content-Type: text/plain

NOTE: MSIE also supports a poorly documented proprietary META tag…

<meta name="DownloadOptions" content="noopen|nosave" />

REFERENCES:

X-Content-Type-Options: nosniff

To prevent XSS/CSRF exploits in MSIE8 and newer, it’s often best to close as many attack vectors as possible. An easy one to implement is an HTTP Header to prevent MSIE from “sniffing” the content to change it when incorrect.

Example: we would not want an HTML page intentionally served with ‘text/plain’ to be rendered as HTML.


X-Content-Type-Options: nosniff
Content-Type: text/plain

This could be added programatically to pages in your application, via a servlet or servlet filter or added to the httpd.conf file.

Apache2 example: httpd.conf

<IfModule headers_module>
Header set X-Content-Type-Options nosniff
</IfModule>

REFERENCES: