title: [Reprint] Practical Problem Series: How to Prevent Company SMS Interface Attacks
date: 2021-08-06 08:51:49
comment: false
toc: true
category:
- Tips
tags: - Reprint
- Attack
- Prevention
- SMS
- Interface
- Problem
This article is reprinted from: Practical Problem Series: How to Prevent Company SMS Interface Attacks
After the emergence of QQ and WeChat, it seems that SMS has no special use for individuals. Communication between friends is usually done through WeChat (and sometimes QQ), which has gradually diminished the use of SMS. However, as developers, we still come into contact with SMS platforms.
The current uses of SMS are:
- Security verification for websites and apps (registration, login, password modification, etc.)
- Advertising push and harassment
- Birthday wishes (from financial management, insurance, banks)
- Girlfriend's birthday
- And those who are confident in selling counterfeit goods (interested readers can refer to the end of the article)
- .......
Currently, Alibaba Cloud, Baidu Cloud, and Tencent Cloud all have their own SMS platforms, and they are also integrated into our system.
In the past, we configured one of these SMS platforms in the production environment, and it has been running for 2 years.
During recent usage, there was an incident where several tens of thousands of SMS messages were maliciously sent (it is best to enable the maximum daily limit on the platform, but we did not).
Some of our SMS interfaces are public (such as the forgot password and registration functions), which can be directly called via the API without authorization. We have also implemented some frequency controls in our system, but we did not restrict by IP.
How should a SMS function be developed to ensure security?
In short: There is no absolute security on the Internet. Security is relative, and it is about increasing the cost for attackers as much as possible.
For beginners: They only consider whether they can send SMS messages, study the SMS platform interface documentation, write code for debugging, and finally be able to send SMS messages successfully. They write business-related code, store and cache relevant information, and wait for verification. Thus, the development of a SMS function is completed.
For experienced developers: They study the SMS platform interface documentation, write code for debugging, and can send SMS messages successfully. They continue to encapsulate the SMS interface and add frequency controls, such as SMS sending interval, verification code expiration time, limit on the number of times the same account can send messages, interval for limiting the number of times, etc. The configuration is as follows:
captcha:
sms:
# Expiration time of SMS verification code (minutes)
expire: ${SMS_EXPIRE:5}
# Interval between sending verification codes (seconds)
interval: ${SMS_INTERVAL:60}
# Limit on the number of times the same account can send messages
limit-time: ${SMS_LIMIT_TIME:10}
# Interval for limiting the number of times (hours)
limit-interval: ${SMS_LIMIT_INTERVAL:12}
They also add IP restrictions to the interface calls (to prevent frequent calls to the same interface from the same IP), and then write business code to complete the development.
They can also filter out some invalid SMS messages, such as:
1. Phone Number Validation#
Do not send SMS messages to invalid phone numbers. You can use the Google component to check phone numbers, which can validate both domestic and international phone numbers.
<dependency>
<groupId>com.googlecode.libphonenumber</groupId>
<artifactId>libphonenumber</artifactId>
<version>8.12.6</version>
</dependency>
2. Registration Function#
Do not send SMS messages to phone numbers that already exist in the system. When sending SMS messages, check if the phone number has already been registered, instead of checking it when submitting the registration data.
3. Password Modification#
Do not send SMS messages to phone numbers that do not exist in the system. When sending verification codes, check if the phone number belongs to a user in the system.
The above solutions only implement frequency controls for the same phone number and IP. However, if the attacker uses different phone numbers to send SMS messages by constantly changing IP addresses, it will be impossible to avoid wasting SMS messages and harassing users.
To solve this problem, you can use image-based CAPTCHA or behavior-based CAPTCHA.
Image-based CAPTCHA is relatively simple and does not require spending money. You can develop it yourself. The effect is as follows:
This visually looks laborious and requires additional user input, resulting in a less optimal user experience. Moreover, machine recognition and parsing of the text in the image are relatively easy. If you want to increase the difficulty of machine recognition, you need to increase the blurring of the image, which will result in a higher error rate for users and a worse experience.
Behavior-based CAPTCHA reminds us of the frustrating image verification used by 12306 when buying train tickets during holidays. It is a click-based CAPTCHA, as shown below:
There is also the more commonly used drag-and-drop CAPTCHA, as shown below:
This provides a much better user experience, is more convenient and visually appealing, and the background image can also be used for advertising.
The core idea of behavior-based CAPTCHA is to use the user's "behavior characteristics" to verify security. Through machine learning and deep learning, a large amount of analysis is performed on the user's behavior characteristics. A security model is established to distinguish between humans and machine programs. The neural network constructed using deep learning can continuously learn and continuously learn new feature analysis during the verification process (source: Baidu Baike).
Most companies do not have the ability to develop this themselves and need to spend money to purchase it.
If you don't want to spend money, you can implement a simple slider by cropping the image. The server records the distance from the slider crop to the edge of the image, and sends the original image and the slider to the front-end. After the user slides it, the front-end sends the sliding distance to the server, and the server verifies it by comparing the distance the user dragged the slider with the correct distance (this method is not very secure).
Another method is to add API rate limiting.
In summary:
- Implement frequency controls, such as
SMS sending interval,verification code expiration time,limit on the number of times the same account can send messages,interval for limiting the number of times. - Increase the frequency control for IP calls to the interface.
- Avoid unnecessary interface calls through validation, such as
phone number format validation,registration function: do not send messages to phone numbers that already exist in the system,password modification: do not send messages to phone numbers that do not exist in the system. - Add behavior-based CAPTCHA.
- Implement rate limiting.
"As the saying goes, there is no absolute security. Security is a battle between offense and defense."