[Penetration test] Insufficient rate limiting (email)

[elamcheliyan]

During our penetration test, we found that there is Insufficient rate limiting (email), please below detailed information.
Do you have suggestions on how we can overcome this situation?

Description:

There is no limit on the number of times a certain functionality can be requested.
Exploit preconditions:
The attacker needs to have access to the application and be on the internal network.

Impact:

Using it multiple times in a row may cause a (partial) denial-of-service. Since the functionality communicates with external services (such as an email provider), using it multiple times in a row may cause the application to become blacklisted or it a high financial cost. And since the functionality sends messages (such as e-mail), using it multiple times in a row may inconvenience regular users.

Recommendations:

Implement sensible rate limiting so that an attacker cannot abuse functionality by using it multiple times in a row.

[jpassing]

There are several quotas that implicitly limit the number/frequency of requests:

• Cloud Asset API:
  • AnalyzeIamPolicy Requests per day (applies to the PolicyAnalyzer catalog)
  • AnalyzeIamPolicy Requests per minute (applies to the PolicyAnalyzer catalog)
  • BatchGetEffectiveIamPolicies Requests per minute (applies to the AssetInventory catalog)
• IAM API
  • Read requests per minute
  • Write requests per minute

However, these quotas are not by user. So you're right that a single, IAP-authenticated user could exceed one of these quotas and thereby make the app temporarily unusable for other users.

If that's a concern, deploying Cloud Armor rate-limiting might be a good way to throttle/limit requests.

[elamcheliyan]

The above description issue which I have given is more generic approach of the problem. The actual problem is JIT backend allow to send role request approval notification email unlimitted rate,

Can anything do with the NotificationServices? based on the below call.(see below picture)

[elamcheliyan]

I have found two ways, and I want to know which one would be best. Can anyone help us?
Applying rate limit to the specifc REST API **public ActivationStatusResponse requestActivation() ** using the below solution
https://quarkus.io/guides/smallrye-fault-tolerance

or

Solution below which is Specific to avoid email flooding under SmtpClient.java
https://docs.fluidattacks.com/criteria/fixes/java/122/