Comments (15)
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.
from asvs.
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
from asvs.
I'm good with that, @ImanSharaf do you want to open a PR?
from asvs.
Sure. I will do that.
from asvs.
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.
from asvs.
@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?
from asvs.
-
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 ?
from asvs.
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
from asvs.
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.
from asvs.
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
from asvs.
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 |
from asvs.
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.
from asvs.
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?
from asvs.
Please check it here
from asvs.
done via #1775
from asvs.
Related Issues (20)
- Requesting Clarifying Definition in the Business Logic Section Header HOT 3
- Something amiss in requirement description for v5.0-50.5.3 HOT 4
- lowercase vs uppercase grammar (original: 6.2.1 causes capitalization inconsistency) HOT 13
- 5.1.1 - terminology, GET and POST... HOT 14
- clarifying 5.1.3 HOT 9
- Should easily visible logout functionality be a requirement or a recomendation HOT 15
- Tracking supporters HOT 6
- V9 rework - 9.2.5 has insufficient value HOT 5
- 2.10.5 (v4.0.3-9.2.3) - belongs in authentication (needs improvement and scope check) HOT 15
- 7.2.3 (v4.0.3-7.1.3) - wording improvement HOT 4
- 7.2.4 (v4.0.3-9.2.5) - improve the wording to cover all connection errors and failed certificate checks HOT 10
- move section V5.5 (and V5.4) to V10 HOT 18
- Ismael HOT 1
- Finalize web socket requirements HOT 12
- Proposal to remove serverless references HOT 6
- oauth related discussions HOT 3
- cleanup V3.5 Token-based Session Management HOT 3
- V8.3 security and policy HOT 11
- encoded sensitive data (such as JWT) should not be logged HOT 5
- proposal: move 1.14.6 to V50 (Web Frontend Security) HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from asvs.