I want to finish this chapter with an example that combines redirection, cookies, PHP scripting, and some intuition on my part regarding their URLs.
The original email contained the link http://ylnif.raoy.com/r/vron/owepre.cfm. At face value,
the .cfm suffix suggests that this
is a Cold Fusion script, but this was clearly another example of replica
watch spam, and I already knew they weren’t using anything that fancy.
In addition, the term vron had
appeared several times before in the URLs. Clicking on the link took me
to the primary web site as expected.
Working on the hunch that the owepre.cfm filename was irrelevant, I tried
the shortened URL http://ylnif.raoy.com/r/vron/
and that worked just as well. That implied that some script, or Apache
directive, on the http://raoy.com server was
stripping down the URL before redirection. After a little more
experimentation, I realized that vron
was the name of an affiliate of the replica watch site, and the process
of redirection also created a cookie containing that name on the system
of the person visiting the site.
This set of headers shows how the whole process worked. In order
to test out my hypothesis, I replaced vron with the name foobar and even simplified the hostname of the
intermediary server. The URL I passed to wget was http://raoy.com/r/foobar.
Connecting to raoy.com[222.223.134.66]:80... connected.
[...]
1 HTTP/1.1 302 Found
2 Date: Wed, 12 Jan 2005 20:04:02 GMT
3 Server: Apache/1.3.33 (Unix) PHP/4.3.9
4 X-Powered-By: PHP/4.3.9
5 Location: http://www.online-replica-store.com/affiliate/?id=foobar
[...]
Connecting to www.online-replica-store.com[61.222.10.125]:80... connected.
[...]
1 HTTP/1.1 302 Found
2 Date: Wed, 12 Jan 2005 20:04:04 GMT
3 Server: Apache/1.3.33 (Unix) PHP/4.3.9
4 X-Powered-By: PHP/4.3.9
5 Set-Cookie: bmm=foobar; expires=Wed, 26-Jan-2005 20:04:07 GMT; path=/
6 Location: /
[...]
Connecting to www.online-replica-store.com[61.222.10.125]:80... connected.
HTTP request sent, awaiting response...
1 HTTP/1.1 200 OK
2 Date: Wed, 12 Jan 2005 20:04:09 GMT
3 Server: Apache/1.3.33 (Unix) PHP/4.3.9
4 X-Powered-By: PHP/4.3.9
5 Set-Cookie: PHPSESSID=e3127de47cefc63e4f571ae9b38dc5cd; path=/The first block of headers tells the browser to redirect from
http://raoy.com/r/foobar to http://www.online-replica-store.com/affiliate/?id=foobar.
Not only has the intermediary server redirected the browser, but it also
has rewritten the URL to include the name that I substituted in the
original URL. You can do this sort of thing using Apache directives, but
in this case it is the work of a PHP script. The X-Powered-By header tells us that. The script
parsed out the word following the /r/
in the URL and used that to generate the Location header that was returned to the
browser. The fact that this new URL includes the word affiliate suggests that this is some mechanism
to tell the replica watch site where that referral came from.
The second block of headers document a second
redirection. This redirects the browser to / on the same host, which is the home page for
the watch site. The reason for doing this is two fold. First it gets rid
of the string affiliate/?id=foobar so
the user can properly navigate the site. The second reason is that the
PHP script that generates the new Location header can also create a Set-Cookie header that contains the name of
the affiliate. The cookie has the name bmm and value foobar. The expiration date of the cookie is
set two weeks into the future.
Presumably if the visitor to the replica watch site were to
actually purchase something, within two weeks of the initial visit, then
foobar would be identified as the
affiliate who generated the referral.
I hope that this example illustrates just how valuable HTTP headers can be in understanding the operation of a web site. Even though the amount of information in a header block may be quite limited, it can offer insights that are not available anywhere else.