GET and referer security considerations

Hallam-Baker:
>
[...]
>Specifically I I have a confidential document P that links to Q I may want
>to instruct browsers not to pass on the referer field. It seems to me that
>this would be an easy enhancement to add to the spec but what the best
>way of transporting this information is I'm not sure.
[...]

This reminds me....  Some time ago, I read a report (in the RISKS
digest?) of the following case:

- user submits confidential information (e.g. credit card number) to a
  server, using a form
- form submission is nicely secure (SSL I believe)
- however, the form was submitted with a GET request
- and the form result contained a link to page on another server.

Result: the other server had things like

 https://blah.com/cgi/buy-cd?creditcard=2034872398472340

appearing in its referer log file.

This case suggests to me two additions to the HTTP/1.1 security
considerations section:

- User agents SHOULD NOT include a referer field in a (non-secure) HTTP
  request if the referring page was transferred with a secure protocol.

- Web servers SHOULD NOT use GET based forms for the submission
  of sensitive data, because this will cause this data to be encoded in
  the request URI, and many existing servers, proxies, and user agents
  will log the request URI in some place where it may be visible to
  third parties.  Servers can use POST based form submission instead.


Koen.

Received on Tuesday, 1 July 1997 11:15:33 UTC