Implement Rate Limiting to Prevent Mail Bomb Attacks

[ImanSharaf]

While we do have controls in the ASVS to verify against rapid transaction submissions (11.2.1) and to safeguard against excessive calls like mass data exfiltration, DoS attacks, etc. (11.2.2), we currently do not have a specific check against mail bomb attacks.

Applications with functionalities like password reset or email notifications often allow email sending without any rate limits. Malicious actors can exploit this to flood a target's mailbox, making it an attractive medium for mail bomb attacks. The impacts of such an attack can be significant:

Blacklisting: The mail server might get blacklisted by email providers, affecting its reputation and future deliverability.
SaaS Penalties: If a third-party SaaS solution is used to dispatch emails, the account could be banned or penalized for contravening its use policies.

ASVS Addition:
Ensure that functionalities allowing email sending have an associated rate limit to prevent abuse.

[elarlang]

I would say we have it general covered by anti-automation requirements 11.2.1 and 11.2.2 (like you mentioned yourself). I don't think we need special requirement for each separate topic, such as sending too many mails, although we have separate requirement for authentication.

#	Description	L1	L2	L3	CWE
11.2.1	[MOVED FROM 11.1.2] Verify that the application will only process business logic flows with all steps being processed in realistic human time, i.e. transactions are not submitted too quickly.	✓	✓	✓	799
11.2.2	[MOVED FROM 11.1.4] Verify that the application has anti-automation controls to protect against excessive calls such as mass data exfiltration, business logic requests, file uploads or denial of service attacks.	✓	✓	✓	770

One-two abstract requirements are better in a way - if you put some specific requirement on some topic, it may give understanding, that only those are required to protect and rest of it is not. With abstract requirement it matches for all.

In general, maybe it's more point of view - I don't watch ASVS as testing framework which need to cover all test-cases, but reporting framework, which you can use to report your findings. So, for my point of view 11.2.1 and 11.2.2 are enough to cover mail-bomb or whatever mass-call to some functionality problems.

[Sjord]

I also think that mail bombs can pose a risk, even though I think that the impact is not that great. I agree with Elar that the current requirements are sufficient.

It could be helpful to add another example to 11.2.2, but even then I would prefer describing it as restricting interaction with other systems, or restricting out-of-band communication, rather than email specific.

[elarlang]

@ImanSharaf - do you agree that it is covered by 11.2.2 (with or without text improvements) or you have some arguments why it should be separate requirement?

[ImanSharaf]

• Granularity Matters: While controls like 11.2.1 and 11.2.2 may capture the general idea of rate-limiting and anti-automation, email bomb attacks are a distinct threat with unique consequences, as you pointed out (e.g., email server blacklisting). Specific controls address distinct threats in a manner that's clear and actionable.

• Consistency in the ASVS: The ASVS itself differentiates between various forms of injection attacks. If the ASVS already distinguishes between types of injection attacks, why should it not offer similar granularity for other threats? This would maintain the integrity and consistency of the ASVS.

• Avoiding Ambiguity: While one can argue that 11.2.1 and 11.2.2 cover email bomb attacks in essence, leaving them as implied might lead to inconsistencies in interpretation. An auditor, developer, or tester could potentially overlook this risk if it's not explicitly stated.

• Guidance for Developers: Developers look at such standards to understand specific threats and their defenses. Generalized statements might not provide adequate guidance. Specific controls, like the one you're suggesting, can help developers implement precise defenses and not overlook a particular threat.

• Benchmarking & Reporting: From a reporting perspective, having a specific control about mail bomb attacks allows businesses to definitively state they have defenses against this specific threat. It can be more persuasive to stakeholders and clients compared to referencing a generalized control.

• Future Evolution of the ASVS: As threats evolve, the ASVS should evolve to cover new and nuanced threats. If the ASVS moves towards only general controls, it may not remain the comprehensive and trusted standard it is today.

• Principle of Least Surprise: Security professionals, when using a framework or standard, expect it to be thorough. Specific threats, especially widely recognized ones like mail bomb attacks, should ideally not be left out or left to interpretation.

What is your opinion @tghosth ?

[elarlang]

Nice arguments and it's good to understand the logic behind proposals.

One thing which I pointed out before:

In general, maybe it's more point of view - I don't watch ASVS as testing framework which need to cover all test-cases, but reporting framework, which you can use to report your findings.

So direction where I don't want ASVS to go is:

• duplicate testing guide, there is separate project for that - there is need to have abstract requirements and it's always good question, should we spotlight something specially or not (like it is also in this case)
• duplicate cheat sheet - guidance for developers is more cheat sheet project topic - ASVS can not educate developers

[tghosth]

Hi @ImanSharaf,

Thanks for the detailed arguments. I have tried to respond to each of them.

Firstly, my overall preference is that we should have a single requirement per separate protection mechanism which is needed. To me ASVS is most important as a standard for developers as otherwise we won't really have anything to verify :)

Email sending is fundamentally a business logic function. The threat of overuse of business logic functions such as creating new records, uploading files, etc, can lead to a variety of consequences. However, ultimately the protection/solution is an effective rate-limiting solution.

If we talk about SMTP/IMAP injection, that is not a business logic issue but rather a technical issue about how the app interacts with the protocol. As such, it would need a separate requirement to implement a specific solution against this type of threat.

However, a rate limiting solution should cover the threat of overuse of all business logic functions.

Regarding your specific points:

• Granularity Matters: While controls like 11.2.1 and 11.2.2 may capture the general idea of rate-limiting and anti-automation, email bomb attacks are a distinct threat with unique consequences, as you pointed out (e.g., email server blacklisting). Specific controls address distinct threats in a manner that's clear and actionable.

I agree in principle but like I said the granularity should generally be at the solution level, not necessarily the consequence/threat level.

• Consistency in the ASVS: The ASVS itself differentiates between various forms of injection attacks. If the ASVS already distinguishes between types of injection attacks, why should it not offer similar granularity for other threats? This would maintain the integrity and consistency of the ASVS.

Hopefully the explanation above makes my perspective on this clearer.

• Avoiding Ambiguity: While one can argue that 11.2.1 and 11.2.2 cover email bomb attacks in essence, leaving them as implied might lead to inconsistencies in interpretation. An auditor, developer, or tester could potentially overlook this risk if it's not explicitly stated.

I think that I would expect an auditor/tester to find and highlight these type of business logic issues. From a developer perspective, I am hoping that once 11.2.2 starts the conversation about rate-limiting, it will lead to a comprehensive solution.

• Guidance for Developers: Developers look at such standards to understand specific threats and their defenses. Generalized statements might not provide adequate guidance. Specific controls, like the one you're suggesting, can help developers implement precise defenses and not overlook a particular threat.

Same answer: From a developer perspective, I am hoping that once 11.2.2 starts the conversation about rate-limiting, it will lead to a comprehensive solution.

• Benchmarking & Reporting: From a reporting perspective, having a specific control about mail bomb attacks allows businesses to definitively state they have defenses against this specific threat. It can be more persuasive to stakeholders and clients compared to referencing a generalized control.

Again, I think the threat is not specific compared to other business logic replay issues. Also, the more requirements we have, the harder it gets to benchmark :)

• Future Evolution of the ASVS: As threats evolve, the ASVS should evolve to cover new and nuanced threats. If the ASVS moves towards only general controls, it may not remain the comprehensive and trusted standard it is today.

Again, I think the threat is not specific compared to other business logic replay issues.

• Principle of Least Surprise: Security professionals, when using a framework or standard, expect it to be thorough. Specific threats, especially widely recognized ones like mail bomb attacks, should ideally not be left out or left to interpretation.

Again, I think the threat is not specific compared to other business logic replay issues.

What is your opinion @tghosth ?

I think we can clarify 11.2.2 to make this line of thinking clearer and maybe even add some explanatory text to the 11.2 section to explain in more detail. But I don't think this warrants a new requirement.

[elarlang]

So, general agreement seems to be, that we don't need new separate requirement to cover it.

The question stays, do we need to mention or cover it in 12.2.2?

ping @Sjord @tghosth @ImanSharaf

[tghosth]

Ok so what do we think about the following? I have deliberately tried to retarget the text to be more specific.

#	Description	L1	L2	L3	CWE
11.2.2	[MODIFIED, MOVED FROM 11.1.4] Verify that the application has anti-automation controls to protect against excessive calls to application functionality which could result in mass data exfiltration, junk data creation, resource quota exhaustion, rate limit breaches, mail or SMS flooding, denial of service, overuse of an expensive resource, etc.	✓	✓	✓	770

[elarlang]

I'm ok with current one and ok with proposed one. For me the meaning is the same.

To list those examples is good and bad - good to give some ideas for those who need them; bad as it may kill ideas with only listed issues as it is general problem.

[tghosth]

To list those examples is good and bad - good to give some ideas for those who need them; bad as it may kill ideas with only listed issues as it is general problem.

I hear that but I think I would rather have the examples and let the "etc" do the extra work 🤣

@ImanSharaf do you have any further thoughts?

[ImanSharaf]

What do you think about this one? 11.2.2 [MODIFIED, MOVED FROM 11.1.4] Verify that the application has anti-automation controls to protect against excessive calls to application functionality which could result in mass data exfiltration, junk data creation, resource quota exhaustion, rate limit breaches, out-of-band communication flooding, denial of service, overuse of an expensive resource, etc. ✓ ✓ ✓ 770

[tghosth]

I'm good with that, @ImanSharaf do you want to open a PR?

[ImanSharaf]

Sure. I will do that.

[ImanSharaf]

Please check it here

[elarlang]

done via #1775