App Test Retrieve password _ Test magazine

In the age of mobile interconnection, everyone's smartphone is equipped with a variety of apps, then we use these apps will be used to retrieve the password of this function, this feature is very convenient for users, but if this function is not done well, or for test engineers, if the function is not tested well, can also cause some serious consequences, such as arbitrary user password reset, user data leakage and a series of security issues. This seemingly simple function, but the development engineer dug a lot of holes, we accidentally fall down. Let's explore the holes in the app's ability to retrieve the password.
The app-side phone-back password process is usually as follows: Enter the phone number-get the SMS authentication Code-set the password
The following figure:



Pit 1: The verification code is not tied to the cell phone number
Test process: Retrieve the password, enter your mobile phone number point to obtain the verification code, at this time the verification code will be sent to their mobile phone, input to obtain the verification code, this time to modify the mobile phone number B (b is also registered users), click Next to set the password. See if you can reset the success. In the actual testing process, some apps can reset successfully. That is, using your own phone to obtain the authentication code, reset User B's password. This crater is an obvious logical loophole, and it's obvious that the program doesn't bind the verification code to the phone number. As long as the verification code is legitimate, you can reset any user's password, a small logic error, resulting in a serious consequence, if as a tester, did not test such a problem, in the market let the user feedback back, Whether we will be held accountable, it depends on the mood of the boss. Feel like this developer must have a grudge against the test, or how to dig a hole like this.
Pit 2: SMS authentication code out of the packet returned now
As we all know, our app client and server interact with HTTP or HTTPS protocols in general. For the HTTP protocol, I send a request message to the server, and the server returns a response message. The authentication code sent to the user is also in the packet returned by the server. That means anyone can get this captcha, and then you can reset the password with a captcha. At this time the verification code is in a fake, resetting someone else's password becomes so simple, you are afraid.
Testing process: This test process to use the help of grasping bag tools, such a lot of tools, you can choose at will. I use here is the Fiddler, first sets up the mobile phone proxy to surf the net, the handset network and the computer is in the same WiFi, the proxy port sets and the fiddler and the Port are consistent. The specific setting of the tutorial can be online search, set up, start the app, grab bag.
... ...
Turn from: http://www.51testing.com/html/65/n-3704165.html