[533] in cryptography@c2.net mail archive
Re: SSL weakness affecting links from pa
daemon@ATHENA.MIT.EDU (Steven Bellovin)
Mon Apr 14 14:32:30 1997
To: perry@piermont.com
cc: Tom Weinstein <tomw@netscape.com>,
"cryptography@c2.net" <cryptography@c2.net>
Date: Mon, 14 Apr 1997 14:04:59 -0400
From: Steven Bellovin <smb@research.att.com>
Tom Weinstein writes:
> > It does indicate what to look into to avoid it when writing web pa
ges,
> > but it doesn't say how to avoid it when entering your credit card
> > number into a web page, or what to look for as a non-programmer us
er.
>
> I basically agree with Microsoft. It works as specified, and everyo
ne
> should know that handling sensitive form posts via GET is a bad idea
.
Are you seriously suggesting that users should be responsible for
looking at the HTML source of every web page they send credit card
data from?
I do not think this is a reasonable position.
Yes and no. GET with arguments is a misfeature; there's no doubt
about that. It never should have been invented. And (decent) books
on running Web servers warn you about it.
However... If you're sending sensitive information to a Web site,
you *are* trusting the programmers there, often in less-visible ways.
I can (in principle) look at the HTML to see if there are GET methods.
I can't look at their site to see if they're storing my credit card
number somewhere in the document tree (as was done by at least one
popular server package). I can't (or at least shouldn't) run my
favorite security hole scanner to look for other ways in. And I don't
even know if they're honest -- their order script could be feeding
every 10th credit card number directly into an embossing machine filled
with Visa card blanks.
Referer is a harder problem. It does serve a legitimate purpose, and
in the Web world of two years ago (ancient history), it was useful for
finding broken links and maintaining state. In today's Web, with
things like doubleclick.com, ``adult'' sites, and lots of commerce,
it's a lot more dubious.
