---

most of your answers have a certain effect, which can make it more difficult to be attacked, and you can drop some low-end attacks on Filter. But in fact, it is futile in front of professional hacker.

essentially means that the client sends a request to the server, all the parameters of the request come from the client, and all the protective measures on the client are floating clouds. There are 1000 ways to prevent it, and there are 1001 ways to break it. If you have this skill, you might as well check the validity of the HTTP request on the server first. For example, a Firefox browser sends an SMS request to your APP server User-Agent: Firefox . Do you want to send it? The Refer of a request is www.duanxingongzhaji.com . Should you intercept it?

the most cost-effective thing is actually plus verification code , because attackers have fixed economic costs even for docking and coding platforms. There are plenty of naked interfaces out there, and SMS bombers will not target you unless someone is deliberately trying to mess with you. But the addition of CAPTCHA is followed by a decline in the user experience.

APP has been published. What if I can't add it? Cold salad! Either get promoted or continue to endure the attack .

for those who answer the restrictions on IP and mobile phone number, have you studied the question carefully?

use different ip, different numbers, different ip, different numbers, different ip, different numbers

IP can consider the identification of agents and data center IP. The cost of self-identification is too high, and you can interface with third-party saas services, but no one can identify agents 100%. 70% to 80% is about the same. In addition, some attacks are crowdsourced, initiated by broilers who have been hit by Trojans, and the machine itself is basically in the normal way of personal PC,.

Mobile phone number can only consider empty number detection, do not try to do this yourself, find a supplier, similarly, there is no 100% accuracy, and it is not real-time. Technically it can be helpful, but the product level may not be very elegant.

consider the attack mode of the attacker:

• for SMS bombers, where there is no purpose of attack, mobile phone numbers generally exist, and IP are scattered, normal IP,. Apart from CAPTCHA, there is really no way to prevent it. unless you know in advance that this number is being attacked

• for malicious hacker attacks, it is generally accompanied by a large number of empty numbers and proxy IP, if you must guard against it, you need a certain cost, otherwise you can only accept it.

the topic limit is relatively dead, above, hand in the paper ~

The most commonly used ways of

---

are
1. You can add the picture and text verification code
2. You can set Filter
3.ip restrictions based on your mobile phone number. You can request a duration within a single time range

---

.

the picture verification code is useless at all. You can use the coding platform at the low end and the QR code directly at the high end.

it is recommended to improve ip verification to capture the user's real ip instead of proxy ip address

when we encounter this kind of situation, there is no way to prevent it. From the development point of view, no matter what the other side does, we can use api

.

---

Picture and text verification code + parameters are encrypted to generate sign+ parameters to the server for verification

---

met before. There is no way to add the CAPTCHA immediately at the front end, while the other side is playing with text messages.
the solution at that time was:
the server shutdown turned off the request for SMS CAPTCHA.
for the API that requests SMS verification code from the server, the server directly sets the returned errorCode as an exception code, which can be captured by the front end, and then write the verification code into the error message and pop up. In this way, the user can still see the CAPTCHA.

< hr >

then sit down and add picture verification and so on

---

the form of binding between ip and mobile phone is not good. Normal users may not be able to use
1, limit the number of times their mobile phone number sends CAPTCHA
2, CAPTCHA
3, token

---

.

the following ideas are for reference only:

1. APP has been published, but others can use scripts to run the interface. The first feeling is that the security has not been done well, and the online interface must be enabled for https access. In this way, it will be much more difficult for others to grab the bag.

2. I personally feel that the API for sending SMS messages can not be exposed to the front end, that is, it is impossible to send SMS messages by calling an API directly. It can be used as a back-end service and can only be accessed by exposing it to API. The logic of sending text messages can be written in the logic of registration, login, etc.

3. check the parameters once. For example, you can combine the request parameters with a certain rule into a unique value. The server gets the parameter and combines it with the same rule to see if it is the same as the check value. If it is the same, continue with the operation. If the error is not reported to the client, the more difficult it is for others to crack your verification rule when calling your API. The harder it is for others to call through the interface.

4. for other restrictions, please refer to the ideas of the gods upstairs.

---

to tell you the inside story: many of them are brushed by SMS providers, and startups seldom have the time to engage in competitors!

not to mention servers with clusters switch to IP to browse, it is an underground industry chain

in addition, a simple picture verification code can still be cracked

---

is the interface written by the landlord open to the app of android and ios?
it would be easier if it were this.
first of all, if the attacker is a manual brush, there is nothing he can do about it. But the attacker is also very inefficient in doing so, and I judge that they must have carried out the attack through the program.
here's how to crack a program attack:
add a private key string to the client, and the server has the same private key string.
when the client requests the SMS interface from the server, the client encrypts the "private key string + mobile phone number" md5 into a token field. Then send the token and mobile phone number to the server.
after receiving the request, the server will encrypt the "private key and mobile phone number" md5 of the server, and send a text message if the same.
in this way, the attacker needs to crack your private key, which is very expensive.

---

We also encountered the same problem before. At that time, the front end could not be changed. Later, we analyzed the commonness of request packets. Because it is sent in batches with tools, there are some characteristics on the request header. Our API directly returns 200 after judging these characteristics, without following the business logic.

The reason for returning 200 directly is that we don't want the other party to know that we have taken defensive measures to prevent them from attacking further.

---

calling the payment interface plus CAPTCHA is the most basic respect for corporate finance.

Fortunately, the SMS service provider I use has its own defense against attacks.

---

think of a way for reference only.

under the premise of irreversible APP source code

• APP
  request SMS API getSms?phone= mobile number & sec= encrypted string & time= timestamp. For example, encryption uses a simple md5, encryption string sec=md5 (mobile number + timestamp + contract key).
• Server
  receives the request and determines that the transmission timestamp time and the current timestamp now_time, cannot be sent beyond X seconds (X=now_time-time), X prevents network delay and time difference, and then determines whether the transmission sec is consistent with the delivery sec, if the same encryption method allows it to be sent.
• there is a problem
  within X seconds, the user can grab the packet to the request and then brush the verification code. Therefore, the frequency limit is imposed at the background, and repeated acquisition is not allowed within 10 seconds / y seconds. This can basically prevent.

wap and pc pages using image captcha is probably the best solution right now.

---

I originally thought that if there was a homologous policy, there would be no outdomain that could be called, but later I found that there were still people who could do it with tools. Our company adopted

.

1. save the user's current ip+mobile into key of memcached , and value is the timestamp. Everyone knows how to play, and then take it out and calculate

.

2. prohibit possible cross-domain requests

3. the server generates tokens similar to CsrfToken on the front end of the page. When verifying with the backend, you can only verify 1 at a time. If you succeed, you need to generate new tokens to the front end, because you need to consider the waiting time of lovely users sometimes, otherwise the user experience will be poor

.

but when I saw that the landlord said that someone could change the ip and change the number, I thought it would be complicated. Anything can be done quickly

wait for the wonderful answer downstairs

---

add pre-send verification, which can only be generated manually, such as dragging verification code and jigsaw puzzle verification code. Token token authentication, Let each form submission only use

---

. I guess you use ajax to send the CAPTCHA. Generally, if you use the form token, of course, if you really use the script to do your CAPTCHA, the safest thing is to verify the picture CAPTCHA once and then use the expression token when you send the mobile phone CAPTCHA, which greatly reduces this possibility. If the user experience is not good, there are always risks. It depends on how you control

---

that you are all out.
We have also encountered this situation, where SMS verification codes can be called repeatedly by others indefinitely. In fact, this problem is very simple: those SMS bombardment and mobile phone bombardment software writers take advantage of the SMS API of the website.
our solution is that there is no problem with the first call, and the subsequent operation needs to enter the verification code, which will not be requested until the input of the verification code is successful, which can effectively prevent malicious calls from api. If you don't even want to send him the first message, verify the CAPTCHA before you send a text message (provided that the CAPTCHA is preferably hidden and displayed when you click a button or element)

---

that depends on whether you designed the CAPTCHA function and input the CAPTCHA before you can call it. This is the simplest method

---

it should be more appropriate to use picture verification code to obtain the verification code of SMS

---

APP has been sent, you can only restrict the call of the same IP and the same mobile number first, and then do the graphic verification code

---

< p. > in the next version. Each mobile number can only call the SMS interface 10 times a day.
2. Each mobile number can only be called once per minute.
3. Use token, to do a good job.

---

first confirm whether you are using the same user or the second account to register. These are two different processing directions, the same user or a fixed group of users in the brush, this is relatively simple, you limit users on the line. If you brush the trumpet registration, it involves the offensive and defensive war, you can reverse consider where the benefits of the other party brushing the trumpet registration are, for example, there are some coupons for new users, then you can make restrictions in this respect, or raise the registration threshold. The interim plan can make some regular restrictions (that is, offensive and defensive warfare, guerrilla warfare), but in the end, we have to hold on to the key points. There are also many temporary solutions, this kind of brush interface, will have certain behavior characteristics, according to the behavior characteristics to deal with.

---

there has been a lot of talk upstairs about how to avoid this problem, and I have revealed a possible scenario in which your company's SMS interface is abused: SMS bombers.

now there is a service called SMS bomber. To put it bluntly, people who use this bomber software only need to fill in a mobile phone number, and this mobile phone number will continue to receive a lot of spam messages, which is annoying. But what are these messages about? If you open it, you will only find that there are basically all kinds of websites, APP registration verification SMS, password recovery SMS, login verification SMS, etc., especially registration verification SMS. In principle, this SMS bomber is actually very simple, that is, it collects a large number of SMS interfaces for sending CAPTCHA codes on some websites or APP, and then uses these interfaces to send verification text messages to designated mobile phone numbers. once more items are collected, there will be a steady stream of text messages sent to the specified mobile phone number.

this kind of IP that usually sends verification text messages is the IP address of the person who uses the bomber software, so it is difficult to send Filter messages according to the IP address. However, I believe that people who engage in this kind of prank software are generally lazy to crack CAPTCHA (they want as many interfaces as possible), and a small CAPTCHA is very useful in many cases.

---

the verification code cannot be too simple. Note that the Filter ip, project recommends the introduction of third-party verification services.

---

the answers above are all nonsense. Since they are malicious, they must be using vps so that there will be endless ip,. We can set a policy of dynamic blocking of a single ip per second or post per minute. Note that it is blocked at the application layer, not at the network layer or at the transport layer. With the automatic lifting of the ban on redis, ngx_dynamic_limit_req_module this module is sufficient to meet a variety of needs for use in a multi-level pv environment. You only need to configure it on the server side to https://github.com/limithit/n.

.