Important points for Product Development
1. Verify all pages and resources by default require authentication except those specifically intended to be public (Principle of complete mediation).
2. Verify that all password fields do not echo the user’s password when it is entered.
3. Verify all authentication controls are enforced on the server side.
4. Verify all authentication controls fail securely to ensure attackers cannot log in.
5. Verify password entry fields allow, or encourage, the use of passphrases, and do not prevent long passphrases/highly complex passwords being entered.
6. Verify all account identity authentication functions (such as update profile, forgot the password, disabled/lost token, help desk or IVR) that might regain access to the account are at least as resistant to attack as the primary authentication mechanism.
7. Verify that the changing password functionality includes the old password, the new password, and a password confirmation.
8. Verify that all suspicious authentication decisions are logged. This should include requests with relevant metadata needed for security investigations.
9. Verify that account passwords make use of a sufficient strength encryption routine and that it withstands brute force attack against the encryption routine.
10. Verify that credentials are transported using a suitable encrypted link and that all pages/functions that require a user to enter credentials are done so using an encrypted link.
11. Verify that the forgotten password function and other recovery paths do not reveal the current password and that the new password is not sent in clear text to the user.
12. Verify that information enumeration is not possible via login, password reset, or forgot account functionality.
13. Verify there are no default passwords in use for the application framework or any components used by the application (such as “admin/password”).
14. Verify that request throttling is in place to prevent automated attacks against common authentication attacks such as brute force attacks or denial of service attacks.
15. Verify that all authentication credentials for accessing services external to the application are encrypted and stored in a protected location.
16. Verify that forgotten password and other recovery paths use a soft token, mobile push, or an offline recovery mechanism.
17. Verify that account lockout divided into soft and hard lock status, and these are not mutually exclusive. If an account is temporarily soft locked out due to a brute force attack, this should not reset the hard lock status.
18. Verify that if knowledge-based questions (also known as “secret questions”) are required, the questions should be strong enough to protect the application.
19. Verify that the system can be configured to disallow the use of a configurable number of previous passwords.
20. Verify re-authentication, step up or adaptive authentication, two-factor authentication, or transaction signing is required before any application-specific sensitive operations are permitted as per the risk profile of the application.
21. Verify that measures are in place to block the use of commonly chosen passwords and weak passphrases.
22. Verify that all authentication challenges, whether successful or failed, should respond in the same average response time.
23. Verify that secrets, API keys, and passwords are not included in the source code, or online source code repositories.
24. Verify that if an application allows users to authenticate, they use a proven secure authentication mechanism.
25. Verify that if an application allows users to authenticate, they can authenticate using two-factor authentication or other strong authentication, or any similar scheme that provides protection against username + password disclosure.
26. Verify that administrative interfaces are not accessible to untrusted parties
27. Verify that sessions are invalidated when the user logs out.
28. Verify that sessions timeout after a specified period of inactivity.
29. Verify that sessions timeout after an administratively-configurable maximum time period regardless of activity (an absolute timeout).
30. Verify that all pages that require authentication have easy and visible access to logout functionality.
31. Verify that the session id is never disclosed in URLs, error messages, or logs. This includes verifying that the application does not support URL rewriting of session cookies.
32. Verify that all successful authentication and re-authentication generates a new session and session id.
33. Verify that only session id is generated by the application framework are recognized as active by the application.
34. Verify that session ids are sufficiently long, random and unique across the correct active session base.
35. Verify that session id stored in cookies have their path set to an appropriately restrictive value for the application, and authentication session tokens additionally set the “HttpOnly” and “secure” attributes.
36. Verify that the application limits the number of active concurrent sessions.
37. Verify that an active session list is displayed in the account profile or similar of each user. The user should be able to terminate any active session.
38. Verify the user is prompted with the option to terminate all other active sessions after a successful change password process.
39. Verify that the principle of least privilege exists — the user 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.
40. Verify that access to sensitive records is protected, such that only authorized objects or data is accessible to each user (for example, protect against users tampering with a parameter to see or alter another user’s account).
41. 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.
42. Verify that access controls fail securely.
43. Verify that the same access control rules implied by the presentation layer are enforced on the server side.
44. Verify that all user and data attributes and policy information used by access controls cannot be manipulated by end users unless specifically authorized.
45. Verify that there is a centralized mechanism (including libraries that call external authorization services) for protecting access to each type of protected resource.
46. Verify that all access control decisions can be logged and all failed decisions are logged.
47. Verify that the application or framework uses strong random anti-CSRF tokens or has another transaction protection mechanism.
48. Verify the system can protect against aggregate or continuous access of secured functions, resources, or data. For example, consider the use of a resource governor to limit the number of edits per hour or to prevent the entire database from being scraped by an individual user.
49. 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.
50. Verify that the application correctly enforces context-sensitive authorization so as to not allow unauthorized manipulation by means of parameter tampering.
51. Verify that the runtime environment is not susceptible to buffer overflows, or that security controls prevent buffer overflows.
52. Verify that server-side input validation failures result in request rejection and are logged.
53. Verify that the input validation routine is enforced on the server side.
54. Verify that a single input validation control is used by the application for each type of data that is accepted.
55. Verify that all SQL queries, HQL, OSQL, NOSQL and stored procedures, calling of stored procedures are protected by the use of prepared statements or query parameterization, and thus not susceptible to SQL injection.
56. Verify that the application is not susceptible to LDAP Injection, or that security controls prevent LDAP Injection.
57. Verify that the application is not susceptible to OS Command Injection, or that security controls prevent OS Command Injection.
58. Verify that the application is not susceptible to Remote File Inclusion (RFI) or Local File Inclusion (LFI) when content is used that is a path to a file.
59. Verify that the application is not susceptible to common XML attacks, such as XPath query tampering, XML External Entity attacks, and XML injection attacks.
60. If the application framework allows automatic mass parameter assignment (also called automatic variable binding) from the inbound request to a model, verify that security-sensitive fields such as “account balance”, “role” or “password” are protected from malicious automatic binding.
61. Verify that the application has defenses against HTTP parameter pollution attacks, particularly if the application framework makes no distinction about the source of request parameters (GET, POST, cookies, headers, environment, etc.)
62. Verify that client-side validation is used as a second line of defense, in addition to server-side validation.
63. Verify that all input data is validated, not only HTML form fields but all sources of input such as REST calls, query parameters, HTTP headers, cookies, batch files, RSS feeds, etc; using positive validation (whitelisting),then lesser forms of validation such as greylisting (eliminating known bad strings), or rejecting bad inputs (blacklisting).
64. Verify that data transferred from one DOM context to another, use safe JavaScript methods, such as using .innerText and .val.
65. Verify when parsing JSON in browsers, that JSON.parse is used to parse JSONon the client. Do not use eval() to parse JSON on the client.
66. Verify that authenticated data is cleared from client storage, such as the browser DOM after the session is terminated.
67. Verify that all cryptographic modules fail securely, and errors are handled in a way that does not enable oracle padding.
68. Verify that cryptographic modules operate in their approved mode according to their published security policies.
69. Verify that where possible, keys and secrets are zeroed when destroyed.
70. Verify that all keys and passwords are replaceable, and are generated or replaced at installation time.
71. Verify that the application does not output error messages or stack traces containing sensitive data that could assist an attacker, including session id, software/framework versions, and personal information.
72. Verify that error handling logic in security controls denies access by default.
73. Verify security logging controls provide the ability to log success and particularly failure events that are identified as security-relevant.
74. Verify that each log event includes necessary information that would allow for a detailed investigation of the timeline when an event happens.
75. Verify that the application does not log sensitive data as defined under local privacy laws or regulations, organizational sensitive data as defined by a risk assessment, or sensitive authentication data that could assist an attacker, including user’s session identifiers, passwords, hashes, or API tokens.
76. Verify that all non-printable symbols and field separators are properly encoded in log entries, to prevent log injection.
77. Verify that log fields from trusted and untrusted sources are distinguishable in log entries.
78. Verify that security logs have some form of integrity checking or control to prevent unauthorized modification.
79. Verify that the logs are stored on a different partition than the application is running with proper log rotation.
80. Verify that all forms containing sensitive information have disabled client-side caching, including autocomplete features.
81. Verify that the list of sensitive data processed by the application is identified and that there is an explicit policy for how access to this data must be controlled, encrypted and enforced under relevant data protection directives.
82. Verify that all sensitive data is sent to the server in the HTTP message body or headers (i.e., URL parameters are never used to send sensitive data).
83. Verify that there is a method to remove each type of sensitive data from the application at the end of the required retention policy.
84. Verify the application minimizes the number of parameters in a request, such as hidden fields, Ajax variables, cookies and header values.
85. Verify the application has the ability to detect and alert on abnormal numbers of requests for data harvesting for an example screen scraping.
86. Verify that data stored in client-side storage — such as HTML5 local storage, session storage, IndexedDB, regular cookies or Flash cookies — does not contain sensitive or PII).
87. Verify accessing sensitive data is logged, if the data is collected under relevant data protection directives or where logging of accesses is required.
88. Verify that sensitive data is rapidly sanitized from memory as soon as itis no longer needed and handled in accordance to functions and techniques supported by the framework/library/operating system.
89. Verify that certificate paths are built and verified for all client certificates using configured trust anchors and revocation information.
90. Verify that production website URL has been submitted to a preloaded list of Strict Transport Security domains maintained by web browser vendors. Please see the references below.
91. Verify that only strong algorithms, ciphers, and protocols are used, through all the certificate hierarchy, including root and intermediary certificates of your selected certifying authority.
92. Verify that the application accepts only a defined set of required HTTP request methods, such asGET and POST are accepted, and unused methods(e.g. TRACE, PUT, and DELETE) are explicitly blocked.
93. Verify that the HTTP headers or any part of the HTTP response do not expose detailed version information of system components.
94. Verify all malicious activity is adequately sandboxed, containerized or isolated to delay and deter attackers from attacking other applications.
95. Verify that a code review looks for malicious code, back doors, Easter eggs, and logic flaws.
96. Verify the application will only process business logic flows in sequential step order, with all steps being processed in realistic human time, and not process out of order, skipped steps, process steps from another user, or too quickly submitted transactions.
97. Verify the application has business limits and correctly enforces on a per-user basis, with configurable alerting and automated reactions to automated or unusual attack.
98. Verify that URL redirects and forwards only allow whitelisted destinations, or show a warning when redirecting to potentially untrusted content.
99. Verify the application code does not execute uploaded data obtained from untrusted sources.
100. Do not use Flash, Active-X, Silverlight, NACL, client-side Java or other client-side technologies not supported natively via W3C browser standards.
101. Verify that untrusted data is not used within inclusion, class loader, or reflection capabilities to prevent remote/local file inclusion vulnerabilities.
Published on Linkedin Earlier