Security

We know that security is important to customers. We take the responsibility to ensure that the 8x8 Embeddable Communications and APIs platform is absolutely secure, private, and reliable, so customers can have peace of mind: Security Page on 8x8 Website

Built-in security

8x8 proactively provides application security and authentication to all our users by building security right into our software:
​

  • Two-Factor Authentication (2FA) to the 8x8 Connect customer portal can be achieved via the Authenticator app or SMS Verification (OTP).
  • 8x8 Connect supports single sign-on via SAML.
  • Number Lookup API: Cleans user database and steps up on anti-fraud measures by checking the validity of phone numbers and their current locations.
  • Mobile Verification API: Generates and authenticates SMS-based or phone call-based mobile verification requests.
  • Number Masking API: Enables users to connect to a phone call while keeping their phone numbers private.
  • Remove Personally Identifiable Information (PII) API: Removes PII for particular messages from 8x8 databases.

SMS Flooding Attacks

Overview

For customers who expose the API endpoints publicly and route traffics to the 8x8 Embeddable Communications and APIs platform, your endpoints might be susceptible to various attacks. As attackers increasingly automate attacks, it’s easy for them to target hundreds, if not thousands of services at once.
For these reasons, it is important to understand what are the threats and how to stop them.
​
In this section, we will discuss the risk of SMS flooding attacks specifically and what are the possible mitigations to protect your business.
​
1. What is an SMS flooding attack?
An SMS flooding attack occurs when a high volume of cellular SMS messages are sent to saturate and overload the website’s backend. In your normal business activity, you may allow the user to send a request to an interface that triggers an SMS message to be sent back to the user’s phone number (e.g. verification code for sign-up or sign-in). However, if there is no defense to protect the SMS interface, attackers can leverage programs to send high-frequency requests to these interfaces and resulting in the following harms

  • Excessive SMS charges caused by malicious traffic.
  • User information leaks (bypass 2FA using brute-force against the account).
  • Performance degradation for legit users. SMS API rate limiting might be applied in extreme cases.
  • Brand reputation damage for harmed SMS recipients.

Mitigations

To protect your business from such attacks, we believe in a shared responsibility model between 8x8 and you as a customer. You may consider the following measures that can be leveraged for mitigating such attacks:

  1. Captcha: A CAPTCHA is a type of challenge-response test used in computing to determine whether or not the user is human. We recommend our customers implement such features on their applications.
  2. Web Application Firewall (WAF): Firewalls that protect web applications by filtering and monitoring HTTP traffic between a web application and the Internet. We recommend our customers deploy WAF(s) on their networks.
  3. Rate limiting: Rate limiting is a strategy for limiting network traffic. It puts a cap on how often someone can repeat an action within a certain timeframe. You can enforce rate-limiting in your service to prevent excessive traffic volume. Also, we offer basic rate limiting by clientIp with some endpoints in the 8x8 Embeddable Communications and APIs platform out of the box. You can leverage this feature to add a quick security defense in place. We will discuss more details in the [next section] (https://developer.8x8.com/connect/docs/security-1#client-ip-rate-limiting)

Client IP Rate Limiting

1. Why do we offer rate-limiting by client IP address?
The purpose of using client IP for rate limiting is to control traffic from the same origin IP that could potentially cause harm to your service. And this is a built-in feature in some APIs offered by the 8x8 platform.
In your business cases, you may want to implement a simple security defense to block some common automated scripting attacks. You can leverage this feature from us to gain security capability quickly in the most cost-effective way. In the meantime, as your business grows, you can consider scaling your security with more sophisticated protection and commercial security product (like WAF) as your business needs.


2. How to use rate-limiting with client IP
There are many ways how to apply this measure in your business context. You may want to enforce the rate limit in your service locally after obtaining the actual origin IP of end-users, or you can delegate the rate-limiting to us simply by filling up the clientIP field with that IP address. Endpoints that support rate-limiting by clientIp are:

  1. Code generation API
  2. Send SMS API
  3. Send SMS batch API
    ​
    To enable IP rate limiting to these endpoints for your service, you will need to do it in 2 steps:
    ​
    Step 1:
    ​
    Submit the request form on the Help Center portal. The content should be similar to the following screenshot. The customer support will help you create the IP rate limiting rule specifically to your SubAccount and its related endpoint.
    ​
    ​
1312

​
Step 2:
​
Fill up the clientIp field in the request with the origin client IP address and forward the request to 8x8 APIs.

636

3. Risk of IP spoofing vulnerability
Please be aware that one of the common attacks to circumvent IP rate limiting is IP spoofing. Normally, an attacker sends a large amount of traffic by rotating different proxies to hide its actual origin IP. Hence, to fetch the actual origin client IP, you will need to look up the X-Forwarded-For header in the HTTP request if it is tunneled by a proxy. The X-Forwarded-For contains a list of IPs that includes proxy IP and actual origin IP addresses with the following format:

X-Forwarded-For: <client>, <proxy1>, <proxy2>

Examples:

X-Forwarded-For: 2001:db8:85a3:8d3:1319:8a2e:370:7348
X-Forwarded-For: 203.0.113.195
X-Forwarded-For: 203.0.113.195, 70.41.3.18, 150.172.238.178

It is important to parses the IP address correctly from this header, instead of always getting the first one from the list (cause it might be replaced to fake IP by a bad actor proxy).

​
Useful Links:​