Using browser refresh to expose passwords
by Balaji V | Discuss this article »» (5)
A web browser has the functionality to store the recent pages browsed by the user in its history. The back and forward buttons on the browser make use of this history to display the pages that the user visited recently. The browser also keeps track of the variables that were sent as part of the request to the server for each page. The refresh feature of the browser automates posting of the variables to the server thereby greatly improving the user experience while browsing.
These features enhance the user experience but at the same time they expose a high risk vulnerability. This happens due to the application being insecurely designed. Attackers exploit these functionalities of the browser to obtain access to user credentials. Let’s see how this works and the solutions to overcome this problem.
When a user visits www.mysite.com, he is served a page say ‘login.asp’. This page requires the user to provide his login credentials - the ‘userID’ and ‘password’. When the user enters the name and password, the browser posts it to the server and saves the request in its history. After authentication, the user is presented with his personal page say ‘myhome.asp’. The user then browses through several pages and then logs out of the application.
The problem starts here, if the computer is a shared system. If the user leaves the browser open after logging out, the attacker can make use of the back button and navigate to the previous pages visited by the user. Most likely, the pages would have expired, so the attacker would get an error page on the browser saying just that. But the attacker isn’t done yet.
The attacker goes “back” to the second page, myhome.asp. Remember this is the first page displayed after login.
When the browser reaches this page, the attacker starts a web proxy such as Paros, and points the browser to use the proxy. Then the attacker clicks on the refresh button, asking the browser to resend the request that accessed the myhome.asp. The browser will display a pop up warning that some of the variables have to be reposted in order to display the particular page.
The attacker agrees by clicking on retry and the variables saved by the browser are reposted to the server. But the attacker now captures the request in the web proxy. This request contains the previous user’s ‘userID’ and ‘password’.
There also exist certain variations of the attack. These are:
- Stealing user credentials by refreshing sensitive pages visited by the user.
- Capturing user credentials when application uses frames.
A complete description of the variations and solutions can be read from http://paladion.net/papers/Stealing_passwords_via_browser_refresh.pdf
This problem can be addressed in two different ways. The methods described below can also be used to prevent the variations of this attack.
The first method is to use an intermediate page between the login page and the first page displayed after authentication (myhome.asp in this case). This intermediate page should be used to redirect the user via an “HTTP Redirect command” to myhome.asp after successful login. In such a scenario, the login request is redirected immediately by the intermediate page. This page is never displayed on the browser, instead it only redirects to myhome.asp. Hence the original login request is never saved in the browser, nor is the intermediate page stored. This avoids the possibility of the attacker being able to reach the intermediate page and refreshing it to steal the user credentials.
The second method is to use a salted hash technique for authentication. In this method, the password is hashed before sending it to the server. This hash is made random using a salt (a random value) provided by the server. This salt is added to the hash generated from the password and then hashed again. This salted hash is sent to the server for authentication. This way, even if the attacker uses the refresh button to capture the request, only the salted hash value will be visible. It will not allow the attacker to login by refreshing as the salt would change at the next login.
It is also essential that the application invalidate the session token upon user logout. As a best practice, when the back button is used to access any previously visited pages after the user’s logout, the browser should be redirected to the login page.
Some of the most useful features can also become attack tools when they are used against insecurely designed applications. Hence it is the application designer’s responsibility to ensure that the users are safeguarded against any such attacks.