-
-
Notifications
You must be signed in to change notification settings - Fork 667
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
1.3.1 - Session Controls Documentation #2076
Comments
Session decisions to document:
Is SSO has separate session from the application (like it usually is), then it all applies (separately) to SSO as well. |
@ryarmst - let's try to get your proposed requirement in. I thik it needs some surrounding text to the chapter as well, maybe @tghosth can help with that. I prefer "absolute maximum session lifetime" (that we use in 3.3.2) over "overall timeout" from NIST. Requirement should be level 1, as we have implementation requirements that needs this documented info with level 1 (3.3.2, 3.3.5). |
I think it may introduce the least friction by providing considerations for design/documentation in the section text rather than too many additional requirements. I have written a rather verbose proposal for section text below. I think it can be trimmed down. I have written up "considerations" that could be turned into requirements. I also included terminology because I think there has been some ongoing confusion, but it may be more appropriate in the appendix. Some comments are in square brackets. Proposed Section TextSession management mechanisms provide applications the capability to correlate user and device interactions over time even using otherwise stateless communication protocols. While applications traditionally utilized session handling capabilities built in to browsers, such as HTTP Cookies or even HTTP Basic Authentication, applications today utilize a variety of techniques and technologies to implement the session management lifecycle (creation, transmission, storage, and termination). [This paragraph is fairly introductory and could be cut]. Modern applications may utilize multiple session identifiers or tokens with distinct characteristics and purpose. There is no single pattern that suits all applications. As such, session management systems must be designed with consideration for the relevant strengths and weaknesses in conjunction with the expected use cases of the application and intended level of security assurance. A secure session management system is one that optimally prevents attackers from obtaining, utilizing, or otherwise abusing a victim's session. The most devastating of such attacks is known as session hijacking or takeover attacks. The following terminology is used within the ASVS:
Security controls should mitigate the likelihood and potential impact of successful attacks against user sessions. Consider starting with the following questions surrounding session management:
Considering the above, evaluate the controls appropriate for your application, including:
|
When I asked chapter texts, I had in mind "few lines" :) First - I think it makes sense to handle requirement and chapter text in a separate issues.
Personally, I prefer, that all "considerations" (or required decisions to be able to implement and later test) for session management are written as separate documentation requirements, as was proposed in 1.3.1.
With terminology we need to check, what should belong to the chapter text and what to the glossary so that we don't duplicate them. We can move things here and there, but it is a great input to work with. |
Great content @ryarmst :)
I agree with this, I think it would be good if you can combine the considerations into a few documentation requirements.
I also agree with this, it may be better to reference the glossary and then put the definitions there. @elarlang would it make sense for @ryarmst to take those actions and prepare an initial PR that implements them? |
In general, it makes sense, but I think a slightly shorter feedback loop can be helpful e. g. do not waste time and effort on something that is not aligned with our vision of how things in ASVS should be. Maybe just quick validation in chat or here before putting the effort in. |
Agreed, I will get the details right before a PR. I will open a new issue for a trimmed section text proposal. @elarlang In terms of additional documentation requirements for V1.3, do you think the following are reasonable to build into requirements?
For each, I will open a new issue to propose requirements as appropriate. |
Yes, at the moment I think so. As the result is up to the discussion for each one of them, we will find out :) |
New issues for items above:
|
Ok, let's get back to this issue focus and try to move on with 1.3.1 here. Input/update for further finetuning
Need to think more about the last sentence - it is not only session hijacking, or even more general session takeover including session fixation vectors, it's in general against attacks if pre-condition is user's active session, e.g. csrf, clickjacking, xss etc. |
Looks good to me! |
@ryarmst - would you like to open the PR yourself? |
waiting for #2113 |
ping, can we get this one moving? The vision here was to provide flexibility to decide own timeout values, but if those are different from NIST provided recommendation, the reasoning must be documented. |
So I think there are two approaches to consider:
For (1) above, consider:
For (2), I think it would be best to split into two separate requirements (for absolute and inactivity). Here is an example for inactivity timeouts:
Thoughts? |
I'm not happy with the requirement, I have started to build a proposal for improvement 10 times and never reached any result... So the quick takeaway here is, let's get version 1 into the document and if someone has a proposal for improvement, we can always do that. |
@ryarmst - do you want me to handle the PR or you'll do it yourself? |
Adding the first documentation requirements for session management.
Opened #2154 to resolve |
Branching from #1557
V1.3 Session Management Architecture is currently a placeholder. The latest draft of NIST 800-63B Revision 4 includes:
I suggest the addition of the following requirement that also captures considerations for additional controls against session hijacking/theft:
After reviewing other discussions surrounding similar controls, I think keeping the requirement vague (non-prescriptive) with respect to "other controls" may be the most practical approach. Consider, for example, discussions on client session storage spanning multiple issues (example: see #2010).
The text was updated successfully, but these errors were encountered: