6

I am logging in to my site using Chrome (on Ubuntu). Even if I logout and close my browser I can see the login POST request content (containing username and Password) using "Hexedit".

I have seen a similar question asked for IE, but I am not convinced with the answers provided. Most of them sounds like precautions only. I searched online for solutions. Someone suggested to use encryption on the client side, but that isn't a solution I can easily go for.

Gmail and Facbook login are not using any client side encryption (I can see my username and password sent in POST request without encryption); But I can't see any POST request saved for Gmail and Facebook using "Hexedit". So I suppose there is something that can be done?

How do I stop browsers (not just Chrome, but in general) from saving the content of POST requests sent to my site?

Moolshankar Tyagi
  • 61
  • 4
  • Is there any way to prevent browser (Any not only Chrome) storing login POST request in its memory. Generally browser stores POST requests on hex format which can be accessed using Hex editors like "Winhex" in Windows or "Hexedit" in Linux. There is a siliar question asked for IE as well – Moolshankar Tyagi Mar 27 '17 at 07:18
  • https://security.stackexchange.com/questions/112776/can-i-prevent-internet-explorer-from-storing-login-requests-in-memory?rq=1 – Moolshankar Tyagi Mar 27 '17 at 07:18
  • Anyway for the user visiting the site to stop it from being stored? Or anyway for the owner of the server thats serving the site? – Anders Mar 27 '17 at 07:24
  • anyway for the owner of the server thats serving the site. I am a developer and this is a security vulnerability in my code for which I need to fix. – Moolshankar Tyagi Mar 27 '17 at 07:28
  • A code level fix or suggestion is what I am looking for Is there any way we can delete POST requests or at least last POST request from browser memory? – Moolshankar Tyagi Mar 27 '17 at 07:36
  • You want the server to tell the browser to flush its own cache or delete particular cached data? – schroeder Mar 27 '17 at 08:24
  • Yes but I don't think its cache as we are already took care of that using Cache-control: no cache Cache-control: no store – Moolshankar Tyagi Mar 27 '17 at 10:25
  • Its some Browser's memory which is stored in hex form and needs to be flush out – Moolshankar Tyagi Mar 27 '17 at 10:26
  • 2
    right, that's what I mean: you want your server to tell a client browser to modify its internal memory cache .... I'm not sure you will find any function to permit this ... – schroeder Mar 27 '17 at 10:57
  • @schroeder : Yes correct and agree with you, I was just wondering how google and facebook guys are doing it, Is there any request header or some other rule so that request doesn't get saved? – Moolshankar Tyagi Mar 27 '17 at 11:48
  • I do not use Chrome, but Firefox can specifically strore passwords. Not in post requests but in a specific *credential registry* that can optionally be secured with a master password. – Serge Ballesta Mar 27 '17 at 12:03
  • Thanks Serge! Actually I don't know much about that, But a general solution would be too great as users are free to use any browser which can't be restricted .... Hope I didn't get you wrong. – Moolshankar Tyagi Mar 27 '17 at 12:43
  • Dump the google & facebook response *and request*: there may be a HTTP *request* header so that the request is not cached and dumped ASAP from the browser's memory. – Xenos Apr 07 '17 at 15:30
  • @Xenos : Yes, looking for something like that. One more input; I tried to create a simple WebApp, fired a POST login request and found that browser generally doesn't store POST login request it seems. If it is storing that is because of cookies or some local storage methods thats what I feel. Anyways I am still digging what caused browser to store POST request forever. – Moolshankar Tyagi Apr 10 '17 at 06:36
  • Modern web bowsers value efficiency over security, you might say they are inheriently insecure. – this.josh Apr 14 '17 at 05:27
  • Could it be a frameworks issue? – Moolshankar Tyagi May 03 '17 at 09:03

1 Answers1

3

You don't really have to worry about this. You aren't responsible for managing the virtual memory of a client's browser.

Think through what you're concerned about. The only way for this to be exploited is for an attacker to be on a client's machine, and to dump the memory of the process. If this is the case, they already have multiple easier methods of harvesting credentials (keylogging, browser Man-in-the-middle, etc...).

If you really wanted to get crazy about it, I suppose you could do something like this:

  • Separate the 'password' field into multiple different form elements spread around the page
  • Assign each character to a different variable in the POST request
  • Send all the characters in different order and reassemble on your side

I don't 100% know if that'll work, but I don't think it'll be easily readable in memory without some manual extraction.

Nick Simonian
  • 369
  • 2
  • 4