Foundations of Python Network Programming 978-1-4302-3004-5

CHAPTER 9 ■ HTTP
But you should know that these other mechanisms exist if you are writing web clients, proxies, or even if
you simply browse the Web yourself and are interested in controlling your identity.
HTTP Session Hijacking
A perpetual problem with cookies is that web site designers do not seem to realize that cookies need to
be protected as zealously as your username and password. While it is true that well-designed cookies
expire and will no longer be accepted as valid by the server, cookies—while they last—give exactly as
much access to a web site as a username and password. If someone can make requests to a site with your
login cookie, the site will think it is you who has just logged in.
Some sites do not protect cookies at all: they might require HTTPS for your username and password,
but then return you to normal HTTP for the rest of your session. And with every HTTP request, your
session cookies are transmitted in the clear for anyone to intercept and start using.
Other sites are smart enough to protect subsequent page loads with HTTPS, even after you have left
the login page, but they forget that static data from the same domain, like images, decorations, CSS files,
and JavaScript source code, will also carry your cookie. The better alternatives are to either send all of
that information over HTTPS, or to carefully serve it from a different domain or path that is outside the
jurisdiction of the session cookie.
And despite the fact this problem has existed for years, at the time of writing it is once again back in
the news with the celebrated release of Firesheep. Sites need to learn that session cookies should always
be marked as secure, so that browsers will not divulge them over insecure links.
Earlier generations of browsers would refuse to cache content that came in over HTTPS, and that
might be where some developers got into the habit of not encrypting most of their web site. But modern
browsers will happily cache resources fetched over HTTPS—some will even save it on disk if the Cachecontrol:
header is set to public—so there are no longer good reasons not to encrypt everything sent
from a web site. Remember: If your users really need privacy, then exposing even what images,
decorations, and JavaScript they are downloading might allow an observer to guess which pages they are
visiting and which actions they are taking on your site.
Should you happen to observe or capture a Cookie: header from an HTTP request that you observe,
remember that there is no need to store it in a CookieJar or represent it as a cookielib object at all.
Indeed, you could not do that anyway because the outgoing Cookie: header does not reveal the domain
and path rules that the cookie was stored with. Instead, just inject the Cookie: header raw into the
requests you make to the web site:
request = urllib2.Request(url)
request.add_header('Cookie', intercepted_value)
info = urllib2.urlopen(request)
As always, use your powers for good and not evil!
Cross-Site Scripting Attacks
The earliest experiments with scripts that could run in web browsers revealed a problem: all of the HTTP
requests made by the browser were done with the authority of the user’s cookies, so pages could cause
quite a bit of trouble by attempting to, say, POST to the online web site of a popular bank asking that
money be transferred to the attacker’s account. Anyone who visited the problem site while logged on to
that particular bank in another window could lose money.
To address this, browsers imposed the restriction that scripts in languages like JavaScript can only
make connections back to the site that served the web page, and not to other web sites. This is called the
“same origin policy.”
160