Summarize browser-based security vulnerabilities in Web applications

1. Browser cache

Each time a Web site is opened, the content of the page is cached to the user's machine. If the content needs to be reloaded in other pages, the browser loads the cache instead of downloading the content again. If some Web store and display user sensitive information (such as address, credit card information, user name) This information will also be recorded in the cache, so you can detect the browser cache to retrieve this information.

In Internet Explorer, this information is stored in:

C:\Users\<user_name>\appdata\local\microsoft\windows\temporary Internet Files 

In the Firefox browser:

C:\Users\<user_name>\appdata\local\mozilla\firefox\profiles\<profile-id>\cache or enter About:cache in the Address bar   

In the Chrome browser, enter Chrome://cache in the Address bar, which is stored in

C:\Users\<user_name>\appdata\local\google\chrome\user data\default\cache 

Verify

We experimented under Mozilla Firefox, visited several pages and then exited the site. Enter About:cache in the Address bar. This allows you to display cached information in the browser, and select the content you are interested in by caching the list and its contents.

The following shows the user dashboard, in the user dashboard may contain high-risk sensitive information, such as address, phone number, credit card information, e-mail and so on.

Open a specific cache entry, in the user dashboard we can see the address, telephone number, order history and so on

Tips

This problem can be resolved by setting the appropriate cache control property in the response header.

There are two main types of cache properties:

Cache-control:no-cache

The No-cache property indicates that the browser does not use specific request-response cache information. Instead of reading content from the cache, the browser stores the cached information and sends a request to the server every time. In other words, the cache is just kept in the browser, and it is easy for an attacker or malicious to read the relevant information.

Cache-control:no-store

The No-store property indicates that the request-response is not cached or stored in the browser.

Using HTML META tags

You can also use the META tag to implement the control of the cache, set as follows:

<meta http-equiv="Cache-control" content="No-cache" />< Meta http-equiv="Cache-control" content="No-store" /> 

If the Cache-control header is added manually in the HTTP response header, and the No-cache is set. As shown, the browser will still cache the page

If you access the browser cache, then we can find it in the User dashboard cache page. Using the offline mode to open will show detailed details such as:

If the Cache-control header is set to No-store, No-cache. We can't find it in the user dashboard.

As a result, developers need to analyze the content of the Web page and adjust the appropriate Cache-control properties.

2. Password in browser memory

Most sites and servers are encrypted using hash or encrypt, but this does not apply to passwords saved in the browser's memory. Get requests and post requests are almost transparent in browser memory, and attackers can look at these sensitive information through tools like Winhex.

Verify

Visit the site and enter a valid voucher, as follows.

The following shows the user name and password passed to the server

Exit from the site, but do not close the browser, then open a tool like Winhex and navigate to the correct path.

First Open memory

Then select the browser (the Firefox we use in this column), select all memory

Searching for the user name in the data, we can obtain the complete login request information.

From here, attackers can steal user login credentials.

Tips

This problem occurs on the browser/local machine, and using SSL does not reduce the risk. Users do not prevent the browser from recording passwords or other sensitive information, and the solution to this problem is to use hash encryption.

Here is the workflow for adding salt hashes:

The MD5 hash password stored in the database. When a user requests a login page, the server randomly generates a number, which is called salt (salt) and then returned to the user's page. A JavaScript script appears on the user's machine, MD5 the password entered by the user. Then add salt and then calculate the hash value, which is sent to the server, the server selects the hash value of the password from the database combined with the salt value and calculates the MD5 value. If this value matches, the user logs on successfully.

Each time the salt value is not the same, so the attacker gets the hash from the memory in the browser, and the hash value is useless.

Another implementation, using a JavaScript script implementation, when the user exits after the forced closing of the browser, so that the browser's memory will be reset.

3. Return to refresh attack

The return function of the browser is familiar to everyone. By moving back this feature, we can display recently viewed pages. In addition, the browser will also be aware of such variables as user name, password, bank card account number and so on. This is because the page is crawled at the same time that it is delivered to the server via post. If a user logs on to a Web site and then exits after performing some action, the attacker logs on on the same machine, he can see the logout page in the browser window, and then he presses the back button until the page is displayed successfully, and then clicks the Refresh button, and the browser automatically resubmit all the requested information.

Verify

Log in to the webpage and go to the Change Password page, enter the current password, and click submit for the modified password.

To change the password for a series of requests and responses, see the following

Request

Response

Password Change succeeded

Browse the Web, then log off, log off and leave the machine without closing the browser. If an attacker can physically access the machine, simply click the Back button drop-down menu and just find the page after changing the password.

When you click to enter a special page, the browser displays the alert page that has expired.

At this point, attackers can use browser proxy tools such as burp and configure the browser to send requests through proxies.

Click the Refresh button in the error page, the browser will pop up a prompt window

With the configured proxy tool, an attacker can see the request sent to the server and can intercept the user's password

Variant attack

After the website has been successfully logged in, use redirection, and the login page contains the verification code. If the user uses the correct user name and password but the verification code is wrong, then the website will return to the login page and prompt the user for the error message.

In this case, the attacker could also use the fallback and refresh features to steal the username password. Even if the captcha is wrong, the attacker is able to obtain sensitive information such as the user name and password.

Verify

Visit the login page of the website, enter the correct user name and the wrong password

After the user name and password authentication, the server responds with "OK" and error description "username/Password Error"

Click the Back button to access a page that was previously able to log in correctly.

The browser warns that the credential has expired and requires the user to resend the data to the server.

Configure the agent between the browser and the server, intercept the data that is transmitted to the server, and then click the Send button

User's account password can be displayed in clear text to us

Problem analysis

In this example, the page that changes the password to "changepass.aspx" appears after "Changepass1.aspx". The "changepass1.aspx" page appears after providing the current password and the new password. Therefore, the browser logs the request sent to "changepass1.aspx". Let's take the whole order.

The user accesses the "changepass.aspx" page.

The user enters the current password, the new password, and finally confirms the new password.

Password and submit request sent to "changepass1.aspx"

User authentication on the "changepass1.aspx" page

When the attacker opens the "changepass1.aspx" page, the request is sent to "changepass1.aspx". This request contains the current password, the new password, and the confirmation password.

4. Auto-Save

After the user submits the account number and password, the browser will prompt to remember the password. If the user clicks Remember password, the browser stores the password and automatically fills in the relevant content the next time the site is accessed. This function is really convenient for users, users do not need to remember too many passwords, but if the user is on the public machine to use this feature, then the consequences? An attacker can easily find the account password.

Even if the password is encrypted, or there is a master password to protect it (with a password to access the stored password). An attacker could access the site to retrieve the password stored in the browser, and the attacker would simply type in the user name, the browser would automatically populate the password field, and only the burp-like tool would be required to intercept the browser request to obtain the password.

Here, after entering the user name and password, the browser pops up and prompts us whether to save the password

If the user confirms that the password is saved, the password is stored in the browser. In Firefox you can click tools → options → security → saved passwords

Now assume that the password saved in the browser has a master password to manage, and only after the password is verified can you see the information above

In this example, an attacker would need an intermediary agent tool to intercept the request that was sent to the server.

To the site, double-click the table box for the User Name field, which displays the list of stored user names. Click on one of the user names, in the Password field browser will be automatically filled out, from the interception request can be very easy to find the account and password information.

Tips

In the most recent version of most browser products, this auto-save feature is still available. In this special easy to hit the library of the age, the password is really not good to remember, this is to see the choice of their own.

5. Browser history

When a user submits data, not a GET request is a POST request. A GET request can be found by observing the URL itself, but the POST request exists in the body of the request, and the following two shows the GET request and the user data for the POST request.

So get requests can be accessed through the browser's history and the cache, and even if you log off and close the browser, the data can be viewed through the history record.

GET Request:

POST Request:

Verify

After the user has filled in the user name and password, click the login button, here will submit a GET request

Use burp to intercept requests, as follows

As a result, an attacker can through a history record

Similarly, if a site sends sensitive information through a GET method, the attacker can also look through the browser history.

Tips

Let not use get to send sensitive information, become we do not say the secret!

Summarize browser-based security vulnerabilities in Web applications