[Pdx-pm] 3 Simple ways to attack cookies (was: saving state with
poec at yahoo.com
Thu Nov 6 14:04:07 CST 2003
--- Austin Schutz <tex at off.org> wrote:
> Three points of rebuttal... err.. I guess four:
> 1. If a credit card number has to be stored, I'd much rather have it
> stored on my computer than on some poorly maintained webserver run
> by joe shmoe on the other side of the 'Net.
Credit card numbers generally should not be stored. However, if they are, there is *no way* that
information should be in a cookie. That information gets invisibly stored on whatever computer
I'm using. If I am at a public place and I happen to pop over to the credit card company's Web
site, then I've just stored my credit card number on this public computer (and session cookies can
also be written to swap files and get stored on disk when you think they aren't!).
There is no way we can hope to educate all users on how to manage this information and we
shouldn't have to. The more things we ask people to remember, the more things they will forget.
> 3. Encryption works swell. Just because the data is stored on the
> user's computer doesn't mean it has to be available in plaintext.
I can't remember the source of the quote, but I recall reading once a description of SSL as using
an armored car to send credit card numbers from a guy on a park bench to a guy in a cardboard box.
Now while that *seems* like an innapropriate analogy since you appear to be talking about
encrypting the cookies as they are stored in the hard-drive (thus making is an armored cardboard
box), I think it's a perfect analogy because it reminds us that there we are talking about complex
systems and there are many parts to secure.
For example, let's say you really, really think that you've got everything nailed down. The Web
site is using SSL for every single page (performance be damned), you have a physically secure
computer and just to be paranoid, you use an encrypted file system. You've checked the server
that the Web site is sitting on and, as far as you can tell, every security patch appears to be
place and there are no known exploits. An in-depth security audit of the code also reveals that
there are no known security holes in any portion of the Web code. Feel pretty safe, huh?
Now the site uses your computer to store your personal data by storing it in a cookie on your
side, but no worries, you're bullet proof.
Tomorrow, the new programmer does a quick update to a page to allow a very limited subset of HTML
in user-posted comments and someone slips in an XSS (cross-site scripting) attack and snags Joe
User's cookie. Game over. Joe loses.
But the Web site's security team is so top-notch that they would never allow anything like this to
occur, so Joe User doesn't have to worry.
And while Joe User isn't worrying, he is over at another site which, unbeknownst to him, allows
tracing) attack whereby his cookie for the safe domain is sent to the attacker whose script
resides on the unsafe domain.
(unlike the vast majority of surfers), so Joe User is now perfectly safe and doesn't have to
And while Joe User isn't worrying, he's connecting to the safe server and notices that they had a
problem with their SSL certificate. Annoyed at seeing this *again* (so many sites are sloppy
about this), he clicks "ignore" and is completely unaware of the man in the middle attack that's
grabbing his credit card number.
I could go on, but I think the point is made. Those were potential scenarious of attack that
*assumed* everyone was cognizant of security issues. Most, as we are sadly aware, are not. With
networks, there are so many ways of compromising them that it doesn't make sense to send more
confidential information over the Web than is necessary. We know that this data will be sent, but
it should be as limited as possible.
This is not to say that we should never use the Web for anything personal. That's like saying we
can never unlock our front door lest the thieves get in. The problem is that we shouldn't be
leaving our front door unlocked and then driving to the coast (unless we have insurance and want
new furniture). The point here is risk management. We need to understand what common sources of
attack are and how we can guard against them. I probably won't hire a small army to guard against
a physical assault against my servers as this is both unlikely and not cost-effective. On the
other hand, XSS attacks are quite common and *should* be guarded against.
Silence is Evil http://users.easystreet.com/ovid/philosophy/indexdecency.htm
Web Programming with Perl http://users.easystreet.com/ovid/cgi_course/
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
More information about the Pdx-pm-list