Keep a tight lid on HTTP headers

The web server is a common infrastructure component supporting a wide range of applications.  If you manage the web server, then you are the community manager, and you have a responsibility to maintain the reputation of the community.

The weather has been very windy lately.  Some people in the neighborhood put out their garbage and don't put a tight lid on the trash can.  Of course, the trash blows down the street and into other yards.  Now a few of the people in the neighborhood do not see this as a big problem.  After all their yard looks fine, and their trash is gone.  The president of the homeowners association has been sending out emails to remind people to put a tight lid on their trash cans.

Software vendors or application providers sometimes have the same attitude when you report a cross site scripting or HTTP response splitting issue.  The reaction seems to be "How does this affect me"?

These types of vulnerabilities do not directly affect the application that is creating the issue, but they impact the reputation of the whole community, because a person is launching an attack based on the reputation of the web site.  The manager of the web server needs to operate as a community manager and police the site.

If you look at the SANS top cyber security risks for 2009, you will see cross-site scripting at the top of the list.  The WASC Web Application security statistics show HTTP response splitting near the top of the list, along with cross-site scripting and SQL injection.

The root cause of many of these vulnerabilities is due to software developers setting HTTP headers, such as cookies and redirects, from unvalidated user input.  Here is an example using a vulnerability that was reported in the Apache mod_status module.  A patch is available for this issue.  It is considered a moderate level risk because the Apache status page should not be publicly available, and it is disabled by default.  This is a link to a description of the issue:  CVE-2007-6388 - Cross-site scripting (XSS) vulnerability in mod_status

The mod_status module included a feature to refresh the screen using a user entered value for the number of seconds.  The refresh parameter normally contains a number of seconds.  However, the parameter allows the specification of a URL, and the browser will refresh to the URL specified.  The mod_status module did not check the user input.  It simply took the value of the parameter and rewrote it as an HTTP refresh header.  This means a user could click a link expecting to go to a trusted site showing server-status, and instead be redirected to another site on the Internet.  This is what the request/response looks like:

telnet my-trusted-site.com 80
Trying 127.0.0.1...
Connected my-trusted-site.com.
Escape character is '^]'.
GET /server-status?refresh=0;url=http://untrusted-site.com/ HTTP/1.0

HTTP/1.1 200 OK
Date: Wed, 13 Jan 2010 17:48:03 GMT
Refresh: 0;url=http://untrusted-site.com/
Connection: close
Content-Type: text/html

The value of the refresh parameter that was entered by the user, and not validated, was placed in an HTTP header in the response causing the browser to immediately redirect to a new site.  A user clicking this link would think they were going to my-trusted-site, but instead would be redirected to untrusted-site.


An HTTP header is like a trash can lid.  If you don't keep a tight lid on HTTP headers, then garbage will be blown all over the community.