Registration interface attacked. Solution-php Tutorial

The registration interface is verified by a mobile phone. the verification code is sent to the mobile phone and the mobile phone is maliciously attacked. the mobile phone number is submitted at will, which consumes the SMS fee. the submitted forms, ip addresses, and mobile phone numbers are all random, the verification code has expired (the verification code information server saves the session), the cookie limit does not work, and the ip address is random. what should I do... register the API and send the verification code to your mobile phone.

Attackers can submit mobile phone numbers at will, consuming SMS fees,

The submitted forms, ip addresses, and mobile phone numbers are all random,

The verification code has expired (the verification code information server saves the session ),

Cookie restrictions are not good, and ip addresses are random. what should I do?

Even if you upgrade the verification code, it will sooner or later be cracked.

What other solutions are there?

Reply content:

Register the API and send the verification code to your mobile phone.

Attackers can submit mobile phone numbers at will, consuming SMS fees,

The submitted forms, ip addresses, and mobile phone numbers are all random,

The verification code has expired (the verification code information server saves the session ),

Cookie restrictions are not good, and ip addresses are random. what should I do?

Even if you upgrade the verification code, it will sooner or later be cracked.

What other solutions are there?

A simple and effective solution is to add an image verification code before sending it to prevent the machine from submitting the code.

You can consider this excellent verification code http://www.geetest.com/

Whether the image verification code is a good solution is questionable from the perspective of user experience.

Then, my suggestion is: Hide text box

1. add a text box to the registry list and hide it with css.

2. you can use javascript to occasionally update the value here, and then perform verification in the background based on your specific update rules. if the rule does not comply with, you can determine that it is a bot.

The API uses HTTPS + token + parameter encryption for transmission

Js obtains and transmits the cursor coordinates to the backend. the backend can process the coordinates in the registration button's coordinate area.

Restrict the same mobile phone number, that is, save the sending time after sending, and check whether the number has exceeded the valid time.
The invalid number indicates whether the verification is valid.
For a legitimate, random number attack, it is restricted by ip addresses. a single ip address can contain up to a few numbers within a period of time!
So much for now
Http://segmentfault.com/q/10100000007530... this is the same problem as you.

Which can be reproduced for you below

1. [Bind graphic verification code]-bind the graphic verification code to the mobile phone verification code. after you enter the mobile phone number, you must enter the graphic verification code to trigger the text message, this effectively prevents malicious clicks by software. This method is applicable to large websites.
   2. [process limitation]-the text message verification and user name registration are divided into two steps. after the user successfully registers the user name and password, the next step is to verify the text message.

3. [trigger condition]-the user must fill in all registration information before triggering. if the registration information is incomplete, the verification code cannot be sent.
Additional docking settings:

1. [SMS sending interval setting] -- sets the interval for repeated sending of the same number, which is generally set to 60-20 seconds;

2. [IP limit] -- sets the maximum daily sending volume of each IP address;

3. [Sending volume limit] -- sets the maximum number of sent messages per day for each mobile phone number;
   Currently, we recommend that you use 1st, 2, and 3 in combination with 456 to connect to the interface. To avoid unnecessary waste caused by text messages!

Except the verification code and signature, none of them are used.

The interface uses the server curl or flie_get_content request. The interface also needs to write a signature verification`

Data is submitted using ajax post, and cross-origin data cannot be submitted. data submitted in the same domain is also verified by signature.

We recommend that you use the mobile phone number attribution method to check whether the mobile phone number exists first. if the information is sent when the mobile phone number exists, you can set the region limit if you cannot.

Try the interface protection solution of yundun technology.

Record the ip address, phone number, and request time of each request for the verification code.
You can determine the time interval between the two requests at the next request.
For example, a verification code can be sent only once within 30 minutes.
In this way, if you want to consume your text message fee, you have to have multiple machines and multiple mobile phone numbers.

This is just my guess. I don't know if it's feasible.

The HTTP header and access records can be used to determine whether a user is normal. in general scripts, only HTML will be captured, and images, CSS, JS, and other content will not be requested;
There are also some HTTP headers, and the scripts are generally incomplete.
However, if you really want to do it, I think it's basically impossible to block random IP addresses and random phone numbers. this cannot be simply determined whether it's a normal user or an attack.

Use the verification code of 12306.

How many sets of verification code solutions are prepared and replaced randomly? can he change the verification code at a faster speed?

This is how the verification code is obtained when sent to the mobile phone. In the general logic process, the user investigates and registers the interface. you call the SMS interface, and the SMS platform calls your callback interface. You can also provide the verification code to the SMS interface and text message to the user. Users do not know if they do not have a mobile phone. I think it is necessary to spend money to find someone to do penetration testing. If the text messaging platform is secure and reliable, your problem becomes more serious.

Generate a signature using the private key, transfer the public key, and verify the signature by using the service.

Didn't I add tokens to interface requests? Or the token is easily cracked.