Welcome to the third lesson of the "A04: Insecure Design" course! In this lesson, we'll explore the importance of anti-bot verification in review submission systems. Bots can be used to submit fake reviews, which can significantly impact businesses and user trust.

Our goal is to understand how the absence of anti-bot measures can lead to vulnerabilities and to learn how to implement effective defenses to protect against such attacks. Let's dive in! 🤖

Insecure design refers to a category of weaknesses that stem from missing or ineffective security controls. It's not about a bug in the implementation but a flaw in the design itself—a failure to think like an attacker and anticipate how a feature could be misused. A review submission system without anti-bot protection is a classic example. The system is designed with the "happy path" in mind, assuming that only legitimate users will submit genuine reviews. This design fails to account for the "unhappy path" where automated scripts, or bots, are used to abuse the system.

Review bombing and fake review submissions have become significant global issues affecting businesses across various platforms. For instance, in 2021, Amazon reported removing over 200 million suspected fake reviews before they were seen by customers. These automated attacks can severely impact businesses, with studies showing that a one-star difference in ratings can affect revenue by 5-9%.

Consider an e-commerce platform where competitors use bots to submit thousands of negative reviews for a product. This not only misleads potential customers but also manipulates the platform's recommendation algorithms. Real-world examples include cases where restaurants have been targeted by competitors using bots to lower their ratings on popular review platforms, leading to significant business losses. The core vulnerability is the system's implicit trust in all incoming requests, which we will now examine in code.

Here's an example of a vulnerable review submission endpoint that lacks any form of protection against automated attacks, written using FastAPI. This code correctly validates the format of the incoming data but fails to validate the source or intent of the request.

This endpoint accepts review submissions without any mechanisms to distinguish a human user from a bot. It doesn't check how many reviews have been submitted from one source, nor does it require any proof of humanity (like a CAPTCHA). An attacker could easily create a script to flood this endpoint with fake reviews, potentially overwhelming the system and compromising the integrity of the review system.

An attacker can exploit this design flaw with a simple script. The goal is not to crash the server with a single request but to abuse its functionality at scale. The following shell script demonstrates how easily an attacker can submit thousands of fake reviews with minimal effort.

Let's break down this attack script:

• for i in {1..1000}: This loop runs the command 1,000 times.
• curl: A command-line tool for making web requests.
• -s: "Silent mode" to prevent curl from showing progress meters.
• -X POST: Specifies that this is a POST request, used for submitting data.
• -H "Content-Type: application/json": A header telling the server we are sending JSON data.
• -d "...": The data payload containing the fake review. The comment is slightly different in each iteration ($i) to bypass very basic duplicate-content filters.

When executed, this script floods the system with fake positive reviews for productId "123", artificially inflating its rating and damaging the platform's credibility. This demonstrates why we need robust anti-bot measures in place.

Now that we understand how vulnerable an unprotected review system can be, let's explore the measures we can implement to defend against automated attacks. A robust security posture relies on a "defense-in-depth" strategy, where multiple layers of security controls work together. Relying on a single defense is often insufficient.

To protect our review submission system, we'll implement three key defensive measures:

1. Rate limiting: This control focuses on the volume and frequency of requests. It restricts how many times a user (or IP address) can perform an action within a specific time frame, making large-scale automated attacks much slower and less effective.
2. Email Verification: This control ensures that users have verified their email addresses before they can submit reviews, significantly raising the barrier for creating fake accounts at scale.
3. CAPTCHA Verification: These controls focus on the legitimacy of each individual request, ensuring the user is likely human rather than an automated script.

While these are the measures we'll implement in this lesson, there are several other important anti-bot measures, such as biometrics and advanced user behavior analysis, that are often employed against these types of attacks.

To defend against automated attacks, we'll first implement rate limiting. The theory behind rate limiting is to enforce a policy on the frequency of requests from a single source, typically identified by its IP address. While determined attackers can use proxies to cycle through different IPs, this still serves as an effective first line of defense against simple scripts.

Here is an example using a simple in-memory approach in FastAPI to limit review submissions from a single IP address.

In this secured code, we track request timestamps for each IP address. We allow a maximum of 5 review submissions per IP within a 24-hour window.

• First, we get the client's IP address.
• Next, we clean up our list of timestamps for that IP, keeping only those within the last 24 hours (our WINDOW_SECONDS).
• Then, we check if the number of recent requests is at or above our MAX_REQUESTS limit. If it is, we reject the request with an HTTP 429 Too Many Requests status code.
• If the request is allowed, we record its timestamp. This simple mechanism effectively mitigates the curl script from the previous section, as the script would be blocked after the first five requests.

While rate limiting helps control the frequency of attacks, it doesn't prevent a determined attacker from creating multiple accounts. This is where email verification becomes a critical second layer of defense. By requiring users to verify their email addresses before they can submit reviews, we significantly raise the barrier for creating fake accounts at scale.

Why Email Verification Matters for Anti-Bot Protection

Email verification serves several crucial purposes in preventing bot attacks:

1. Account Creation Friction: Creating fake accounts requires access to valid email addresses. While free email services exist, creating hundreds or thousands of accounts becomes time-consuming and detectable.
2. Traceability: Verified email addresses provide a way to trace abusive behavior back to specific accounts and potentially identify patterns of abuse.
3. Cost Barrier: Many email providers have their own anti-bot measures, rate limits, and CAPTCHA requirements, adding layers of difficulty for attackers.
4. Deterrence: The verification step signals to potential abusers that the platform takes security seriously and has measures in place to detect and prevent fake accounts.

Database Model for Email Verification

To implement email verification, we need to extend our User model to track verification status. Here's what the model looks like:

The email_verified field is a boolean flag that defaults to False when a user registers. This flag is only set to True after the user successfully completes the email verification process.

With rate limiting and email verification in place, we can add another layer of protection by implementing checks that validate the legitimacy of the request itself. This includes verifying that the user is human and that their comment isn't obvious spam.

Below is an example of how you might add a CAPTCHA check and a simple spam filter to the endpoint.

Here, we've added several new checks that run after the rate limiter and email verification:

1. CAPTCHA Verification: We call a (placeholder) function to verify a CAPTCHA token submitted with the request. This helps ensure the user is human.
2. Spam Detection: We use a simple function to check if the comment contains an excessive number of links, a common characteristic of spam.
3. Data Validation: We ensure the rating is a valid integer within the expected range.

While we've implemented these measures specifically for our review submission route, in production environments, these protections are typically implemented at a higher level to be reused across the application. This follows the "Don't Repeat Yourself" (DRY) principle and ensures consistent security.

For instance, rate limiting might be applied globally as middleware to all API endpoints, with different limits for different routes. User status checks (like authentication and email verification) would also be handled in middleware that can be selectively applied to sensitive routes.

Some organizations also use Web Application Firewalls (WAFs) and advanced bot detection services that can identify and block suspicious traffic patterns across their entire application, providing yet another layer in a strong defense-in-depth strategy.

In this lesson, we explored the importance of anti-bot verification in review submission systems. We learned how the absence of such measures is an insecure design flaw that can lead to significant vulnerabilities. By implementing effective defenses like rate limiting, email verification, and CAPTCHA checks, we can protect our systems from bot attacks and maintain user trust.

As you move on to the practice exercises, you'll have the opportunity to apply what you've learned and reinforce your understanding. Keep up the great work, and get ready for more exciting lessons on web security! 🚀