How to realize the infamous mobile phone verification code function



Now basically all kinds of mobile phonesAPPRegistration will use mobile phone verification code, including somePCThe mobile phone number will also be used as the unique identification verification for the end website!

Coincidentally, Xiao Ming’s boss asked him to develop a user registration function, and forced users to register and bind mobile phones. He called it in order to improve security, ha ha ha, in order to collect more user information.


Generally speaking, sending mobile phone verification code should not be too frequent. After clicking the front-end send button, there will be one60Second countdown function. In other words, if the user clicks send and does not receive the verification code, it can only be retransmitted after 60 seconds.

So the problem is, if the user bypasses the front end and goes directly to the backgroundAPISend a SMS request, and then write an infinite loop script. I believe that your SMS account will send a warning message soon (generally speaking, large SMS companies have the function of warning setting).

It’s very simple. You just need toF12View the sending request to find out the background request address, and then you can enter the relevant information in the consoleJSCode, execute a hundred thousand times, isn’t it cool?

Here, take qiniuyun as a test case, open the registration page, F12 enters debugging mode, input the mobile phone number, and manually click send to obtain the background request address of SMS sending. The following is a short message sending request from qiniuyun. After testing it, Zhu Zhu didn’t reach his expectation. After all, it’s a big factory, and the defense measures are still very strong.

Here areJSScript, copy and paste to the console, and press enter to execute:

var data = {"operation":1,"is_voice":false,"mobile_number":"17762018888","captcha_type":2};
for (var i = 0; i < 10; i++) {
        type: 'POST',
		contentType: 'application/json;charset=UTF-8',
        url: '',
        success: function(data) {

The console returns the following information. The first three requests are successful, and the later one has the verification code verification and current limiting operation.

{"code": 7209,"message":"captcha required"}
{"code": 7209,"message":"captcha required"}
{"code": 429,"message":"too many requests"}
{"code": 429,"message":"too many requests"}
{"code": 429,"message":"too many requests"}
{"code": 429,"message":"too many requests"}
{"code": 7209,"message":"captcha required"}

The main user tried to refresh the page, randomly entered a mobile phone number, and then click send again to prompt the user to enter the verification code. This obviously strengthened the prevention and triggered the malicious request authentication interception mechanism.

Security mechanism

For developers, they should not only consider the user’s normal access to the verification code experience, but also consider the security of the SMS interface. The author summarizes the following points, hoping to help you.

  • The background request limits the current and limits the sending frequency per unit time.
  • In the captcha mechanism, remember not to restrict the captcha at the beginning. The experience is extremely unfriendly. After triggering the current limiting, the captcha verification can be turned on.
  • Monitor the number of short messages sent each day, trigger a certain threshold to do corresponding processing, according to the actual business needs.
  • Verification code storage must be guaranteedkeyFor mobile phone number, remember not to use other logo askeyFor examplesessionId
  • Be sure to set the expiration time of captcha, such as five minutes, or less.
  • The verification code should be short and concise as far as possible, with four to six digits.
  • If there are no restrictions in the background, remember that the front desk must set a countdown limit to filter at least some small white users.

Code case

Let’s share a simple verification code generation, storage and invalidation code case to the partners:


import java.util.concurrent.ExecutionException;
import java.util.concurrent.TimeUnit;

public class Mobile {
     *The test is convenient, and 3 seconds failure is set here
    private static LoadingCache caches = CacheBuilder.newBuilder()
            .expireAfterWrite(3, TimeUnit.SECONDS)
            .build(new CacheLoader() {
                public String load(String mobile) {
                    return "";

    public static void main(String[] args) throws ExecutionException, InterruptedException {
        Integer code = (int)((Math.random()*9+1)*100000);
        System.out.println ("is it gone?"+ caches.get ("17762018888"));


Important functions must be verified before and after, when necessary, we must do a good job in limiting current, blacklist and other operations!!!