i Spring and Autumn Writer: Vulkey_Chen
First of all, I would like to thank my friend Qingxuan for the invitation http://payloads.online/archivers/2018-03-21/1 , who participated in the relevant writing of < Web Security Testing Learning Manual>, and is currently responsible for the writing of business logic testing. It has been formed, and I will send it out for everyone to see. Comments are welcome, and you can join us to write together~
business logic test
Introduction: Here is an introduction to the security flaws in the business logic of web applications and explanations of common cases.
Any user password reset
Common defects
* 1. Verification code defects
- Scenes:
1.1 The verification code is echoed back on the client side (response body, Set-Cookie, etc...).
1.2 The verification code is too simple and the timeliness is too long, and the interface is not limited (usually it is a pure number of 4-8 digits, and the timeliness is more than 30 minutes, and the verification code can be enumerated).
* 2. Unverified authority/front-end verification/overauthority
- Scenes:
2.1 Any mobile phone number verification code can reset any account.
false 2.2 Modify the body of the response packet ( you can modify the body of the response packet corresponding to the verification request according to the actual situation true).
2.3 The same browser enters user A's reset, then closes and then enters user B's reset to actually reset user A.
2.4 Modify the parameters related to reset password (such as userid, etc...).
* 3.HOST header forgery
- Scenes:
3.1 When retrieving the password in the mailbox, you can simply replace the Host part for fuzzing, and see if the domain name in the link to retrieve the password is generated according to the Host. If it is, you can replace it with your own domain name. But this kind of thinking is very tasteless, because it requires the user's click, so that the link to reset the password can be seen according to the log.
* 4. The credentials to retrieve the password are fragile
- Scenes:
4.1 The one I have seen most is that the token for password retrieval is base64 encoded, and the decoded plaintext can be modified according to its rules to become the credentials for other users to retrieve their passwords.
captcha bypass
Common defects
Graphical captcha bypass
* 1. Graphic verification code can be reused
- Scenes:
3.1 After the verification code is refreshed, the historically refreshed verification code can still be used.
3.2 After the verification code is used, it will not be refreshed, the validity period will not expire, and it can be reused all the time.
* 2. Graphic verification code is easy to identify
- Scenes
4.1 The display of many verification codes is very simple and easy to be recognized by the machine.
SMS verification code bypass
* 1. The verification code is too simple & the interface is not limited
- Scenes:
1.1 Some mobile phone SMS verification codes are all 4-8 digits pure digital verification codes, which can be directly blasted without any restrictions on the interface.
* 2. The verification code is sent multiplexed & the timeliness is too long & the interface is not limited
- Scenes:
2.1 The validity period of the 6-digit verification code is 5 minutes, but the verification codes sent by the same mobile phone number here are the same, so you can resend the verification code in 4 minutes, and the verification code will be valid again, because the verification code It has been reused, so it can be blasted.
* 3. Universal verification code
- Scenes:
3.1 This is the criticism of many large enterprises. Before it goes online, it is added for the convenience of testing 888888. 000000Such a universal verification code, but the content of the test is not deleted after it goes online, which leads to malicious use.
SMS/Voice verification code replay
Whether it is to send a text message or a voice verification code for verification, a mobile phone number is required, and sending a verification code actually requires a cost, and needs to cooperate with the operator or a third-party verification code platform. Most verification codes are 0.01 yuan One, of course, there are cheaper ones, so the problems here will also affect the assets of an enterprise.
Common defects
* 1. Unlimited sending
- Scenes:
1.1 The manufacturer does not limit the time to send the verification code
* 2. Code layer logic verification problem
- Scenes:
2.1 Many manufacturers will restrict the mobile phone number. If it is sent within 60 seconds, it will not be sent. However, programmers will have many strange problems when designing the logic of the code layer. For example, for the convenience of user experience, the normal code layer The process is:
a.去除用户手误输入的空格以及一些特殊符号
b.验证手机号是否发送过验证码
Some programmers design processes like this:
a.验证手机号是否发送过验证码（发送过则不放行 没发送过则进入下一步）
b.去除用户手误输入的空格以及一些特殊符号
c.发送手机号验证码
* 3. The mobile phone number can be traversed and sent
- Scenes:
3.1 I mentioned before that the sending of verification codes will affect the assets of the enterprise, so the limitation of sending verification codes cannot only be limited to a single mobile phone number. For example, I can load a dictionary of mobile phone numbers, and then traverse and send verification codes directly. This is also one of the hazards.
business process bypass
Common defects
* 1. No verification step skipping
- Scenes:
1.1 There are many scenarios: password reset steps, payment steps, there are many test methods for this:
a. Comparison method, using two accounts, A and B, account A will go through the process normally, and then record the request message and response message of the process, and use account B to test whether it can bypass and directly enter the last step.
b. The sixth sense, assuming that the URL of step 1 is: http://www.test.com/step1, at this time, you can use your sixth sense to modify the link to test /step2it .
Weak encryption algorithm
Common defects
* 1. The front end presents the encryption algorithm code
- Scenes:
1.1 Many manufacturers have written well-written algorithms, but they are useless, because they use JS code, which can be seen directly on the front end, and the code that tries to track JS will know how it is encrypted and can be bypassed directly.
* 2. The algorithm is fragile, and the plaintext can be judged
- Scenes:
2.1 This is a matter of luck. A piece of ciphertext is md5. At this time, you need to do your own analysis on what the plaintext is, and then collide. For example, it may be a combination of md5 (username + email).
Payment Logic Vulnerability
Common defects
* 1. Amount modification
- Scenes:
溢出1.1 In the process of payment, there are many elements involved in the amount of money. You can modify the shipping fee, preferential price, discount, etc., you can modify the amount to a negative amount or modify the amount to be less than the original amount for testing. If the number is large, you will only pay 1 yuan.
* 2. Quantity modification
- Scenes:
2.1 Modify the quantity of purchased items to a decimal or negative number, same as above, sometimes you will encounter 溢出a situation where you only pay 1 yuan if you modify the quantity to a larger number.
* 3.sign value is reversible
- Scenes:
3.1 This is a matter of luck. Most of the sign is a piece of content that compares the confirmation amount, many of which are encrypted by md5. At this time, you need to do your own analysis on what the plaintext is, and then collide, for example, it may be md5 (order number + amount), and then modify the amount to regenerate the sign to bypass the fixed amount limit.
Race conditions (HTTP concurrency)
Common defects
* 1. Conditional race (HTTP concurrency)
- Scenes:
1.1 Such problems are most likely to occur in check-in, transfer, exchange, purchase and other scenarios, and the method of concurrent testing can use Fiddler or BurpSuite Intruder module.
Here is an example of the Fiddler test method (the BurpSuite test is very simple and will not be explained):
Configure the proxy and set up the interception:
Then when you click the last button of exchange, transfer, sign-in, etc., you will catch a request, right-click the request and hold down Shift and click Replay->Reissue Requests:
Fill in the number of times to resend:
Usually 20 is enough, then click GO to release:
Finally, it is up to you to judge whether there is a concurrency problem, such as check-in. If there is, then it must be the number of days of check-in or the rewards obtained by check-in will suddenly be a lot. You can also look at the response message results in Fiddler.