Someone once said that “no security hole is too small”.  The longer you work in the information security field, the more relevant this becomes.  So many times, it’s been shown that the tiniest details can lead to massive data breaches.  The 2013 Target breach is a prime example.  Attackers first broke into Targets network on November 15, 2013.  How? Using stolen credentials from the HVAC system.  Who would of thought?

As security professionals, it’s critical that all possible vulnerabilities are discovered before they are exploited, no matter how small they seem.  Here are a few good examples:

HTTP Response Headers

Some headers that are returned in HTTP responses can contain critical information.  These headers should be disabled, or at the very least, restrict any sensitive information from being returned (web server version, domains, IP addresses, etc).  A few common ones are listed below.

Server

Look at the HTTP response headers below and think about what you see:

I’ll tell you what I see.  The web server is running Apache 2.4.3 which has a remote denial of service vulnerability.  Within 5 seconds of looking at the application, I have an attack vector.  This kind of information is extremely valuable to an attacker because any attack can now be focused or target the specific system in use.

Via

The Via header can also contain useful information for an attacker.  This header is used to the client of proxies through which the response was sent, but it can also contain web server information as well.

X-Powered-By

This is a common one, and it discloses information about the technology supporting the web application.  Knowing the technology and version is enough information for an attacker to simply look up any related CVEs and find vulnerabilities.  It’s usually accompanied by X-Runtime, X-Version, or X-AspNet-Version as well.  All of these should be disabled.

HTTP Strict Transport Security Header

The HTTP Strict Transport Security header (HSTS) is a special, security enhancement header that will prevent any communications to be sent over HTTP to the specified domain.  This will cause any request that is attempted to be sent over HTTP to automatically redirect to HTTPS. Also, in the event that an attacker attempts to intercept traffic via a man-in-the-middle attack using an invalid certificate, the user will not be allowed to accept the invalid certificate message.

A simple example using a one year max-age would be:

Strict-Transport-Security: max-age=31536000

Cookie Attributes

I guess most security professionals wouldn’t consider this a small issue, but it’s quite often that I see session cookies missing the HTTPOnly or secure attributes.  It’s important to have both on session cookies or any other cookie that might contain sensitive information.

HTTPOnly Attribute

The HTTPOnly flag mitigates the risk of the cookie being accessed by a client side script.  A common cross site scripting attack is to reference the victim’s cookies (using document.cookie) in a request to an attacker controlled domain, therefore logging the victim’s session cookie in the attacker’s logs.  The HTTPOnly cookie will prevent the script from accessing the cookies, mitigating the attack.

Secure Attribute

The secure attribute will prevent cookies from being transmitted in plain text, mitigating the risk of an unauthorized party from viewing it.  This attribute will force the browser to only send the cookie over an HTTPS connection.

Insecure HTTP Methods

This could also be considered a much more critical issue.  Testing for vulnerabilities related to insecure HTTP methods is relatively easy, and can be fixed simply by configuring the web server properly.  There are 4 methods that should be disabled:

PUT – Allows a client to upload new files to the web server (potentially malicious).

DELETE – Allows a client to delete files from the web server (can lead to defacement or DoS).

CONNECT – Could allow a client to use the web server as a proxy.

TRACE – Can be used to exploit Cross Site Tracing (CST).  The method echoes back whatever was sent to the server.

These methods can be tested using Netcat/Telnet.  If you get a 200 OK in response, you’ve got a problem.  You can also use the OPTIONS method to see what methods are enabled, though the methods may not be configured.

Proper Logout Functionality

It’s always the small things that will come back to bite us in the ass.  A lot of assumptions are made when designing an application, one being that the user will always press the logout button when they are done with their session.  I can tell you right now, my Facebook profile has been logged in for a solid month, and I definitely haven’t been sitting there scrolling through my news feed watching cat videos for that long.  There are a couple of things that are usually overlooked:

Session Timeout – The user’s session should expire after 30 minutes of inactivity.

Tab Closure – If the user closes the tab/browser, the session should expire.

Multiple Sessions – Unless there is a business need, there’s little reason to allow multiple sessions from the same user.

Session Cookie Does Not Update After Login – This allows a much longer window for an attacker to steal a user’s session cookie.  Normally, this means the same cookie is being used across multiple sessions.