To understand how this information could be dangerous, put yourself in the mind of an attacker. Start out by imagining an attacker who has their eye set on your site. Their goal could be a specific asset such as stealing computer resources or the design plans for the next Death Star. The attacker's goal might also be just a general search for anything of value. This can include confidential customer or employee records, passwords to your company's servers, "tagging" your homepage, etc. Your company may have been chosen for any number of reasons, ranging from you being the only company who has the desired asset (e.g.: There is no competition in the Death Star market), they know your company, they have felt slighted by your company, etc. In reality it does not matter. They are attacking, you are defending; both sides want to win but only one can.

The attacker not only wants to succeed in obtaining the desired asset, but they wish not to get caught or go to jail. Even if they are residing in a country that does not enforce computer theft and will not imprison them, getting caught still means that a successful attack will be more difficult as the attacked site will almost certainly add new security measures or tighten the existing ones to prevent the attack from being reproduced.

So, to begin with, the attacker approaches your site as a typical user: pulling up the homepage, browsing and searching the site, perhaps even buying products from your site. But as the attacker does this, they will be recording every piece of data that is returned. In particular, as part of the HTTP protocol, there are descriptive pieces of a webpage that can be accessed by the Web browser but are not typically displayed. While there are many ways of viewing these headers, I usually use Firefox and the Live HTTP Headers extension.

Let me demonstrate how this process works by putting on my black hat for a minute. I decided to make the Firefox website my target (I chose this for no other reason than because it was on my screen browser from having created a link to it in the previous paragraph). Looking at the headers for http://www.mozilla.com/en-US/firefox/, I notice the following headers as interesting:

The Server header tells me that Apache 2.0.52 is being run on a machine running Red Hat Linux. The "X-Powered-By" header lets us know that the site's software, or at least this page is powered by PHP version 4.3.9. I have never seen the "Via" header before but a quick Google search and the second hit on "ns-cache cookie" tells me that the site is using the Citrix NetScaler Application Delivery Software 6.1 caching software. Searching around Citrix's site, I see that the current version of NetScaler is version 8.0. Knowing that caches are frequently a source of security problems and that Mozilla is running two major releases behind the current version, I look on Citrix's site for any security bulletins for 6.1. My hope is that I will find a security bulletin that documents a vulnerability whose fix has not been applied to the site and use that to gain access to some protected information. Once I have done that, I will use whatever new information I have gained access to and try to get deeper into the system, proceeding patiently, one layer at a time, and changing tacks as I run into dead ends. And so the process goes. Each seemingly innocuous piece of information is used in combination with other information—information on hacking sites, etc.—to attempt the break-in.