2 postings on HTML/SSL/WebForm security (RISKS DIGEST 19.02)

Li Gong (gong@games)
Mon, 7 Apr 1997 22:57:46 -0700

Date: Mon, 7 Apr 1997 22:57:46 -0700
Message-Id: <199704080557.WAA26825@games.eng.sun.com>
From: Li Gong <gong@games>
To: java-security
Subject: 2 postings on HTML/SSL/WebForm security (RISKS DIGEST 19.02)

------- start of forwarded message (RFC 934 encapsulation) -------

RISKS-LIST: Risks-Forum Digest Wednesday 02 April 1997 Volume 19 : Issue 02

FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS (comp.risks)
ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator

- ------------------------------
Date: Fri, 28 Mar 1997 17:25:26 -0800
From: EKR <ekr@terisa.com>
Subject: Re: SSL Browser Vulnerability Discovered (Kennedy, RISKS-18.95)

If you have a page that is fetched by SSL GET that has links offsite, then
targets of those links get whatever secure information was passed to the
site over SSL because of the 'Referer' header field.

For example, imagine I'm shopping at LL Bean and I enter my credit card
number on a page and submit it. Then that page has a link to the Wall Street
Journal. The Journal gets my credit card number in the referrer header.

I don't know for sure that this is the problem described here, but it
matches the described facts and I've verified that this problem in fact
exists.

There is an interesting variant of this involving inline images
on pages which are fetched with SSL. They get the Referer
header too. Now, there are several ways this can go wrong:

1. GIFs that are pointers to other web sites. E.g. advertising
or the ever-popular numbers used to display the number of hits
on the page. This has the same consequence as described in the
article, that is to say that the site which is referenced
gets the referrer header.

2. GIFs that are pointers to the same web site but are fetched
using HTTP. Navigator seems to forbid this (i.e. it pops up
a warning box and then refuses.) IE pops up a warning box
about loading insecure media (which you might very well not
mind doing) and then proceeds with the fetch. The consequence
of this is obvious: your secret information which you went to
all that trouble to encrypt is now passed over the net in the
clear. In general, all links off an SSL page whose URL+arguments
is sensitive need to be SSL protected themselves.

> :: Server-side remedies include referring visitors to an in-house dummy
> page to "wipe the browser's feet," or use the POST command instead of GET.
"Wiping the browsers feet" will work, but the dummy page must be fetched
with SSL itself, otherwise you'll just pass that secret information
in the clear when you fetch the dummy page.

> > Users finally, can protect themselves by typing in Internet addresses
> > manually instead of using links from "secure" pages.
As the inline GIF cases above show, this remedy is insufficient.

This seems to be another case of the law of unintended consequences.
Neither SSL nor the Referer header is the problem. It's the
combination of the two that creates it.

Eric Rescorla, Terisa Systems

- ------------------------------

Date: Fri, 28 Mar 1997 11:00:37 -0500
From: "Anup K. Ghosh" <anup@rstcorp.com>
Subject: Vulnerable Web forms

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?..).
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.

Anup K. Ghosh, Ph.D. http://www.rstcorp.com/~anup
Research Scientist Reliable Software Technologies Corp., Sterling, VA

- ------------------------------