Encountered the login box SRC vulnerability discovery process, the test does not always feel completely, East West, a hammer a stick, what think of what to measure.
I feel this is not OK, it is not professional, and thus summarize, after the testing process can be as prompt notes.
The following tests in the order:
registration page
- Registration bulk registration page
- Sign up covering (repeat others registered account)
- SMS mail bombs
- Whether the phone verification code can burst (cliché, Burpsuite blasting four capture verification code)
- Photos verify that the code may be bypassed (deletion codes, failure codes reproduced data packet, universal codes 0000, air bypass verification code, the verification code distal acquired (rare cases))
log in page
- Weak passwords, no authentication code blasting, universal password (background login, user logins limit)
- Whether the phone verification code can be text messages bomb
- url Jump Vulnerability (mainly used for fishing, and for bypassing the use Baidu search has been a lot of articles, not repeat them here)
- Whether at login can be bypassed (no cookie for most sites)
- Username Enumeration (observation prompted the return package or return package parameter changes)
forget password
- Whether the phone verification code can blast
- Whether to modify the password process can be skipped
- Any user password reset
- SMS mail bombs
Registration bulk registration page
This website registration page, no SMS verification code, then we can consider whether you can batch register it?
For the premise of bulk registration is: The page at no CAPTCHA or Captcha code failure! This page is not registered at the Captcha code.
Although the registration page to enter the name and ID number, but did not do it for the name and ID number to check, enter any name and ID number can be.
Test procedure: Burpsuite capture registration submitted
First registration with the correct information, keep in mind the data returned by the server when the registration is successful, know what the return is successful registration
Then just modified data packet to traverse the phone number, account number and other parameters transmitted reply packet observation state
Sign up covering (repeat others registered account)
For registration page coverage refers to the original registration with a phone number has been registered account, but due to the vulnerability, leading to possible re-use of the mobile phone number to register, and will be registered before the record cover!
When we have registered account ready to register, you are prompted to find the phone number already exists!
We get caught, it was found that the detection of the rear end of the phone number has been registered, it will return true. If it is detected that the phone number is not registered, it returns false.
Modify the parameters of return, to repeat the registration purposes.
In fact, this is a question of limiting - that is, the number of requests within the time limit of an interface window.
Many projects are indispensable to the user's mobile phone number or email account to send text messages like e-mail, but many are sending text messages to send text messages with the aid of third-party interfaces, this way, SMS is limited, oh charges. If the system is not doing well, some small flaw, white hat was found okay, and if those are found in the black hat, several thousand, severe cases may lead to company closures ah. Even without being attacked black hat, some malicious users may damage the system.
Can also be used Burpsuite capture blasting, Ximen big brother had a packet capture instance in order to add a space after the phone number
Precautions:
1. Limit the number of times per day for each phone number is sent, it refused to send more than the number of times, indicating the number of times over the day.
2. Each ip limit the maximum number of restrictions. It refused to send more than the number of times, suggesting more than the maximum number of ip sent the same day.
3. limit each phone number to send time interval, such as two minutes, no more than two minutes, allowed to send frequent prompts.
4. Send message to increase authentication code, the server and enter the verification code comparison, do not match, reject the transmission.
Whether at login can be bypassed
Unreliable distal check
There will still be many sites they do not have strict identity verification, they are often sent via JSON data to rely on the account password after the return to determine the identity of the user is correct, which exposed a huge loophole, this loophole it is quite easy to use, often only need a security boundary artifact BURP to complete authentication bypass, enter the correct accounts and random password at login, the message intercepted, then select burp interception inside return function package capture status codes returned.
Almost all sites need to have a login password and then forget the password reset function, if the password reset functionality at the site code is not precise enough, will cause any password reset logic vulnerabilities.
1, failure code, an attacker may be achieved by any user password reset blasting other users phone code
* 2, the verification code is not bound users: that is, we can use their mobile phone number to successfully verified phone code, however, to submit someone else's cell phone number submission to change the password at to achieve change other people's passwords
2.3, modify the phone to receive verification codes or mail: When we change the password, enter the correct user name and click Send verification code, packet capture, packet have found the user name corresponding to a cell phone or email, we will change it for their own phone or email to receive a verification code. Enter the code that we receive, we can achieve reset the user's password. (Here there is a leak of information that will be able to know the phone know the user name or mailbox for the user's)
1.4, skip verification: the site of the procedure to modify the password, do not check, can lead directly into the final edit link passwords, jump directly to that page, then enter the new password to achieve the purpose of resetting your password. First, we use a process to go their own account, get links to pages for each step, and then enter the new password link records corresponding to page 3, when the user resets the others, after obtaining the verification code, enter the password change page link directly to the new password interface, enter the password reset successfully.
5, cookie value substitution: Reset Password get to that point when the only judge a unique user ID cookie, the cookie does not determine the password reset process has not previously verified, leading to alternative cookie to reset the user password to others. Reset your user password to reach the final stage, captured packets and other users retrieve cookie in the first phase, we crawled to replace the cookie packets, the developer test.