Client Side Browser Based Vulnerability - Part 1

Client Side Browser Based Vulnerability – Part 1

Software applications that are mediators between a user and world wide web, and are an instrument for accessing information from the web, are known as web browsers or mobile browsers. Some of the popular browsers are – Mozilla Firefox, Google Chrome, Safari, Opera, Internet Explorer, etc. Due to their extensive usage and popularity, they have become major targets for hacking. It may become vulnerable to attacks due to a small mistake during application coding. This article covers two attacks that are not browser specific and that can be exploited on any browser not closed by the application developers, while designing or writing the application. The second part of the article covers rest of the three attacks.

Following are the browser-based attacks, along with their mitigation:

1. Browser cache: In this, sensitive information is obtained from the cache stored in browsers.
2. Back and Refresh attack: This involves getting credentials and other sensitive information by using the Refresh and Back button feature of the browser.
3. Passwords in browser memory: Obtaining credit card details or passwords stored in browser’s physical memory.
4. Autocomplete: Getting credentials of a user from browser’s stored passwords.
5. Browser history: Sensitive information is leaked from the browser’s history, through the URL.

1. Browser Cache

Each time a website is opened, the web page contents are sent to the browser’s temporary cache folder in the user’s machine. If those contents have to be loaded again, the page is opened by the browser from the cache instead of downloading the page. If few web application stores show sensitive information, such as credit card details, address, username, etc), the information can be stored for caching and can be retrieved by examining the browser’s cache.

Proof of Concept

This can be demonstrated in Mozilla Firefox browser. You can log in to the application and after accessing some pages, log out of the application. Type about:cache in the address bar. This will display the cache store in the browser. You can access the cache content of the website that you are interested in, by simply going through the list.

Upon opening a specific entry, the user dashboard can be seen with the order history, address, phone number, etc.

Mitigation

The problem can be solved by setting proper cache control features in the response header.

Following are the types of cache attributes:

Cache-control: no-cache: The no-cache attribute shows that the browser should not use the data that is cached for a specific request-response pair. The cache is stored in the browser, but instead of the cache content being shown, the request is sent to the server every time.

•Cache-control: no-store: This attribute indicates that the response-request pair should not be cached and stored in the browser.

•Usage of HTML meta tags: The cache control can be implemented using Meta tags. Meta tags can be set as:

(meta http-equiv=”Cache-Control” content=”no-cache” /)
(meta http-equiv=”Cache-Control” content=”no-store” /)

If the cache-control header is manually adjoined in the HTTP response and set to no-cache, the page will still be cached by the browser.

2. Back and Refresh Attack

The forward and back buttons on browsers, display the pages that have been recently browsed by a user. In addition to that variables are also tracked, like password, username, credit card details, etc. It is possible for the attacker to click the Refresh button, to obtain all the information from the browser.

Proof of Concept

If you are thinking about changing the password page of an application. Access the Change Password page of an application, by logging into the application. You can enter the values in the New and Current Password fields and click submit. The password will be changed successfully and an attacker who has physical access to the machine can click on the Back button and identify the page.

Mitigation

The following steps can be performed if a page is set up between “changepass.aspx” and “changepass1.aspx”:

•The “ChangePass.aspx” page is accessed by the user.

•Current password and new password is typed by the user and the new password is confirmed and submitted to “CheckPass.aspx”.

•The “CheckPass.aspx” page authenticates the user.

•The user is diverted to the “ChangePass1.aspx” page.

•A new request is sent by the browser to fetch the “ChangePass1.aspx” page.



Let us know what you think