professional, technology, utilities, and defense These industries may not appear to have very much in common, but the threat actors who are likely to attack organizations in this segment are more likely to perform focused attacks with more time, skill, and resources. Often the sensitive information or systems are not easy to locate and require leveraging insiders and social engineering techniques. Attacks may involve insiders, outsiders, or be collusion between the two. Their goals may include gaining access to intellectual property for strategic or technological advantage. We also do not want to overlook attackers looking to abuse application functionality influence the behaviour of or disrupt sensitive systems. Most attackers are looking for sensitive data that can be used to directly or indirectly profit from to include personally identifiable information and payment data. Often the data can be used for identity theft, fraudulent payments, or a variety of fraud schemes. All network accessible applications. Applications containing internal information or information about employees that may be leveraged in social engineering. Applications containing nonessential, but important intellectual property or trade secrets. Applications containing valuable intellectual property, trade secrets, or government secrets (e.g. in the United States this may be anything classified at Secret or above) that is critical to the survival or success of the organization. Applications controlling sensitive functionality (e.g. transit, manufacturing equipment, control systems) or that have the possibility of threatening safety of lif Healthcare Most attackers are looking for sensitive data that can be used to directly or indirectly profit from to include personally identifiable information and payment data. Often the data can be used for identity theft, fraudulent payments, or a variety of fraud schemes. For the US healthcare sector, the Health Insurance Portability and Accountability Act (HIPAA) Privacy, Security, Breach Notification Rules and Patient Safety Rule (= All network accessible applications Applications with small or moderate amounts of sensitive medical information (Protected Health Information), Personally Identifiable Information, or payment data. Applications used to control medical equipment, devices, or records that may endanger human life. Payment and Point of Sale systems (POS) that contain large amounts of transaction data that could be used to commit fraud. This includes any administrative interfaces for these applications
Retail, food, hospitality Many of the attackers in this segment utilize opportunistic "smash and grab" tactics. However, there is also a regular threat of specific attacks on applications known to contain payment information, perform financial transactions, or store personally identifiable information. Although less likely than the threats mentioned above, there is also the possibility of more advanced threats attacking this industry segment to steal intellectual property, gain competitive intelligence, or gain an advantage with the target organization or a business partner in negotiations. All network accessible applications. Suitable for business applications, product catalogue information, internal corporate information, and applications with limited user information (e.g. contact information). Applications with small or moderate amounts of payment data or checkout functionality. Payment and Point of Sale systems (POS) that contain large amounts of transaction data that could be used to commit fraud. This includes any administrative interfaces for these applications. Applications with a large volume of sensitive information like full credit card numbers, mother's maiden name, social security numbers etc.
2.12 Verify that all authentication decisions can be logged, without storing sensitive session identifiers or passwords. This should include requests with relevant metadata needed for security investigations. 3.0.1 2.13 Verify that account passwords are one way hashed with a salt, and there is sufficient work factor to defeat brute force and password hash recovery attacks. 3.0.1 2.16 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. 3.0 2.17 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. 2.0 2.18 Verify that information enumeration is not possible via login, password reset, or forgot account functionality. 2.0 2.19 Verify there are no default passwords in use for the application framework or any components used by the application (such as “admin/password”). 2.0 2.20 Verify that anti-automation is in place to prevent breached credential testing, brute forcing, and account lockout attacks. 3.0.1 2.21 Verify that all authentication credentials for accessing services external to the application are encrypted and stored in a protected location. 2.0 2.22 Verify that forgotten password and other recovery paths use a TOTP or other soft token, mobile push, or other offline recovery mechanism. Use of a random value in an e-mail or SMS should be a last resort and is known weak. 3.0.1 2.23 Verify that account lockout is 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. 3.0 2.24 Verify that if shared knowledge based questions (also known as "secret questions") are required, the questions do not violate privacy laws and are sufficiently strong to protect accounts from malicious recovery. 3.0.1 2.25 Verify that the system can be configured to disallow the use of a configurable number of previous passwords. 2.0
3.13 Verify that all code implementing or using session management controls is not affected by any malicious code Moved 2.0 Moved to V13 - Malicious code 3.14 Verify that authenticated session tokens using cookies are protected by the use of "HttpOnly". Updated 3.0 Moved into 3.13 3.15 Verify that authenticated session tokens using cookies are protected with the "secure" attribute. Updated 3.0 into 3.13 4.2 Verify that users can only access secured URLs for which they possess specific authorization. Updated 3.0 Rolled into 4.1 4.3 Verify that users can only access secured data files for which they possess specific authorization. Updated 3.0 Rolled into 4.1 4.13 Verify that limitations on input and access imposed by the business on the application (such as daily transaction limits or sequencing of tasks) cannot be bypassed. Moved 3.0 Moved to V15 Business Logic 4.15 Verify that all code implementing or using access controls is not affected by any malicious code. Moved 2.0 Moved to V13 Malicious Controls 5.2 Verify that a positive validation pattern is defined and applied to all input Deprecated 2.0 Removed as too difficult to implement particularly for free form text inputs 5.4 Verify that a character set, such as UTF-8, is specified for all sources of input Deprecated 3.0 Removed as too difficult to implement in most languages 5.7 Verify that all input validation failures are logged. Deprecated 3.0 Removed as would create too many useless logs that would be ignored 5.8 Verify that all input data is canonicalized for all downstream decoders or interpreters prior to validation. Deprecated 3.0 Removed as Type 1 JSP technology specific and not
17.1 Verify that the client validates SSL certificates Deprecated 3.0 Duplicated requirement. General requirement already captured by V10. 17.7 Deprecated 17.8 Deprecated 17.10 Deprecated 17.11 Deprecated 17.12 Deprecated 17.13 Deprecated 17.14 Deprecated 17.15 Deprecated 17.16 Deprecated 17.17 Deprecated 17.18 Deprecated 17.19 Deprecated 17.20 Deprecated 17.22 Deprecated 17.23 Deprecated 17.24 Deprecated
6.5.9 Cross-site request forgery (CSRF). 4.13 Exact mapping. ASVS considers CSRF defense to be an aspect of access control. 6.5.10 Broken authentication and session management. v2 and v3 - all Comprehensive mapping from 1 up