Client Side Browser Based Vulnerability - Part 2

Client Side Browser Based Vulnerability – Part 2

The previous article on ‘Client Side Browser Based Vulnerability‘, discussed about web and mobile browsers and how they have become major targets for hackers. It further discussed about two kinds of browser-based attacks, along with their proof of concept and mitigation.

This article continues with the next three attacks along with their solutions.

3. Password in browser memory

Most of the servers and applications store passwords in encrypted or hashed format. But, when passwords are stored in the browser memory, such hashing/encryption is not enforced. If the user is supplying sensitive information (such as credit card numbers, credentials, etc), through POST and GET requests on a sensitive page, the information gets stored in the browser memory while it is still open. An attacker having local access to the system can read such sensitive data, with memory-reading tools such as WinHex. Someone who has physical access to a user’s open browser, even after logging-out, can steal these data from the memory.

Proof of Concept

If you access the application, put valid credentials and then browse through the application. The request goes through the server, along with the username and password. The browser should not be closed, after you are logged out of the application. Open memory-reading tools such as ‘Winhex’ and cruise to the following path.

Tools:

 Open Ram

 Choose a browser (in this case Firefox)  Select Entire Memory

Using the username, go through the data. The entire login request for that particular application can be retrieved.

Mitigation

As the problem exists in the local/browser machine, using SSL will not reduce the damage. A user is not able to stop the browser from storing sensitive information such as passwords. A solution has to be enforced, so that the attacker is not able to replay the password value, secured from the physical memory.

So, the solution here is implementing salted hashing. Here is how the technique works:

1. The MD5 hash of the password should be stored in the database. This is a cryptographic technique where the actual value is never recovered.
2. If a login page is requested by the client, a random number is generated by the server. It is called salt and it is send to the user, along with the page.
3. The MD5 hash of the password entered by the user is calculated by a JavaScript present on the client machine.
4. The hash value and salt value are combined and the hash value is recalculated.
5. The value is sent to the server.
6. The hash value of the password is picked by the server, it is combined with the salt value and the MD5 hash value is calculated.
7. If both values match (when user enters the right password), the user is corroborated to the application.

4. Autocomplete

In a number of applications, when credentials are submitted by the user, a pop-up is shown by the browser for remembering the password. If “Remember password” is clicked by the user, the password will be stored by the browser and when the same application is accessed, it will be automatically entered. But, it will be an issue if the user uses this feature on a public or shared computer. The password which is stored in the browser can easily be retrieved by an attacker.

It is possible to access the saved password through the following process:

Firefox: Options

Security → Saved Password

Chrome: Settings

Manage password (Under password and forms)

IE: Internet Options

Content

AutoComplete Settings

Manage Passwords

Proof of Concept

Here, after putting in the credentials, a popup is shown by the browser, which asks the user if the password should be remembered. The password will be stored in the browser, if the user clicks ‘Remember Me’. The saved password can be accessed on Firefox, by navigating to Tools –

Options

Security

Saved Password

The ‘Saved Passwords’ button shows list of websites for which passwords have been stored in the browser.

The ‘Show Passwords’ button show all the stored passwords.

Now, if the list of stored passwords is obtained by a master password. Then the user just has to enter the master password, in order to access the list.

In this case, the opponent just has to use an intermediate proxy tool to obstruct the request that is going to the server.

You need to go to the application and double click on the username field. A list of stored usernames will be shown. If you click on one username, the browser will fill the password from the list of stored passwords.

Mitigation

The issue can be resolved by setting Autocomplete feature in the Login or other critical pages. Make sure this feature is set to ‘off’ for all sensitive pages. Examples of sensitive pages are the Login page, edit information page, change password page, etc. If Autocomplete has not been configured, then it will be ‘On’ by default and the information will be stored by the application.

The following command can be given to do this:

< form autocomplete=”off”> – This will set Autocomplete to ‘Off’ for all fields in the page.

Even if the browser has been set up to store password, the browser settings will be overwritten by the above code.

5. Browser History

When any data is submitted by a user, it goes to the server either in a POST request or GET request form. In a POST request the data is presented in the request body and in GET request the data is presented in the URL itself.

All GET requests that are obtained from the browser are saved in the browser’s cache and history. This data can be seen even if the user is logged out or if the browser is closed, by looking at the history of the browser. The data can be seen even if the user is logged out or if the browser is closed, by looking at the history of the browser. So, if user sensitive information is sent by an application, through a GET request, i.e. By a URL, the data can be obtained by an attacker by checking the browser history.

Proof of Concept

After submitting the credentials on the website when the Log in button is clicked, the credentials are sent in the form of GET request. The attacker having physical access to a user’s machine can view the credentials in browser history.

Mitigation

Sensitive information should never be sent through GET request. POST request should be used for sending data containing sensitive information. If sensitive information is sent through POST request, the data goes to request body and cannot be accessed through browser history, as only GET requests are shown by the browser history.



Let us know what you think