Merge branch 'release/0.1.2'

Author: PauloASilva

2019/en/dist/owasp-api-security-top-10.odt

@@ -42,6 +42,12 @@ the site.
 * Never rely on the client side to perform sensitive data filtering.
 * Review the responses from the API to make sure they contain only legitimate
   data.
+* Explicitly define and enforce data returned by all API methods, including
+  errors. Whenever possible: use schemas for responses, patterns for all strings
+  and clear field names.
+* Define all sensitive and personally identifiable information (PII) that your
+  application stores and works with and review all API calls returning such
+  information to see if these responses can be a security issue.
 
 ## References
 

2019/en/dist/owasp-api-security-top-10.pdf

@@ -49,11 +49,19 @@ errors.
   [file descriptors, and processes][4].
 * Implement a limit on how often a client can call the API within a defined
   timeframe.
+* For sensitive operations such as login or password reset, consider rate limits
+  by API method (e.g., authentication), client (e.g., IP address), property
+  (e.g., username).
 * Notify the client when the limit is exceeded by providing the limit number and
   the time at which the limit will be reset.
 * Add proper server-side validation for query string and request body
   parameters, specifically the one that controls the number of records to be
   returned in the response.
+* Define and enforce maximum size of data on all incoming parameters and
+  payloads such as maximum length for strings and maximum number of elements in
+  arrays.
+* If your API accepts compressed files check compression ratios before expanding
+  the files to protect yourself against "zip bombs".
 
 ## References
 

2019/en/src/0xa3-excessive-data-exposure.md

@@ -4,7 +4,7 @@ A5:2019 Broken Function Level Authorization
 | Threat agents/Attack vectors | Security Weakness | Impacts |
 | - | - | - |
 | API Specific : Exploitability **3** | Prevalence **2** : Detectability **1** | Technical **2** : Business Specific |
-| Exploitation requires the attacker to send legitimate API calls to the API endpoint that they should not have access to. These endpoints might be exposed to anonymous users or regular, non-privileged users. It’s easier to discover these flaws in APIs since APIs are more structured, and the way to access certain functions is more predictable (e.g., replacing the HTTP method from GET to PUT, or changing the “users” string in the URL to "admins"). | Authorization checks for a function or resource are usually managed via configuration, and sometimes at the code level. Implementing proper checks can be a confusing task, since modern applications can contain many types of roles or groups and complex user hierarchy (e.g., sub-users, users with more than one role). | Such flaws allow attackers to access unauthorized functionality. Administrative functions are key targets for this type of attack. |
+| Exploitation requires the attacker to send legitimate API calls to the API endpoint that they should not have access to. These endpoints might be exposed to anonymous users or regular, non-privileged users. It’s easier to discover these flaws in APIs since APIs are more structured, and the way to access certain functions is more predictable (e.g., replacing the HTTP method from GET to PUT, or changing the “users” string in the URL to "admins", or changing the value of a parameter like "is_admin" from "false" to "true"). | Authorization checks for a function or resource are usually managed via configuration, and sometimes at the code level. Implementing proper checks can be a confusing task, since modern applications can contain many types of roles or groups and complex user hierarchy (e.g., sub-users, users with more than one role). | Such flaws allow attackers to access unauthorized functionality. Administrative functions are key targets for this type of attack. |
 
 ## Is the API Vulnerable?
 

2019/en/src/0xa4-lack-of-resources-and-rate-limiting.md

@@ -75,6 +75,8 @@ shell command injection once the attacker downloads the video as MP4.
 * Whitelist only the properties that should be updated by the client.
 * Use built-in features to blacklist properties that should not be accessed by
   clients.
+* If applicable, explicitly define and enforce schemas for the input data
+  payloads.
 
 ## References
 

2019/en/src/0xa5-broken-function-level-authorization.md

@@ -4,7 +4,7 @@ A7:2019 Security Misconfiguration
 | Threat agents/Attack vectors | Security Weakness | Impacts |
 | - | - | - |
 | API Specific : Exploitability **3** | Prevalence **3** : Detectability **3** | Technical **2** : Business Specific |
-| Attackers will often attempt to find unpatched flaws, common endpoints, or unprotected files and directories to gain unauthorized access or knowledge of the system. | Security misconfiguration can happen at any level of the API stack, from the network level to the application level. Automated tools are available to detect and exploit misconfigurations such as unnecessary services or legacy options. | Security misconfigurations can no only expose sensitive user data, but also system details that may lead to full server compromise. |
+| Attackers will often attempt to find unpatched flaws, common endpoints, or unprotected files and directories to gain unauthorized access or knowledge of the system. | Security misconfiguration can happen at any level of the API stack, from the network level to the application level. Automated tools are available to detect and exploit misconfigurations such as unnecessary services or legacy options. | Security misconfigurations can not only expose sensitive user data, but also system details that may lead to full server compromise. |
 
 ## Is the API Vulnerable?
 
@@ -65,6 +65,9 @@ The API life cycle should include:
   assets (e.g., images).
 * An automated process to continuously assess the effectiveness of the
   configuration and settings in all environments.
+* To prevent exception traces and other valuable information from being sent
+  back to attackers, if applicable, define and enforce all API response payload
+  schemas including error responses.
 
 ## References
 

2019/en/src/0xa6-mass-assignment.md

@@ -33,7 +33,7 @@ The attacker replays the request with a different payload
 
 ```
 POST /api/account/recovery
-{"email": "[email protected]';WAITFOR DELAY '0:0:5'--"}
+{"username": "[email protected]';WAITFOR DELAY '0:0:5'--"}
 ```
 
 This time, the response took ~5 seconds confirming the API is vulnerable to SQL
@@ -103,6 +103,8 @@ Preventing injection requires keeping data separate from commands and queries.
   of injection.
 * Validate incoming data using sufficient filters to only allow valid values for
   each input parameter.
+* To prevent data leaks, define and enforce schemas for all API responses.
+* Define data types and strict patterns for all string parameters.
 
 ## References
 
@@ -117,12 +119,10 @@ Preventing injection requires keeping data separate from commands and queries.
 
 * [CWE-77: Command Injection][5]
 * [CWE-89: SQL Injection][6]
-* [HOW TO: Command Injection, HackerOne][7]
 
 [1]: https://www.owasp.org/index.php/Injection_Flaws
 [2]: https://www.owasp.org/index.php/SQL_Injection
 [3]: https://www.owasp.org/images/e/ed/GOD16-NOSQL.pdf
 [4]: https://www.owasp.org/index.php/Command_Injection
 [5]: https://cwe.mitre.org/data/definitions/77.html
 [6]: https://cwe.mitre.org/data/definitions/89.html
-[7]: https://www.hackerone.com/blog/how-to-command-injections

2019/en/src/0xa7-security-misconfiguration.md

@@ -61,6 +61,9 @@ user by using a simple brute-force to guess the 6 digits token.
 * Generate documentation automatically by adopting open standards. Include the
   documentation build in your CI/CD pipeline.
 * Make API documentation available to those authorized to use the API.
+* Use external protection measures such as API security firewalls for all exposed versions of your APIs, not just for the current production version.
+* Avoid using production data with non-production API deployments. If this is unavoidable, these endpoints should get the same security treatment as the production ones.
+* When newer versions of APIs include security improvements, perform risk analysis to make the decision of the mitigation actions required for the older version: for example, whether it is possible to backport the improvements without breaking API compatibility or you need to take the older version out quickly and force all clients to move to the latest version.
 
 ## References
 

2019/en/src/0xa8-injection.md

@@ -11,6 +11,7 @@ or via other means:
 * caseysoftware
 * Chris Westphal
 * dsopas
+* DSotnikov
 * emilva
 * ErezYalon
 * flascelles