Have you ever seen plain-text credentials in the browser? Do you think, it’s an application vulnerability?
The direct answer would be, No. That’s how the protocol works and it’s the intended behavior of the browser.
Well, let’s dig into the question, “WHY?”
It’s not an application vulnerability, since it’s only visible in the particular user’s browser and the browser must be protected by the user. If someone else obtained access to your browser, they can do more than what you’re seeing on the browser.
How does it work?
Do you know there are 7 layers in the OSI model, which defines how computer systems communicate over a network?
In the same context, the user interaction with the browser relies on the application layer (the top layer). Therefore, it’s the browser that receives the user input directly and transmits it through the network.
What we’re seeing on the network tracer is, the data we submitted to the browser, and the network tracer is part of the browser. Therefore, showing the credentials in plain text in the network tracer is expected, since that’s what we entered on the login page!
In addition to the network tracer, the credentials can also be seen in plain text if those are saved in the browser.
Once the request leaves the browser (Presentation Layer), the whole POST request payload will be encrypted (between the OSI layers 6–4), including the credentials when communicated using HTTPS.
- Using HTTPS is mandatory since that’s the secure protocol to communicate over a network. If otherwise (HTTP) entire data will be sent in plain text throughout the network.
- The credentials should not be sent as URL query parameters (GET), since the URL could be recorded in several places such as server logs.
- The sensitive data must be sent as request body parameters (POST), or as request headers (POST/ GET).
Is it possible to encrypt the credentials in the browser?
The actual encryption of network communication happens in the OSI layers between 6–4, whereas the browser resides on layer 7 (application layer). Therefore, it’s not possible to encrypt the credentials in a standard way and such well-defined protocols are not available as of now.
Oh, do you still think it must be possible?
- Assume you’re encrypting the credential somehow, then the encrypted string will be your new password 😉 (If someone obtained the encrypted credentials, they could gain access to your account by using it — decryption is not required).
- What if the server accepts the hashed credentials? Well, that’s your new credentials again 😉 (If someone obtained the hashed value of your password, they could gain access to your account by using the hashed value— the original value is not required, since the server is already accepting the hashed value as the password)
A simple example is, the way Facebook sends the credentials.
If I’ve provided the valid credentials (I haven’t 😇), you can gain access to my account, using the above values.
Yes, you can mimic the encryption behavior as above. However, if someone gains access to your network tracer (as a HAR file) or if the attacker is recording/ snooping your screen, they can access your account, even with the hashed/ encrypted credentials.
The same applies if you’re intercepting the traffic from the burp suite and viewing the request payload since it requires importing the certificate to your browser in order to create a different secure channel between the browser and the burp suite. If someone is able to add a certificate to your browser and proxy the network requests, they can do way more than what you think and you’re already on a MITM attack 😁
Do you have a better approach?
Research and publish it to the world!
