OWASP - User contributions [en]

ASVS V2 Authentication

2017-12-05T20:01:40Z

Mark Burnett: Made it a bit more human-readable

== V2: Authentication Verification Requirements ==

=== Control Objective ===

Authentication is the act of establishing, or confirming, something (or someone) as authentic, that is, that claims made by or about the thing are true. Ensure that a verified application satisfies the following high level requirements:

* Verifies the digital identity of the sender of a communication.
* Ensures that only those authorised are able to authenticate and credentials are transported in a secure manner.

=== Security Verification Requirements ===

{| class="wikitable"
! # !! Description !! L1 !! L2 !! L3 !! Since
|-
| 2.1 || Verify all pages and resources are protected by server-side authentication, except those specifically intended to be public. || ✓ || ✓ || ✓ || 3.1
|-
| 2.2 || Verify that the application does not automatically fill in credentials – either as hidden fields, URL arguments, Ajax requests, or in forms, as this implies plain text, reversible or de-cryptable password storage. Random time limited nonces are acceptable as stand ins, such as to protect change password forms or forgot password forms. || ✓ || ✓ || ✓ || 3.1
|-
| 2.6 || Verify all authentication controls fail securely to ensure attackers cannot log in. || ✓ || ✓ || ✓ || 1.0
|-
| 2.7 || Verify password entry fields allow, or encourage, the use of passphrases, and do not prevent long passphrases or highly complex passwords being entered. || ✓ || ✓ || ✓ || 3.0.1
|-
| 2.8 || Verify all identity functions (e.g. forgot password, change password, change email, manage 2FA token, etc.) have the security controls, as the primary authentication mechanism (e.g. login form). || ✓ || ✓ || ✓ || 2.0
|-
| 2.9 || Verify that the changing password functionality includes the old password, the new password, and a password confirmation. || ✓ || ✓ || ✓ || 1.0
|-
| 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 all application data is transmitted over an encrypted channel (e.g. TLS). || ✓ || ✓ || ✓ || 3.1
|-
| 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. A one time password reset link should be used instead. || ✓ || ✓ || ✓ || 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. The use of SMS has been deprecated by NIST and should not be used. || || ✓ || ✓ || 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 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 high value applications can be configured to disallow the use of a configurable number of previous passwords. || || ✓ || ✓ || 3.1
|-
| 2.26 || Verify that sensitive operations (e.g. change password, change email address, add new biller, etc.) require re-authentication (e.g. password or 2FA token). This is in addition to CSRF measures, not instead. || || ✓ || ✓ || 3.0.1
|-
| 2.27 || Verify that measures are in place to block the use of commonly chosen passwords and weak pass-phrases. || || ✓ || ✓ || 3.0
|-
| 2.28 || Verify that all authentication challenges, whether successful or failed, should respond in the same average response time. || || || ✓ || 3.0
|-
| 2.29 || Verify that secrets, API keys, and passwords are not included in the source code, or online source code repositories. || || ✓ || ✓ || 3.0
|-
| 2.31 || Verify that users can enrol and use TOTP verification, two-factor, biometric (Touch ID or similar), or equivalent multi-factor authentication mechanism that provides protection against single factor credential disclosure. || || ✓ || ✓ || 3.1
|-
| 2.32 || Verify that access to administrative interfaces are strictly controlled and not accessible to untrusted parties. || ✓ || ✓ || ✓ || 3.0
|-
| 2.33 || Verify that the application is compatible with browser based and third party password managers, unless prohibited by risk based policy. || ✓ || ✓ || ✓ || 3.1
|}

=== References ===

For more information, see also:

* [https://www.owasp.org/index.php/Testing_for_authentication OWASP Testing Guide 4.0: Testing for Authentication]
* [https://www.owasp.org/index.php/Password_Storage_Cheat_Sheet:Password storage cheat sheet]
* [https://www.owasp.org/index.php/Forgot_Password_Cheat_Sheet:Forgot password cheat sheet]
* [https://www.owasp.org/index.php/Choosing_and_Using_Security_Questions_Cheat_SheetChoosing and Using Security Questions at]

ASVS V1 Architecture

2017-12-05T19:50:14Z

Mark Burnett:

== V1: Architecture, Design and Threat Modeling Requirements ==

=== Control Objective ===

In a perfect world, security would be considered throughout all phases of development. In reality however, security is often only a consideration at a late stage in the SDLC. Besides the technical controls, the ASVS requires processes to be in place that ensure that the security has been explicitly addressed when planning the architecture of the application or API, and that the functional and security roles of all components are known. Since single page applications and act as clients to remote API or services, it must be ensured that appropriate security standards are also applied to those services - testing the app in isolation is not sufficient.

The category “V1” lists requirements pertaining to architecture and design of the app. As such, this is the only category that does not map to technical test cases in the OWASP Testing Guide. To cover topics such as threat modelling, secure SDLC, key management, users of the ASVS should consult the respective OWASP projects and/or other standards such as the ones linked below.

=== Security Verification Requirements ===
{| class="wikitable"
|-
! # !! Description !! L1 !! L2 !! L3 !! Since
|-
| 1.1 || All app components are identified and known to be needed. || ✓ || ✓ || ✓ || 1.0
|-
| 1.2 || Security controls are never enforced only on the client side, but on the respective remote endpoints. || || ✓ || ✓ || 1.0
|-
| 1.3 || A high-level architecture for the application and all connected remote services has been defined and security has been addressed in that architecture. || || ✓ || ✓ || 1.0
|-
| 1.4 || Data considered sensitive in the context of the application is clearly identified. || || || ✓ || 1.0
|-
| 1.5 || All app components are defined in terms of the business functions and/or security functions they provide. || || || ✓ || 1.0
|-
| 1.6 || A threat model for the application and the associated remote services has been produced that identifies potential threats and countermeasures. || || || ✓ || 1.0
|-
| 1.7 || All security controls have a centralized implementation. || || ✓ || ✓ || 3.0
|-
| 1.8 || Components are segregated from each other via a defined security control, such as network segmentation, firewall rules, or cloud based security groups. || || ✓ || ✓ || 3.0
|-
| 1.9 || A mechanism for enforcing updates of the application exists. || || ✓ || ✓ || 3.0
|-
| 1.10 || Security is addressed within all parts of the software development lifecycle. || || ✓ || ✓ || 3.0
|-
| 1.11 || all application components, libraries, modules, frameworks, platform, and operating systems are free from known vulnerabilities || || ✓ || ✓ || 3.0.1
|-
| 1.12 || There is an explicit policy for how cryptographic keys (if any) are managed, and the lifecycle of cryptographic keys is enforced. Ideally, follow a key management standard such as NIST SP 800-57. || || ✓ ||✓ || 3.1
|}

=== References ===

For more information, please see:
* [OWASP Threat Modeling Cheat Sheet](https://www.owasp.org/index.php/Application_Security_Architecture_Cheat_Sheet)
* [OWASP Attack Surface Analysis Cheat Sheet](https://www.owasp.org/index.php/Attack_Surface_Analysis_Cheat_Sheet)
* [OWASP Security Architecture Cheat Sheet](https://www.owasp.org/index.php/Application_Security_Architecture_Cheat_Sheet)
* [OWASP Thread modelling](https://www.owasp.org/index.php/Application_Threat_Modeling)
* [OWASP Secure SDLC Cheat Sheet](https://www.owasp.org/index.php/Secure_SDLC_Cheat_Sheet)
* [Microsoft SDL](https://www.microsoft.com/en-us/sdl/)
* [NIST SP 800-57](http://csrc.nist.gov/publications/nistpubs/800-57/sp800-57-Part1-revised2_Mar08-2007.pdf)

ASVS V1 Architecture

2017-12-05T19:49:17Z

Mark Burnett: Reformatted to be a bit more readable.

== V1: Architecture, Design and Threat Modeling Requirements ==

=== Control Objective ===

In a perfect world, security would be considered throughout all phases of development. In reality however, security is often only a consideration at a late stage in the SDLC. Besides the technical controls, the ASVS requires processes to be in place that ensure that the security has been explicitly addressed when planning the architecture of the application or API, and that the functional and security roles of all components are known. Since single page applications and act as clients to remote API or services, it must be ensured that appropriate security standards are also applied to those services - testing the app in isolation is not sufficient.

The category “V1” lists requirements pertaining to architecture and design of the app. As such, this is the only category that does not map to technical test cases in the OWASP Testing Guide. To cover topics such as threat modelling, secure SDLC, key management, users of the ASVS should consult the respective OWASP projects and/or other standards such as the ones linked below.

=== Security Verification Requirements ===
{| class="wikitable"
|-
! # !! Description !! L1 !! L2 !! L3 !! Since |
|-
| 1.1 || All app components are identified and known to be needed. || ✓ || ✓ || ✓ || 1.0
|-
| 1.2 || Security controls are never enforced only on the client side, but on the respective remote endpoints. || || ✓ || ✓ || 1.0
|-
| 1.3 || A high-level architecture for the application and all connected remote services has been defined and security has been addressed in that architecture. || || ✓ || ✓ || 1.0
|-
| 1.4 || Data considered sensitive in the context of the application is clearly identified. || || || ✓ || 1.0
|-
| 1.5 || All app components are defined in terms of the business functions and/or security functions they provide. || || || ✓ || 1.0
|-
| 1.6 || A threat model for the application and the associated remote services has been produced that identifies potential threats and countermeasures. || || || ✓ || 1.0
|-
| 1.7 || All security controls have a centralized implementation. || || ✓ || ✓ || 3.0
|-
| 1.8 || Components are segregated from each other via a defined security control, such as network segmentation, firewall rules, or cloud based security groups. || || ✓ || ✓ || 3.0
|-
| 1.9 || A mechanism for enforcing updates of the application exists. || || ✓ || ✓ || 3.0
|-
| 1.10 || Security is addressed within all parts of the software development lifecycle. || || ✓ || ✓ || 3.0
|-
| 1.11 || all application components, libraries, modules, frameworks, platform, and operating systems are free from known vulnerabilities || || ✓ || ✓ || 3.0.1
|-
| 1.12 || There is an explicit policy for how cryptographic keys (if any) are managed, and the lifecycle of cryptographic keys is enforced. Ideally, follow a key management standard such as NIST SP 800-57. || || ✓ ||✓ || 3.1
|}

=== References ===

For more information, please see:
* [OWASP Threat Modeling Cheat Sheet](https://www.owasp.org/index.php/Application_Security_Architecture_Cheat_Sheet)
* [OWASP Attack Surface Analysis Cheat Sheet](https://www.owasp.org/index.php/Attack_Surface_Analysis_Cheat_Sheet)
* [OWASP Security Architecture Cheat Sheet](https://www.owasp.org/index.php/Application_Security_Architecture_Cheat_Sheet)
* [OWASP Thread modelling](https://www.owasp.org/index.php/Application_Threat_Modeling)
* [OWASP Secure SDLC Cheat Sheet](https://www.owasp.org/index.php/Secure_SDLC_Cheat_Sheet)
* [Microsoft SDL](https://www.microsoft.com/en-us/sdl/)
* [NIST SP 800-57](http://csrc.nist.gov/publications/nistpubs/800-57/sp800-57-Part1-revised2_Mar08-2007.pdf)

Double Free

2014-06-25T00:16:12Z

Mark Burnett: Fixed incomplete sentence.

{{Template:Vulnerability}}
{{Template:Fortify}}

Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''

[[ASDR_TOC_Vulnerabilities|Vulnerabilities Table of Contents]]

==Description==

Double free errors occur when free() is called more than once with the same memory address as an argument.

Calling free() twice on the same value can lead to memory leak. When a program calls free() twice with the same argument, the program's memory management data structures become corrupted and could allow a malicious user to write values in arbitrary memory spaces. This corruption can cause the program to crash or, in some circumstances, alter the execution flow. By overwriting particular registers or memory spaces, an attacker can trick the program into executing code of his/her own choosing, often resulting in an interactive shell with elevated permissions.

When a buffer is free()'d, a linked list of free buffers is read to rearrange and combine the chunks of free memory (to be able to allocate larger buffers in the future). These chunks are laid out in a double linked list which points to previous and next chunks. Unlinking an unused buffer (which is what happens when free() is called) could allow an attacker to write arbitrary values in memory; essentially overwriting valuable registers, calling shellcode from it's own buffer.

==Risk Factors==

* Talk about the [[OWASP Risk Rating Methodology|factors]] that make this vulnerability likely or unlikely to actually happen
* Discuss the technical impact of a successful exploit of this vulnerability
* Consider the likely [business impacts] of a successful attack

==Examples==

The following code shows a simple example of a double free vulnerability.

<pre>
char* ptr = (char*)malloc (SIZE);
...
if (abrt) {
free(ptr);
}
...
free(ptr);
</pre>

Double free vulnerabilities have three common (and sometimes overlapping) causes:

* Error conditions and other exceptional circumstances
* Usage of the memory space after it's freed.
* Confusion over which part of the program is responsible for freeing the memory

Although some double free vulnerabilities are not much more complicated than the previous example, most are spread out across hundreds of lines of code or even different files. Programmers seem particularly susceptible to freeing global variables more than once.

==Related [[Attacks]]==

* [[Heap_overflow]]
* [[Buffer_overflow_attack]]

==Related [[Vulnerabilities]]==

* [[Vulnerability 1]]
* [[Vulnerabiltiy 2]]

==Related [[Controls]]==

* [[Control 1]]
* [[Control 2]]

==Related [[Technical Impacts]]==

* [[Technical Impact 1]]
* [[Technical Impact 2]]

==References==
TBD

[[Category:FIXME|add links

In addition, one should classify vulnerability based on the following subcategories: Ex:<nowiki>[[Category:Error Handling Vulnerability]]</nowiki>

Availability Vulnerability

Authorization Vulnerability

Authentication Vulnerability

Concurrency Vulnerability

Configuration Vulnerability

Cryptographic Vulnerability

Encoding Vulnerability

Error Handling Vulnerability

Input Validation Vulnerability

Logging and Auditing Vulnerability

Session Management Vulnerability]]

__NOTOC__

[[Category:OWASP ASDR Project]]
[[Category:Code Quality Vulnerability]]
[[Category:Implementation]]
[[Category:Code Snippet]]
[[Category:Vulnerability]]