Web Security Test Learning Handbook-business logic Testing

Web Security Test Learning Handbook-business logic Testing

First of all, thank the friend of the invitation HTTP://PAYLOADS.ONLINE/ARCHIVERS/2018-03-21/1, participated in the <web Safety test Study Manual > Related writing, currently responsible for business logic test this piece of writing, is now initially formed , first sent out to let us see, welcome comments, you can join us to write ~

Business logic Testing

Description: This article introduces the security flaws in the Web application business logic and explains the common cases.

Any user password reset common defects * 1. Verification code Type Defects

-Scene: 1.1 Verification code Echo on the client (response body, Set-cookie, etc...).

1.2 Verification code is too simple and time-sensitive, the interface is not limited (usually a pure number of 4-8 digits, time-sensitive up to 30 minutes or more can be enumerated code verification).

* 2. Non-verified permissions/front-end check/ultra vires

-Scene: 2.1 Any phone number verification code can reset any account.

2.2 Modify the body of the response package (depending on the actual situation, such as the subject of the response message corresponding to the validation request, false you can modify it as true ).

2.3 The same browser enters the reset of the a user and then closes the reset to the B user and actually resets the a user.

2.4 Modify the parameters associated with resetting the password (e.g. UserID, etc...).

* 3.HOST Head Forged

-Scene: 3.1 In the mailbox to retrieve the password, you can simply replace the host part of the fuzz, to see if the password to retrieve the link in the domain name is based on the host to generate if it can be replaced by their own domain name. But this kind of thinking is very chicken, because it needs the user's click, so that you can see the link to reset the password according to the log, in case the link to reset password timeliness past helpless.

* 4. Password recovery is fragile

-Scene: 4.1 has seen the most is to retrieve the password token is Base64 encoded, and the decoded text according to its rules can be changed to be someone else's user password to retrieve the credentials.

Verification code bypasses common defect Graphics Class Captcha Bypass * 1. Graphics verification code can be reused

-Scene: 3.1 After the verification code has been refreshed, the verification code of the history refresh can continue to be used.

3.2 Verification code after use does not refresh, time-sensitive period, can be reused.

* 2. Easy identification of graphics verification code

-Scene 4.1 The display of many verification codes is simple and easy to be recognized by the machine.

SMS Class Verification Code Bypass * 1. Verification code is too simple & interface is not limited

-Scene: 1.1 Some SMS Verification code is 4-8-bit pure digital verification code, in the case of no restrictions on the interface can be directly exploded.

* 2. Verification code send multiplexing & timeliness too long & interface not Limited

-Scene: 2.1 6-digit verification code time is 5 minutes, but here the same mobile phone number to send the verification code is the same, so can be in 4 minutes to resend the verification code so that the verification code is valid again, because the verification code has been reused, so it can be exploded.

* 3. Universal Verification Code

-Scene: 3.1 This is a lot of big enterprise's criticism, before the launch to facilitate the test added 888888 , 000000 such a universal verification code but after the online did not delete the content of the test to be exploited.

SMS/Voice Verification Code replay

Whether it is to send text messages or voice verification code to do verification, are required mobile phone number, and send verification code is actually cost, need to be with the operator or a third-party verification code platform to cooperate, most of the verification code of 0.01 yuan A, of course, there are cheaper, so this side of the problem will affect the assets of an enterprise.

Common defects * 1. Unlimited send

-Scene: 1.1 The vendor sends this piece to the verification code and does not have a time limit to send

* 2. Code layer Logic Check problem

-Scene: 2.1 Many manufacturers will limit the number of mobile phones, if sent within 60 seconds will not be sent, but programmers in the design of the code layer of logic, there are many wonderful problems, for example, in order to facilitate the user experience, the normal code layer of the process is:

a.去除用户手误输入的空格以及一些特殊符号

b.验证手机号是否发送过验证码

Some programmers will design the process like this:

a.验证手机号是否发送过验证码（发送过则不放行 没发送过则进入下一步）

b.去除用户手误输入的空格以及一些特殊符号

c.发送手机号验证码

* 3. Mobile phone number can traverse send

-Scene: 3.1 I mentioned earlier that the verification code sent will affect the enterprise assets, then send the verification code limit can not only for a single mobile phone number limit, such as I can load a bunch of mobile phone number dictionary, and then directly traverse the sending verification code, which is also one of the hazards.

Business process Bypass Common defects * 1. No verification step skipping

-Scene: 1.1 There are a lot of scenes: password reset steps, payment steps, there are many ways to test this:

A. Contrast method, use a, b two accounts, a account to go through the process normally, then record the process request message and response message, use B account to test whether can bypass directly into the last step.

B. Sixth Sense, assuming that the URL of step 1 is:, this time http://www.test.com/step1 you can rely on your sixth sense to modify the following link to /step2 test.

Cryptographic algorithms fragile common defects * 1. Front-end rendering encryption algorithm code

-Scene: 1.1 Many vendors algorithm write very good, can not be useless, because he uses the JS code, in the front end will be able to see directly, and try to track JS code will know how to encrypt so can directly bypass.

* 2. Weak algorithm, clear text can be judged

-Scene: 2.1 This is a look at the problem of luck, a piece of ciphertext for MD5, at this time you have to do your own analysis of what is clear, and then go to collision, for example, may be MD5 (username + mailbox) such a combination.

Common flaw in Payment logic vulnerability * 1. Amount modified

-Scene: 1.1 Payment process There are many elements involved in the amount can be modified freight, preferential price, discount, etc. can be modified to negative amount can also be modified to less than the original amount of the number of test, sometimes encounter 溢出 , you modify the amount for a larger number to see you will appear only pay 1 yuan of the situation.

* 2. Quantity modification

-Scene: 2.1 Modify the number of items purchased is a decimal or negative, ditto, sometimes 溢出 you will encounter, you modify the number for a larger number to see you will appear only pay 1 yuan case.

* 3.sign Value Reversible

-Scene: 3.1 This is a look at the problem of luck, sign most of the comparison to confirm the amount of a piece of content, many are MD5 encrypted, at this time you have to do your own analysis of what is clear, and then go to collision, for example, may be MD5 (order number + amount) such a combination, Then modify the amount to regenerate sign to bypass the fixed limit of the amount.

Conditional competition (HTTP concurrency) Common defects * 1. Conditional contention (HTTP concurrency)

-Scene: 1.1 In the scene of check-in, transfer, redemption and purchase, the problem is most likely to occur, while the method of concurrent testing can use Fiddler or the Burpsuite Intruder module.

Here are examples of the Fiddler test method (Burpsuite test is simply not explained):

Configure the agent, set up the interception:

Then click on the Last button of redemption, transfer, check-in and so on to catch a request, right-click this request and then hold down SHIFT and tap Replay->reissue requests:

Fill in the number of times you want to re-send:

Typically 20, then click Go Release:

Finally look at yourself to determine if there is a concurrency problem, such as check-in, if there is a sign in the number of days or sign in the reward will be a lot, you can also see the response message results in Fiddler.

Web Security Test Learning Handbook-business logic Testing