Website vulnerability troubleshooting experience

Website vulnerability troubleshooting experience

Here we will share some problems that have been detected during Vulnerability Detection on a website Member/user system (generally, all domain names are passport.xx.com). Most of these problems are logical vulnerabilities, using vulnerabilities for attacks does not require any advanced technical capabilities. Therefore, they are extremely harmful. I hope you can share your experience with us.

It should be noted that the following examples of vulnerabilities are based on the premise that you have obtained a valid account password (the password is a password). You may ask:

1. How can I get another user's account and password? In fact, many websites have leaked their account libraries with clear text passwords (some account libraries do not contain passwords, or MD5 hash passwords, some common simple password attempts can be used without a password. The MD5 password can be "decrypted" using the cloud MD5 password library "), many people use some tools to perform one-by-one logon tests on a website using millions of accounts and passwords they have obtained (this process is called scanning ), when a website with a verification code uses a program to automatically identify the password, you can use the cloud CAPTCHA human bypass platform to identify the verification code. As long as you can log on to the website, this account password is the password for the website, it can be sold to the recipient at a certain price (for example, an account of 5 yuan). The account owner is purely technical, what do people who receive numbers get their accounts? This varies with the website (for game websites, the accounts are basically used for account washing ).

2. Now that you have obtained your account and password, what are the vulnerabilities? Many websites can log on with their account and password, but some key operations are often verified by dual authentication (such as email verification and mobile phone verification). What's more, some websites have account security policies, if an account is detected to be insecure (for example, remote logon), you may need to verify the authentication code on your mobile phone before you can log on. In general, even if someone else's account is in use, you can only log on to the background to check whether sensitive operations (such as account balance extraction and password modification) can be performed ), further behavior is possible only after some bindings are changed.

Verify first and then the operation is not bound together for overall treatment

Assume that your account is A and has been bound to an email address, and your encrypted account is B.

1. log on to the website using account A and open two tabs in the browser.

2. Go to the mailbox change function. On the page, you will be prompted to obtain the verification code. Click "get" to go to the "Change email" page, on this page, the website requires you to enter the Verification Code and the new email address you want to change.

3. Didn't I open two tab pages just now? Go to the second tab page and click "logout". Use Account B to log on to the website and enter the "Change email" function. Then, click "get verification code.

4. On the first tab, enter A new email address xx in step 2, and enter the correct Verification Code (view the verification code in the email address bound to account) complete the mailbox change process (in fact, the current login account is B ).

5. Refresh the page on the second tab. You can see that the mailbox of B has been changed to xx.

That is to say, in step 2 of the mailbox change operation, the login information of B is directly read and changed, and B is not verified as A which was not originally applied for mailbox change, the vulnerability does not occur due to the overall verification of the operation. If the website has this logic vulnerability, the function of changing the mobile phone may be broken.

The definition of security-related interfaces is too common, resulting in brute-force cracking.

If you are playing a game, you may know that there is something called a security card, for example, a two-dimensional table of X * Y (such as 10*10). Each grid is a number, during the sensitive operations, the player must enter three numbers for the specified position on the secret card. After all the numbers are entered correctly, the operation can be performed. For example, you are required to enter the numbers (A10, C2, F8) in three coordinates. You need to check the security card to find these three numbers and input them in sequence. If you do not have a security card, the number range of the security card is 0-99, so the probability of each digit being guessed is already 1%. The probability of all three digits being guessed is one thousandth (left and right ), therefore, it is a simple and effective security verification method.

Currently, AJAX technology is widely used. If you use a checkmibao /? Although AJAX requests such as locations = A10, C2, F8 & code = 11, 22, and 33 can meet the functional requirements, have you ever thought about this API (if there is no limit on the request frequency) it is very easy to crack quickly. It can simulate such a request checkmibao /? Locations = A1, A1, A1 & code = {0}, {0}, {0}, parameter {0} to cycle from 0 to 99, if the returned result is correct, the A1 security has been obtained. Otherwise, the query continues, for other coordinate A2-J10 of the table also the same operation can be quickly the entire security card "calculation. How should I change it? The locations parameter should not be set for the API at all, because the system knows the three coordinates of the verification when the user verifies the security card, only checkmibao /? Code = 11,22, 33.

To put it bluntly, the cause of this vulnerability is that it does not follow the principle that "everything on the client is untrusted" and can only trust the data on the server, the data submitted by the client must always be processed with a skeptical attitude. Any data can only be used as a reference or presentation and cannot be directly used as a parameter. In addition to this problem, AJAX may also bring some security risks, which are irrelevant to AJAX, many developers mistakenly develop the AJAX interface with the API mentality and forget that the interface is part of the website. For example:

1. Sometimes, in order to block the presentation of some data (for example, the IP address is shown as 192. 168. *. *), only data formatting is performed on the front end. The AJAX interface still provides the original data 192.168.0.1, which is completely insecure.

2. AJAX interfaces are usually lightweight and easy to use. In addition, it is easy to omit the control of Access frequency, making it easier to crack.

3. The initial loading of the page without refreshing the new flavor and the verification of subsequent operations will be segmented to generate vulnerabilities in segments.

Vulnerabilities caused by obsolete APIs

Many websites now make APP versions. After testing the APP on this website, we find that the interaction parameters with the server are both signed and BASE64. We know that android applications can be decompiled, after decompilation, you can see:

1. the private key of the public key is written in Java code. The public key is used to encrypt the data to be sent to the server, and the private key is used to decrypt the data returned from the server, in this way, you can familiarize yourself with the API by translating the data returned by the server, or directly send requests to the server by bypassing the client.

2. After understanding all the APIS, I found that a hidden API in the Code is useless. After testing, this is an "internal use" API, you can use this API to bind a client to an account without any verification. At this point, the account security of the entire website is out of service.

This process looks very simple, but we have tried a lot to find this vulnerability. First, we need to familiarize ourselves with the entire operation process and try whether there are logical vulnerabilities and other Breakthrough points one by one, each vulnerability is different. Not every APP has a hidden internal API. Every possible breakthrough is often based on unconventional thinking.

The improvement method is also very simple. The KEY value is stored in the SO file in a hash mode. It is best to write all the encryption and decryption protocols in C, which is transparent to the Java layer.

Summary

Don't underestimate these vulnerabilities. These vulnerabilities mean that hackers can modify users' email addresses, mobile phones, and passwords to bypass various secondary verification and keep their accounts fully in their hands. If the account owner has 10 million accounts and the account owner has 0.5 million accounts, it would be scary to think about it. From these points, I think we can sum up the following points:

1. In the bucket theory, 99% of the websites are not safe enough. If the website's account system is interconnected, As long as 1% of the websites have problems, the other 99% of the security is useless. People looking for vulnerabilities tend to like to find edge modules (developed by junior programmers.

2. Do not trust any client data. For each piece of data submitted by the client, it should be treated as user input (even if the data was originally read from the server ), perform strict verification.

3. For the implemented logic, consider whether there is an unconventional path or a logic that can be bypassed.

4. Monitor and control the frequency of requests. If some requests increase in the number of visits, a vulnerability may be cracked by others.

5. Try not to use AJAX for important functions. It is not to say that there is something wrong with AJAX, but AJAX is easy to relax and be vigilant. If you can make (AJAX) requests or API calls completely meaningless, such as using a unified generic ajax api to provide interfaces, such as http://passport.xxx.com/ajax? Token = xxx. the token is generated on the server in advance and corresponds to an operation logic. It is invalid when used, even the same API token is dynamic (instead of assigning a specific URL for each service, so that you do not know which service is based on the token, if others are not familiar with your process, it is also difficult to crack the logical vulnerability)

6. Do not require users to have a strong security awareness. As website development, users should actively protect their passwords and other sensitive information, prompting users to change their passwords frequently and establish a security analysis system for the website, security rating of user operations, and rejection of user login requests if necessary.