Comments (11)
I wonder if all of these should be L2 because they are more like regulatory/legal risks and also like defense in depth rather than primary defense.
I think these sort of requirements which are common to data protection legislation, e.g. GDPR or CCPA are worth keeping but with that change in level.
I think we could separate chapter 8 into things which are actually security risks and things which are regulatory/legal risks but I don't think it is critical.
from asvs.
No clear proposals, just some thoughts for further discussion.
tldr: I think we should stay away from legal requirements.
8.3.2, 8.3.9
- V8.3.2 Verify that users have a method to remove their data on demand.
- V8.3.9 Verify that users have a method to export their data on demand.
Well, those functionalities are quite a juicy target for attackers. I can understand the abstract meaning and reasoning, but it opens up a new level of impact for attacks.
Maybe it's worth special mention for this in the 3.7.1?
# | Description | L1 | L2 | L3 | CWE | NIST § |
---|---|---|---|---|---|---|
3.7.1 | [MODIFIED] Verify that the application requires re-authentication or secondary verification before allowing highly sensitive transactions or modifications to account profile or authentication settings. | ✓ | ✓ | ✓ | 306 |
Are those requirements realistic - let's take some bank or gov system, you just can not ask it.
8.3.3
- V8.3.3 Verify that users are provided clear language regarding collection and use of supplied personal information and that users have provided opt-in consent for the use of that data before it is used in any way.
Is it actually 2 requirements?
Verify that users are provided clear language regarding collection
Is this part testable (what is a "clear language")? Is it a bit too much just a policy?
The abstract goal here can be, that the application must not collect (sensitive) data that it does not need, and it should be analyzed via:
- V1.8.1 Verify that all sensitive data created and processed by the application has been identified and classified into protection levels, and ensure that a policy is in place on how to deal with sensitive data.
- V1.8.2 Verify that all protection levels have an associated set of protection requirements and that these are applied in the architecture. This should include (but not be limited to) requirements related to encryption, integrity verification, retention, privacy and privacy-enhancing technologies to be used, and other confidentiality requirements.
Verify that users have provided opt-in consent for the use of that data before it is used in any way.
How we are going to test it? It is written somewhere in a big condition document and it's verified?
ping @tghosth
from asvs.
tldr: I think we should stay away from legal requirements.
I don't see a problem with some high-level requirements as long as they are implementable/testable.
Well, those functionalities are quite a juicy target for attackers. I can understand the abstract meaning and reasoning, but it opens up a new level of impact for attacks.
Maybe it's worth special mention for this in the 3.7.1?
I think it could already be considered to be covered in 3.7.1. We don't enumerate every possibility there.
Are those requirements realistic - let's take some bank or gov system, you just can not ask it.
Reauthentication? Definitely realistic. My bank makes me enter in an SMS code every time I want to do some sort of money transfer.
Is it actually 2 requirements?
I think it is one requirement because they are opting in to whatever is described in the wording it talks about.
Is this part testable (what is a "clear language")? Is it a bit too much just a policy?
I agree that is subjective and unhelpful and would recommend removing.
How we are going to test it? It is written somewhere in a big condition document and it's verified?
For testing opt in, you just have to make sure that users have to explicitly agree to it, should be pretty easy.
from asvs.
Reauthentication? Definitely realistic. My bank makes me enter in an SMS code every time I want to do some sort of money transfer.
No. The topic is:
- V8.3.2 Verify that users have a method to remove their data on demand.
- V8.3.9 Verify that users have a method to export their data on demand.
Is it always realistic to ask removing your data and export all your data. I don't think so.
If it is available as functionality, it is so critical piece, that it is worth special mentioning in 3.7.1.
from asvs.
Reauthentication? Definitely realistic. My bank makes me enter in an SMS code every time I want to do some sort of money transfer.
No. The topic is:
* V8.3.2 Verify that users have a method to remove their data on demand. * V8.3.9 Verify that users have a method to export their data on demand.
Is it always realistic to ask removing your data and export all your data. I don't think so.
If it is available as functionality, it is so critical piece, that it is worth special mentioning in 3.7.1.
Ah ok, I understand better what you mean now. I think that privacy legislation still applies to government bodies except in certain circumstances, for example:
It definitely applies for financial institutions.
As such I think it is almost always valid to expect that.
from asvs.
option 1 - cleanup
Back to the beginning:
Can we say for each requirement, what is the risk to solve?
If there is no clear answer, we should remove it.
Also, we have an agreement
- do not have requirements just because they belong to some policy
- to reduce the amount of requirements
I'm really not convinced we need those requirements in ASVS.
option 2 - update
If you are still sure you want to keep them:
- need for re-auth for data export is worth special mention in 3.7.1
- 8.3.3 needs improvement, remove the "clear language" part
- level 2 for 8.3.2
- I don't think CWE-212 is suitable for 8.3.2
- considerations to have separate policy-oriented requirements - but it is already against the logic to not have them at all
ping @tghosth
from asvs.
Following discussion with @elarlang, reduce to Level 3 since this is not a protective control as such but rather a risk reduction mechanism.
from asvs.
@set-reminder 10 mins josh to look at
from asvs.
⏰ Reminder
Wednesday, April 17, 2024 3:42 PM (GMT+02:00)
josh to look at
from asvs.
josh to look at
from asvs.
Opened #1931
Changes:
- I made them level 3
- I cleaned up 8.3.3
- I removed CWE 212
- I added some guidance to 3.7.1
from asvs.
Related Issues (20)
- Proposal: the application must belong/covered to the HSTS preload list (probably level 3) HOT 43
- Do we want V7.4 to get moved to V10? HOT 3
- Minor V7 changes HOT 2
- Italian Translation HOT 1
- V11 rework by @jmanico HOT 16
- update 50.2.1 (v4.0.3-14.4.3) and/or split requirement for content-security-policy HOT 13
- move or merge 8.3.5 to V7 HOT 3
- URL Safety HOT 23
- proposal/discussion: OAuth - disallow web application to be OAuth public client (and to have direct communication with OAuth token endpoint)
- proposal/discussion: OAuth - (for 1st party usage) only used (by the client) communication options must be allowed by authorization server HOT 3
- proposal/discussion: OAuth - separate requirement for redirect_uri string-match registration and handling HOT 6
- discussion: OAuth - using OAuth just for authentication HOT 4
- proposal/discussion: JWT - 3.5.6 add "type", and rephrase it to describe the goal HOT 6
- proposal/discussion: OAuth: requirement for refresh_token lifetime
- V51: Additional OAuth/OIDC proposals HOT 6
- discussion OAuth/OIDC: accepted flows and grants HOT 6
- 4.3.1 and 4.3.3 HOT 6
- Password Storage Algorithms 2.4.1 revisited HOT 3
- Make 2.1.14 easier and more simplified HOT 7
- Implement Requirement for Anomalous Behavior Detection HOT 4
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.