[4940] in WWW Security List Archive
The GET vulnerability
daemon@ATHENA.MIT.EDU (Gary McGraw)
Fri Mar 28 13:24:24 1997
Date: Fri, 28 Mar 1997 11:16:38 -0500 (EST)
From: Gary McGraw <gem@rstcorp.com>
To: www-security@ns2.rutgers.edu
Errors-To: owner-www-security@ns2.rutgers.edu
My colleage, Anup Ghosh, wrote this explanation of the GET problem
that has made the popular press lately. Good SECURITY fodder for this
list (grumble, mumble).
Gary McGraw
A risk of using the GET method of the HTTP protocol for sending
in confidential data (such as credit card numbers) was reported
widely yesterday including on CNET (see
http://www.news.com/News/Item/0%2C4%2C9193%2C00.html?nd). Warning: this
link may be outdated soon.
The article states:
"For users, security risks could arise if they make a
purchase at a site that uses the GET function to
retrieve their credit card data. Once a user has
submitted an order and credit card number, the data is
sent to the Web vendor in encrypted format. But if the
user clicks on a hyperlink to another Web site, they
could be exposing their unencrypted credit card data to
that site."
What is not explained in the article is why credit card numbers
are at risk. The sum and substance of it is that when the Web site uses
the GET method in a query or form to retrieve your credit card number,
the parameters of the query are logged in the Web server log files.
Using the POST method does not appear to log the parameters of a query.
If you are dealing with a secure site to whom you are sending your
credit card number, sending your sensitive parameters using either
method should be OK---since the data is encrypted in transit to the site
regardless of the method. You also trust that site to carefully handle
the credit card number once it is decrypted on their server.
The problem arises when you jump to another site (that has no business
knowing your credit card number) after you have submitted your form.
The next site may very well be keeping a record of where you were
"referred" from. That is, the server logs of the next site will record
the previous site you jumped from before arriving at their Web page. In
the one popular Web server, the referrer_log file records this
information. For example, using Alta Vista's search engine for "java
security", I found our Web site, then jumped to it. Looking at the
referrer_log entry below, I find not only the site I jumped from, but
also the parameters of my request. Alta Vista's query form uses the GET
method.
http://altavista.digital.com/cgi-bin/query?pg=q&stq=50&q=java+security&r=java+security+
-> /java-security.html
It is easy to see how filling out one of these forms with sensitive
information like credit card numbers can be recorded in the next site's
referrer logs.
The risks are obvious. When using the Web for Internet commerce
activities, people expect that a secure session will protect their
credit card numbers from unauthorized third parties. This vulnerability
in the GET method illustrates how this may not be the case. This risk
also illustrates the lack of privacy in Web surfing. Not only do you
leave your calling card when you hit a site, you also let the site know
where you came from and potentially any sensitive data you may have
submitted to the last site (if the GET method is used for a form).
Finally, it is important to realize that even if the POST method is used
and a secure protocol layer such as SSL is employed to protect the data
in transit, the data inevitably ends up in plain text on the Web
server's host machine. The privacy of that data is now only as good as
the security of the Web server and scruples of the people handling the
data.
