Issues
- 0
4.3.3 Verify the application has additional authorization (such as step up or adaptive authentication) for lower value systems, and / or segregation of duties for high value applications to enforce anti-fraud controls as per the risk of application and past fraud.
#134 opened by kyrcha - 0
4.3.2 Verify that directory browsing is disabled unless deliberately desired. Additionally, applications should not allow discovery or disclosure of file or directory metadata, such as Thumbs.db, .DS_Store, .git or .svn folders.
#133 opened by kyrcha - 0
4.3.1 Verify administrative interfaces use appropriate multi-factor authentication to prevent unauthorized use.
#132 opened by kyrcha - 0
4.2.2 Verify that the application or framework enforces a strong anti-CSRF mechanism to protect authenticated functionality, and effective anti-automation or anti-CSRF protects unauthenticated functionality.
#131 opened by kyrcha - 0
4.2.1 Verify that sensitive data and APIs are protected against direct object attacks targeting creation, reading, updating and deletion of records, such as creating or updating someone else's record, viewing everyone's records, or deleting all records.
#130 opened by kyrcha - 0
4.1.5 Verify that access controls fail securely including when an exception occurs.
#129 opened by kyrcha - 0
4.1.4 Verify that the principle of deny by default exists whereby new users/roles start with minimal or no permissions and users/roles do not receive access to new features until access is explicitly assigned.
#128 opened by kyrcha - 0
4.1.3 Verify that the principle of least privilege exists - users should only be able to access functions, data files, URLs, controllers, services, and other resources, for which they possess specific authorization. This implies protection against spoofing and elevation of privilege.
#127 opened by kyrcha - 0
4.1.2 Verify that all user and data attributes and policy information used by access controls cannot be manipulated by end users unless specifically authorized.
#126 opened by kyrcha - 0
4.1.1 Verify that the application enforces access control rules on a trusted service layer, especially if client-side access control is present and could be bypassed.
#125 opened by kyrcha - 0
3.7.1 Verify the application ensures a valid login session or requires re-authentication or secondary verification before allowing any sensitive transactions or account modifications.
#124 opened by kyrcha - 0
3.6.2 Verify that CSPs inform relying parties of the last authentication event, to allow RPs to determine if they need to re-authenticate the user.
#123 opened by kyrcha - 0
3.6.1 Verify that relying parties specify the maximum authentication time to CSPs and that CSPs re-authenticate the subscriber if they haven't used a session within that period.
#122 opened by kyrcha - 0
3.5.3 Verify that stateless session tokens use digital signatures, encryption, and other countermeasures to protect against tampering, enveloping, replay, null cipher, and key substitution attacks.
#121 opened by kyrcha - 0
3.5.2 Verify the application uses session tokens rather than static API secrets and keys, except with legacy implementations.
#120 opened by kyrcha - 0
3.5.1 Verify the application does not treat OAuth and refresh tokens — on their own — as the presence of the subscriber and allows users to terminate trust relationships with linked applications.
#119 opened by kyrcha - 0
3.4.5 Verify that if the application is published under a domain name with other applications that set or use session cookies that might override or disclose the session cookies, set the path attribute in cookie-based session tokens using the most precise path possible.
#118 opened by kyrcha - 0
3.4.4 Verify that cookie-based session tokens use "__Host-" prefix (see references) to provide session cookie confidentiality.
#117 opened by kyrcha - 0
3.4.3 Verify that cookie-based session tokens utilize the 'SameSite' attribute to limit exposure to cross-site request forgery attacks.
#116 opened by kyrcha - 0
3.4.2 Verify that cookie-based session tokens have the 'HttpOnly' attribute set.
#115 opened by kyrcha - 0
- 0
3.3.4 Verify that users are able to view and log out of any or all currently active sessions and devices.
#113 opened by kyrcha - 0
3.3.3 Verify that the application terminates all other active sessions after a successful password change, and that this is effective across the application, federated login (if present), and any relying parties.
#112 opened by kyrcha - 0
3.3.2 If authenticators permit users to remain logged in, verify that re-authentication occurs periodically both when actively used or after an idle period.
#111 opened by kyrcha - 0
3.3.1 Verify that logout and expiration invalidate the session token, such that the back button or a downstream relying party does not resume an authenticated session, including across relying parties.
#110 opened by kyrcha - 0
3.2.4 Verify that session token are generated using approved cryptographic algorithms
#109 opened by kyrcha - 0
3.2.3 Verify the application only stores session tokens in the browser using secure methods such as appropriately secured cookies (see section 3.4) or HTML 5 session storage.
#108 opened by kyrcha - 0
- 0
3.2.1 Verify the application generates a new session token on user authentication.
#106 opened by kyrcha - 0
3.1.1 Verify the application never reveals session tokens in URL parameters or error messages.
#105 opened by kyrcha - 0
2.10.4 Verify passwords, integrations with databases and third-party systems, seeds and internal secrets, and API keys are managed securely and not included in the source code or stored within source code repositories.
#104 opened by kyrcha - 0
2.10.3 Verify that passwords are stored with sufficient protection to prevent offline recovery attacks, including local system access.
#103 opened by kyrcha - 0
2.10.2 Verify that if passwords are required, the credentials are not a default account.
#102 opened by kyrcha - 0
2.10.1 Verify that integration secrets do not rely on unchanging passwords, such as API keys or shared privileged accounts.
#101 opened by kyrcha - 0
2.9.3 Verify that approved cryptographic algorithms are used in the generation, seeding, and verification.
#100 opened by kyrcha - 0
2.9.2 Verify that the challenge nonce is at least 64 bits in length, and statistically unique or unique over the lifetime of the cryptographic device.
#99 opened by kyrcha - 0
2.9.1 Verify that cryptographic keys used in verification are stored securely and protected against disclosure, such as using a TPM or HSM, or an OS service that can use this secure storage.
#98 opened by kyrcha - 0
2.8.7 Verify that biometric authenticators are limited to use only as secondary factors in conjunction with either something you have and something you know.
#97 opened by kyrcha - 0
2.8.6 Verify physical single factor OTP generator can be revoked in case of theft or other loss
#96 opened by kyrcha - 0
2.8.5 Verify that if a time-based multi factor OTP token is re-used during the validity period, it is logged and rejected with secure notifications being sent to the holder of the device.
#95 opened by kyrcha - 0
2.8.4 Verify that time-based OTP can be used only once within the validity period.
#94 opened by kyrcha - 0
2.8.3 Verify that approved cryptographic algorithms are used in the generation, seeding, and verification.
#93 opened by kyrcha - 0
2.8.2 Verify that symmetric keys used to verify submitted OTPs are highly protected, such as by using a hardware security module or secure operating system based key storage.
#92 opened by kyrcha - 0
- 0
2.7.6 Verify that the initial authentication code is generated by a secure random number generator, containing at least 20 bits of entropy (typically a six digital random number is sufficient).
#90 opened by kyrcha - 0
2.7.5 Verify that the out of band verifier retains only a hashed version of the authentication code.
#89 opened by kyrcha - 0
2.7.4 Verify that the out of band authenticator and verifier communicates over a secure independent channel.
#88 opened by kyrcha - 0
2.7.3 Verify that the out of band verifier authentication requests, codes, or tokens are only usable once, and only for the original authentication request.
#87 opened by kyrcha - 0
2.7.2 Verify that the out of band verifier expires out of band authentication requests, codes, or tokens after 10 minutes.
#86 opened by kyrcha - 0
2.7.1 Verify that clear text out of band (NIST "restricted") authenticators, such as SMS or PSTN, are not offered by default, and stronger alternatives such as push notifications are offered first.
#85 opened by kyrcha