Hardening Your Web Server Against HTTP-based Intrusion Vectors

It happens. You're enjoying a raspberry-flavored sparkling water, mug of coffee, or cup of tea and an email comes in from InfoSec. The subject line casts a dark cloud over the rest of your day: Security Violation Remediation: Server ITSM-VA2-BPCOLL-01 (100001483652). ITSM-VA2-BPCOLL-01 is a print server running Pharos Blueprint Enterprise Collector software. It's getting print jobs, holding them, and then releasing them when the employees are at their print devices. What's the deal here?

What Just Happened?

Most IT organizations conduct security sweeps of their server infrastructure to eek out misconfigurations and other oversights that could potentially put the company at risk for "minor" problems like regulatory fines or sanctions to more major problems like hacking, data theft, or hijacking for another purpose (torrent servers, unregistered data stores and the like).

    "But it's a print server!" you rally. "What are they gonna do, steal company secrets?" Well...yes. A compromised system can serve as a vector for more malicious intent somewhere else; most intrusions happen on piggy-backed systems. Your Security team is just making sure that they keep a running tally of servers that don't fit their bill, and further track how quickly those identified servers are remedied.

What Do I Do?

That question is the first important step, and this article is the next. A lot of scanning systems borrow from a slew of resources like THE MITRE Corporation's Common Vulnerabilities and Exposures (CVE) website (cve.mitre.org) or OWASP (and many of those are software version-based. Keeping up to date with patches for installed software is a great first step in staying off the "naughty" list. Other vulnerabilities exist in web services and applications, and this is where this article is going to spend most of its time. So, on to HTTP Response Headers!

HTTP Response--what??

Some background may be helpful. When the W3C (the World Wide Web Consortium...the "think tank" and one of the standards organizations for the Internet) ushered in the concept of using markup language-formatted text to bring information to people worldwide, they also devised a way for those serving the information to provide additional information about the website to the user without affecting the displayed content on the page...a "meta data" vehicle of sorts: the HTTP Response Header.

    Over time, the function of the HTTP Response Header grew from a carrier of meta data (like who wrote the article, who holds the copyright, how many words it contains and all sorts of other cool, but non-essential, stuff), and could now manage how credentials were used or stored, what the underlying state of the server was, and ... security. Now, remember: a lot of web servers have public entry points (they have to, or your web experience would be awfully non-informative), so a bunch of the security-based HTTP Response Headers are driven towards keeping John Q. Public on the up-and-up, and the public web server out of hot water. And the security software that's out there looking at web servers will be designed around that. So while your internal print server hosting some Pharos software may be just that: internal, keeping it safe is the Security team's job...so they will still "call you out" when they find a violation.

Anyway, HTTP Response Headers. There are a handful of headers that can be implemented at either the server layer or the individual application or site layer that serve to keep things safe. And if your server's web server software (Microsoft IIS, Apache Tomcat, etc.) is missing them, it is likely a good time to add them. They don't affect the Pharos software's operation, and they keep your servers on the good side of the IT Security folks. Which means you get to enjoy your work beverage of choice without worrying about that incoming nasty-gram from InfoSec.

Good Custom HTTP Response Headers to Have

There are five (5) HTTP Response Headers that are good to have on your Microsoft Windows Server running IIS:

> Content-Security-Policy

The content security policy directs the browser (in this case, generally by the printer's built-in web browser) to load only certain types of content from certain sources. Here, the policy only allows loading of resources from the current web site or from the local host (the local host is required because some resources are fetched locally from the printer itself).

> Strict-Transport-Security

Strict transport security forces the use of HTTPS (encrypted HTTP) in future communications to the server. Generally, the "time to live" for this setting is a year, but some organizations may have shorter expiry periods.

> X-Frame-Options, X-Content-Type-Options, and X-XSS-Protection

These three headers prevent cross-site scripting attacks (injected code) and stop the execution of untrusted content. Web pages that allow comments or other interaction points (like the one you're reading now) are common targets for cross-site scripting attacks.

Where to Implement Custom HTTP Response Headers

When implementing Response Headers, one of the first questions asked is "Where?" Well, on the web server itself, of course! In practice, there are a few ways to implement Headers. Where you end up adding them will likely be up to your Security organization. I'll start at the top layer and work down.

> At the "Server" Layer

Implemented at the server layer, the HTTP Response Headers will be applied to all underlying Sites, virtual directories, and web applications. If implemented here, it's a "set it and forget it" type of scenario.

> At the "Site" Layer

Implemented at the site, like the Microsoft IIS "Default Web Site", applies the HTTP Response Headers to all virtual directories and web applications under the site. This is useful when a server is running multiple sites, and not each one needs custom HTTP Response Headers.

> At the Virtual Directory/Web Service Layer

Implemented at the actual web directory or application, this allows granular control over which services get the custom HTTP Response Headers and which ones don't.

Individual applications in Microsoft IIS may have their own set of custom HTTP headers within their web.config file. A Pharos software-based example is Print Center (/myprintcenter). Since HTTP headers are inheritable, you'll need to disinherit upper-level HTTP headers that conflict with what's already specified in web.config.

To clear inheritance, open the application's web.config file and add

<clear />

as the first element under <customHeaders>.

How to Implement Custom HTTP Response Headers

There's an old maxim that states there are three ways to do anything on a computer. The same applies here, but there are more than three.

> Using Microsoft IIS Manager

> Using PowerShell

> Using C# or another programming language

> Editing a web application's web.config file

In this article, we'll cover using Microsoft IIS Manager. There are multiple resources available to discuss the other three mechanisms (hint: use a scriptable/executable method if you have multiple servers). Just launch your favorite web search tool and type "powershell add http response header" or similar and you'll be fast on your way.

Creating a Custom HTTP Response Header in IIS Manager

In this example, we'll be adding the "Content-Security-Policy" HTTP Response Header to the "Default Web Site" in IIS.

Launch IIS Manager on the server. Click the "Default Web Site" element.

In the panel on the right, locate the "IIS" section and double-click the "HTTP Response Headers" item to open it.

Click the "Add..." option in the Actions panel.

Type "Content-Security-Policy" in the "Name" field and "default-src 'self' 127.0.0.1; script-src 'unsafe-inline';" in the "Value" field. Do not type the double-quotes.

Click the "OK" button.

That's it! Continue with the others. The necessary Name and suggested Value of the custom HTTP Response Headers is shown below:

References

The following references were utilized in this article.

• OWASP Application Security FAQ - OWASP  

• https://scotthelme.co.uk/hardening-your-http-response-headers/