1

I have inherited an ASP website where sensitive data was passed in the query string as part of the URL. Something like this:

www.example.Com/Test?details=Username&moreDetails=blahblah

If we change this to encrypt the query string, so Username and moreDetails are not visible, I assume I still have the issue that this encrypted URL is stored in the browser's history, so it doesn't really handle the issue, does it? Am I correct that no-cache won't help either as although that may prevent it from being cached, I assume the URL will still be in the browser's history. Any way to prevent this?

I suppose the best solution is to use a POST and send the sensitive data in the body? But that's a bit of work.

2
  • 5
    Always send data with POST over HTTPS, especially authentication and/or sensitive information.
    – Adi
    Mar 14, 2014 at 15:04
  • If you are worried only about string appearing in the browser history you can always enclose the whole page within a frame/iframe. That way the browser will remember only the top (frameset) page, not the actual URL location. Mar 14, 2014 at 17:50

3 Answers 3

3

The answer you don't want to hear is that you should modify the code to use POST instead of GET.

Generally, you should be using POST for almost all data being sent via the web. The real and only exclusion to this is data that is meant to be seen and manipulated by the end user. Examples of this might be:

  • User Profile
  • Post ID
  • Latitude & Longitude (Mapping)
  • Event Name/ID

This would allow a user to share and bookmark the site with all of the contained information in the URL. This can be advantageous for deciphering the content of the page, and easily modifying the query string to other values.

When you are transmitting any data consider to be sensitive, or otherwise not needed to be exposed, you should be using POST. Examples:

  • Username and Password
  • Personal identifying information
  • Almost all form elements dealing with registration
1

Background

I was looking into the source code of Chromium to determine if there is any blacklisting or filter possibility for history entries. I have checked the following files which are responsible for the whole history handling:

  • history.cc
  • history.h
  • history_data.cc
  • history_data.h
  • history_data_observer.h
  • history_data_store.cc
  • history_data_store.h
  • history_data_store_unittest.cc

The Answer

No, there is no way to do that. As you have mentioned and the answer before mine suggests, you have to use POST requests to prevent information leakages like these.

0

TLDR; Use 302 redirect.

Apparently most modern browsers will not save the URL that redirects to another one with code 302 (while not a security feature - there is no warranty every browser does it, it can be circumvented by web developer tools, plugins, sniffers and perhaps some advanced browser settings - it definitely does help in most use cases). This method is apparently employed by most of the modern password reset link generators.

So, what you must do when someone lands on the link with query details=Username&moreDetails=blahblah, you process the data in whatever way you need (authenticate, start session, whatever) and immediately redirect with 302 to plain URL without those details. Only final URL will be saved in the browser history.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .