[Bug]: Lack of Rate Limiting in Transaction Status Check

What happened?

Lack of Rate Limiting in Transaction Status Check

Vulnerable Code

https://github.com/etherisc/flightdelay-ui/blob/develop/src/app/api/purchase/%5Btx%5D/route.ts

The vulnerability arises from the absence of rate limiting in the GET function, which processes incoming requests to check the status of a transaction.

Here is the relevant portion of the code:

export async function GET(request: NextRequest, { params } : { params: { tx: string } }) { const reqId = nanoid(); const txHash = params.tx; const signer = await getBackendVoidSigner();

// fetch rating data from flightstats
const { policyNftId, riskId } = await checkPolicyCreated(reqId, txHash, signer);

if (policyNftId === BigInt(0)) {
    return Response.json({ error: 'Policy not created yet' }, { status: 202 });
}

return Response.json({
    policyNftId, riskId
}, { status: 200 });

}

Description

The GET function is responsible for checking the status of a transaction related to policy creation on a blockchain.

It accepts a txHash parameter from the request and performs operations to retrieve transaction details. However, the code does not implement any form of rate limiting, allowing clients to send an unlimited number of requests in a short period. This lack of control can lead to several security and operational issues.

Impact.

Denial of Service (DoS): An attacker could exploit the lack of rate limiting by sending a large number of requests in rapid succession, overwhelming the server and causing it to become unresponsive. This would result in a denial of service for legitimate users.

Resource Exhaustion: High volumes of requests can lead to excessive consumption of server resources, such as CPU, memory, and bandwidth.

This can degrade the performance of the application and affect other services running on the same infrastructure.

Increased Operational Costs: Without rate limiting, the server may incur higher operational costs due to increased resource usage, especially if the application is hosted on a cloud platform with usage-based billing.

Security Risks: An attacker could use brute force or other automated techniques to exploit vulnerabilities or gather information, knowing there are no limitations on request frequency.

Severity.

Critical: The severity is critical due to the potential for application-wide denial of service, resource exhaustion, and increased operational costs. The lack of rate limiting exposes the application to a range of potential exploits that could disrupt service and compromise reliability.

Proof of Concept (PoC)

Setup: Deploy the application and ensure it is accessible via a network request.

Execution: Use a tool like ab (Apache Benchmark) or a script to send a large number of requests to the GET endpoint in a short period.

ab -n 1000 -c 100 http://your-server/api/endpoint?tx=validTxHash Observation: Monitor the server's performance and responsiveness. Observe any degradation in service or denial of service as a result of the high request volume.

Suggested Fix.

Implement Rate Limiting: Introduce rate limiting to control the number of requests a client can make within a specified time frame. This can be done using middleware or third-party services.

import rateLimit from 'express-rate-limit';

const limiter = rateLimit({ windowMs: 15 60 1000, // 15 minutes max: 100, // limit each IP to 100 requests per windowMs message: "Too many requests from this IP, please try again later." });

app.use(limiter);Monitor and Log Requests: Implement logging to monitor request patterns and identify potential abuse. This can help in detecting and mitigating attacks. Use logging tools to track IP addresses, request rates, and any anomalies.

Use a Web Application Firewall (WAF): Consider using a WAF to provide additional protection against DoS attacks and other malicious activities. A WAF can help filter and monitor HTTP requests, blocking those that appear to be malicious.

Implement IP Blacklisting: In addition to rate limiting, consider implementing IP blacklisting for repeated offenders. If an IP address consistently exceeds rate limits, temporarily block it to prevent further abuse.

Graceful Degradation: Design the application to degrade gracefully under high load. This might include returning cached responses or providing a limited set of functionalities to ensure that the application remains available to some extent.

Load Balancing: If applicable, use load balancing to distribute incoming requests across multiple servers, reducing the risk of a single server becoming overwhelmed.

What operating system are you seeing the problem on?

Other (please mention in the description)

What browsers are you seeing the problem on?

Other (please mention in the description)

What wallet extension are you using?

Other (please mention in the description)

Rules

[X] I agree to follow this project's rules

etherisc / flightdelay-ui