With the development of network security to the present, the most common web security issues such as injection, cross-site, upload, etc. have basically received the attention of most people, and the current common web scanners can basically find it, but business security has increasingly become network security. An important source of risk, and various logic problems have also appeared.
As the first entrance to business security, login password is one of the places where business security issues are most frequently raised. This article summarizes the daily penetration and security cases seen by CTF, hoping to summarize the posture of resetting user passwords as comprehensively as possible. It only serves as a record. The specific test methods will not be described in detail. .
1. The verification code can be blasted (simple and rude, not detailed)
2. The process of changing the password is divided into several steps (usually inputting the user name-inputting the verification code-inputting the new password 3 steps), there is no connection before and after.
You can skip directly to the third step to modify the password. Some jump through the local judgment of the corresponding state, and you can reach the last step by directly replacing the correct response packet.
In this case, the authentication method is all done in the front-end js. The key step logic of hiding may be leaked in js. For example, the method to modify the password in the third step is update3. In fact, an update5 method is hidden. update5 is not associated with the front and is directly verified by the server.
Three, HTTP response packet leaks
The simplest is to echo the verification code in the direct response packet, but except for the CTF introductory questions, I have never seen this kind of thing.
The other is the link to reset the password, which is spliced by the user's token, and the jump location after splicing will be displayed in the echo package. You can splice the link to modify the password according to the response token. In fact, in this case, by analyzing the link to reset the password, it can be found that the link is regular, such as the md5 or base64 encoding or uriencode of the user name or user id, or the combination of any two parameters MD5 or adding a timestamp Combine MD5 and so on to directly construct a reset password link.
4. The user name or mobile phone number and the verification code are not verified for consistency
If you use the verification code received from your mobile phone number to reset the passwords of other users, this situation is more common, and it is the most common and most prone to problems when combined.
The simple one may be that you can directly modify the mobile phone number or email address that accepts the verification code, and the more complicated one may be that the consistency check is not comprehensive (for example, it is only verified whether the mobile phone number is consistent with the verification code, and the modification of the password takes effect through the user name) .
Freebuf's article has detailed test methods, you can refer to: http://www.freebuf.com/articles/database/161495.html
http://www.freebuf.com/articles/web/162152.html
This kind of summary is actually that the credential information such as the verification code (or cookie, token) is not strictly bound and verified with the actual user . If the verification is bypassed through the unlogged cookie, it is a classic Cookie confusion .
5. Replace hidden fields when modifying information
This is from the rising posture of the dark cloud god carry_your. Everyone usually pays attention to the logic of normal login or password retrieval by default. But I didn't expect to be able to reset someone else's password when updating user information.
In fact, this place is considered to be a kind of horizontal overreach. The reason is that when the statement to modify the information is executed, the user's password is also executed as a field, and it is executed according to the hidden parameter loginid, which leads to the modification of the hidden parameter loginid The value of, you can modify the user password of others.
So when you modify your personal information, you might as well do a source code audit to see if there are hidden fields on the front end that are not in the post request.
The above-mentioned postures are actually the most common in terms of commonness. The verification code blasting and the credential information are not strictly verified are the most common, and the credential information verification is also the most common and most potential. Many seemingly safe scenarios. If you dig deeper, you may find problems.
Therefore, in order to protect against this problem, it is necessary to compare the consistency between resetting users and receiving reset credentials, and directly generate them from the server instead of obtaining them from the client. In addition, the password retrieval logic contains four elements: user identification (user name, user ID, cookie), receiver (mobile phone, email), and credentials (verification code, token), etc., which must be fully associated when submitted in the last step, otherwise May cause arbitrary password reset vulnerabilities. In addition, the server must strictly judge the problems of HTTP parameter pollution and unsubmitted parameters.