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.

  • 4
    Always send data with POST over HTTPS, especially authentication and/or sensitive information. – Adi Mar 14 '14 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. – BeagleEagle Mar 14 '14 at 17:50
1

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.