Re: GET and referer security considerations

At 02:22 PM 7/2/97 -0500, Foteos Macrides wrote:
>koen@win.tue.nl (Koen Holtman) wrote:
>>David W. Morris:
>>[...]
>>>
>>>The BCP suggestion is valid in any case, but from an HTTP perspective,
>>>there has never been a distinction between the piece of software known as
>>>the server and applications it may launch ... the composite is "the
>>>server".
>>
>>Yes. When I wrote
>>
>>  Web servers SHOULD NOT use GET based forms ...
>>
>>I meant web servers as a composite.  I did not mean to specify a
>>restriction which a poor httpd could never enforce by itself.  The
>>following restatement would also work:
>>
>>  Authors of services which use the HTTP protocol SHOULD NOT use .....
>
>	Your posted example referred to a form rely for an https ACTION
>with method GET, but just to be complete about that, the need to block
>a Referer header also applies for an http ACTION because the form might
>have included an INPUT TYPE="password" or other private information, but
>it doesn't apply, IMHO, to the ?searchpart for an ISINDEX reply.  Do you
>agree?  It can be very useful to see what queries were used successfully,
>based on requests for URLs from the hit lists, for improving the ISINDEX
>cover pages of local search services (though the major public ones use
>forms, so this is not a major issue :).  What I'm saying, in effect, is
>that if what follows the '?' doesn't contain an '=', the URL is OK to use
>in a Referer header.
>
>	If a client always blocks Referer headers when the URL has a
>?searchpart that includes an '=', then ones which are being used for
>state management but weren't the content of an actual form submission
>also will be blocked.  Is that a problem?  I don't see one, since it's
>the ?searchpart in the actual requests, not Referer headers, which
>normally are being used for state management, but it's possible at
>present to use both, and I wonder if any major service does in some
>useful way.

	Submitting a <FORM> via GET is bad for several reasons. The insecurity of
the subsequent GET/HEAD/POST request's REFERER field containing information
intended to be private is an important consideration. It is also important
to realize that the info-encoded URL will likely be visible in the UA, in
an "Address" display field or somesuch. Also insecure is passing the data
via GET or POST via HTTP instead of HTTPS. However, these are all
_application level_ concerns. The server can receive data from ah HTTPS
submitted <FORM> and email it (in plain view) to another party, if the
developer is careless enough. 

	It would add to the user's privacy to allow the browser not to report the
REFERER URL. That action would also render many vital applications useless
or make them much more expensive to implement. A good compromise is to
allow the UA not to report the REFERER, if so configured by the user, but
to default to always report, with an option to always prompt for reporting
or not. That behavior would mirror the behavior of submitting insecure
(HTTP) <FORM>s, allowing users to break the application only by explicit
reconfiguration.


>				Fote

--
Matthew Rubenstein                    North American Media Engines
Toronto, Ontario   *finger matt for public key*      (416)943-1010

			    Chess is for computers.

Received on Wednesday, 2 July 1997 12:23:20 UTC