Josh Grossman
Josh Grossman
No I would be delighted for @sambhavnoobcoder to work on this :)
So I think the 6.1.x requirements are relatively specific. Even [3.7.1](https://github.com/OWASP/ASVS/blob/master/5.0/en/0x12-V3-Session-management.md#v37-defenses-against-session-management-exploits) ([permalink](https://github.com/OWASP/ASVS/blame/38dffdb896b25835120ceda9ade8cea14acbc69c/5.0/en/0x12-V3-Session-management.md#L94)) is relatively specific about when it is relevant. I understand why you want to add a requirement like...
Punting this to the business logic rework stage
I'm glad that this popped up now as this also got sort of discussed here: https://github.com/OWASP/ASVS/issues/1437#issuecomment-1910451384 I know we talk about business logic vulnerabilities but my current thinking is that...
> I agree with the language introduced by [#1437 (comment)](https://github.com/OWASP/ASVS/issues/1437#issuecomment-1910451384), as it clearly specifies that this only applies where the functionality is supported. Ok so that language got integrated. >...
I think this becomes a little too prescriptive and specific as I have said above. @EnigmaRosa previously suggested: > Verify that, if the application supports functionality that has been determined...
Thanks for the responses @EnigmaRosa :) > I believe that the extra controls and what necessitates them would be included in the application documentation (perhaps within nonfunctional security requirements, for...
> For sensitive functionality, we have 4.3.3, see https://github.com/OWASP/ASVS/issues/1576#issuecomment-2097681392. It can be fine-tuned if needed, or what is the not-covered aspect at the moment? We deliberately made that requirement focus...
Agree that there are a lot of tricky points in this section, I think we need to discuss what stays if anything from this section
> Verify that the application is able to discern and utilizes the user's true IP address to provide data integrity and that rate limiting and logging use this true IP....