Last updated at Thu, 12 Dec 2019 15:29:13 GMT
This is the second blog in our “Hidden Helpers” series on HTTP headers. Part one explains what HTTP headers are and why you should look to them when securing your application.
If somebody is trying to break into your house, there’s a great chance you’ll hear a window break or a door get forced open. However, this becomes less likely if you tell an attacker that the windows can easily be opened or the lock on your back door isn’t working.
The same holds true for application security. Attackers looking to compromise your system will attempt a variety of attack techniques, hoping that one sticks. If you’re monitoring your site’s traffic, there’s a good chance you’ll see a great deal of successful attacks and you will be able to react accordingly (call 911 if it’s your house, and 1-844-RAPID-IR if it’s your site).
When you present headers to attackers that are not required to use your application, you are possibly sharing information that will increase the potency and reduce the detectability of an attack.
Don’t overshare
When building HeaderInspector, I evaluated the Moz Top 500 sites and found that 85% of them share the type of web server they use (such as Apache, Nginx, etc.). Others share the version as well.
Part of this is due to the fact that Apache is still a major web server, when looking from a domain quality standpoint. And this web server requires you to recompile from the source to fully remove the server software banner. Below, you can see the Netcraft June 2019 Web Server Survey, which goes further into the market share for this metric:
Vendors such as Apache, Microsoft, and PHP all use these headers to evaluate their market share in the server hosting market. You should absolutely suppress these headers. One may argue that hiding these headers is security through obscurity. The harder an attacker must work to identify your system’s technology, the more detectable their actions will be. This will allow you to better prepare and monitor the attack and mitigate its effects.
Below are some examples:
Server
Example
Server: Apache/2.2 (Ubuntu 12.04)
Moz Top 500
This header is suppressed by 15% of sites.
This header exposes that your server is running on Ubuntu 12.04 (which tells us you are past end-of-life updates on your seven-year-old operating system), and that you are using an older version of Apache Web Server. My first action would be to look up Common Vulnerabilities and Exposures (CVEs) for Ubuntu 12.04, my second for Apache 2.2. Between the two applications, 130 CVEs have been published.
X-Powered-By
Example
X-Powered-By: PHP/5.3.3
Moz Top 500
This header is suppressed by 85% of sites.
Similar to the server header detailed above, we can use this information to pull down the list of CVEs. Using this information, we can potentially exploit a server. Contrary to truth, PHP will tell you that this poses no security risk when you go to change the setting to “Off”:
They are wrong.
Mitigation
This blog post focuses on discussion around the headers and their functionality. The information below is generic and potentially tied to a specific version of software. Before leveraging the art of copypasta, verify that this configuration will work for your organization. Sometimes, this information may not be applicable. For example, in PHP, you must modify the PHP.INI file to suppress the X-Powered-By header.
Apache HTTPd
Modify your site configuration file (generally within sites-available/???.conf)
header always set headerKey "headerValue"
NGINX
add_header headerKey "headerValue" always;
Microsoft IIS
Modify web.config for your application, adding headers with “add name” and removing (such as X-Powered-By) with “remove name”:
<system.webServer>
<httpProtocol>
<customHeaders>
<add name="headerKey" value="headerValue" />
<remove name="headerKey" />
</customHeaders>
</httpProtocol>
</system.webServer>
Thanks for reading this blog! If you would like to learn more about this topic, here are some key resources to check out:
