Update a4 and a9 in the English version

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

@@ -0,0 +1,87 @@
+API4:2019 Lack of Resource & Rate Limiting
+===========================================
+
+| Threat agents/Attack vectors | Security Weakness | Impacts |
+| - | - | - |
+| API Specific : Exploitability **2** | Prevalence **3** : Detectability **3** | Technical **2** : Business Specific |
+| Exploitation requires simple API requests. No authentication is required. Multiple concurrent requests can be performed from a single local computer or by using cloud computing resources. | It’s common to find APIs that do not implement rate limiting or APIs where limits are not properly set. | Exploitation may lead to DoS, making the API unresponsive or even unavailable. |
+
+## Is the API Vulnerable?
+
+API requests consume resources such as network, CPU, memory, and storage. The
+amount of resources required to satisfy a request greatly depends on the user
+input and endpoint business logic. Also, consider the fact that requests from
+multiple API clients compete for resources. An API is vulnerable if at least one
+of the following limits is missing or set inappropriately (e.g., too low/high):
+
+* Execution timeouts
+* Max allocable memory
+* Number of file descriptors
+* Number of processes
+* Request payload size (e.g., uploads)
+* Number of requests per client/resource
+* Number of records per page to return in a single request response
+
+## Example Attack Scenarios
+
+### Scenario #1
+
+An attacker uploads a large image by issuing a POST request to `/api/v1/images`.
+When the upload is complete, the API creates multiple thumbnails with different
+sizes. Due to the size of the uploaded image, available memory is exhausted
+during the creation of thumbnails and the API becomes unresponsive.
+
+### Scenario #2
+
+We have an application that contains the users' list on a UI with a limit of
+`200` users per page. The users' list is retrieved from the server using the
+following query: `/api/users?page=1&size=100`. An attacker changes the `size`
+parameter to `200 000`, causing performance issues on the database. Meanwhile,
+the API becomes unresponsive and is unable to handle further requests from this
+or any other clients (aka DoS).
+
+The same scenario might be used to provoke Integer Overflow or Buffer Overflow
+errors.
+
+## How To Prevent
+
+* Docker makes it easy to limit [memory][1], [CPU][2], [number of restarts][3],
+  [file descriptors, and processes][4].
+* Implement a limit on how often a client can call the API within a defined
+  timeframe.
+* 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.
+
+
+## References
+
+### OWASP
+
+* [Blocking Brute Force Attacks][5]
+* [Docker Cheat Sheet - Limit resources (memory, CPU, file descriptors,
+  processes, restarts)][6]
+* [REST Assessment Cheat Sheet][7]
+
+### External
+
+* [CWE-307: Improper Restriction of Excessive Authentication Attempts][8]
+* [CWE-770: Allocation of Resources Without Limits or Throttling][9]
+* “_Rate Limiting (Throttling)_” - [Security Strategies for Microservices-based
+  Application Systems][10], NIST
+
+[1]: https://docs.docker.com/config/containers/resource_constraints/#memory
+[2]: https://docs.docker.com/config/containers/resource_constraints/#cpu
+[3]: https://docs.docker.com/engine/reference/commandline/run/#restart-policies---restart
+[4]: https://docs.docker.com/engine/reference/commandline/run/#set-ulimits-in-container---ulimit
+[5]: https://www.owasp.org/index.php/Blocking_Brute_Force_Attacks
+[6]: https://github.com/OWASP/CheatSheetSeries/blob/3a8134d792528a775142471b1cb14433b4fda3fb/cheatsheets/Docker_Security_Cheat_Sheet.md#rule-7---limit-resources-memory-cpu-file-descriptors-processes-restarts
+[7]: https://github.com/OWASP/CheatSheetSeries/blob/3a8134d792528a775142471b1cb14433b4fda3fb/cheatsheets/REST_Assessment_Cheat_Sheet.md
+[8]: https://cwe.mitre.org/data/definitions/307.html
+[9]: https://cwe.mitre.org/data/definitions/770.html
+[10]: https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-204-draft.pdf

2019/en/src/0xa9-improper-asset-management.md

@@ -0,0 +1,74 @@
+API9:2019 Improper Asset Management
+
+====================================
+
+| Threat agents/Attack vectors | Security Weakness | Impacts |
+| - | - | - |
+| API Specific : Exploitability **3** | Prevalence **3** : Detectability **2** | Technical **2** : Business Specific |
+| Old API versions are usually unpatched and are an easy way to compromise systems without having to fight state-of-the-art security mechanisms, which might be in place to protect the most recent API versions. | Outdated documentation makes it more difficult to find and/or fix vulnerabilities. Lack of assets inventory and retire strategies leads to running unpatched systems, resulting in leakage of sensitive data. It’s common to find unnecessarily exposed API hosts because of modern concepts like microservices, which make applications easy to deploy and independent (e.g., cloud computing, k8s). | Attackers may gain access to sensitive data, or even take over the server through old, unpatched API versions connected to the same database. |
+
+## Is the API Vulnerable?
+
+The API might be vulnerable if:
+
+* The purpose of an API host is unclear, and there are no explicit answers to the following questions:
+  * Which environment is the API running in (e.g., production, staging, test, development)?
+  * Who should have network access to the API (e.g., public, internal, partners)?
+  * Which API version is running?
+  * What data is gathered and processed by the API (e.g., PII)?
+  * What's the data flow?
+* There is no documentation, or the existing documentation is not updated.
+* There is no retirement plan for each API version.
+* Hosts inventory is missing or outdated.
+* Integrated services inventory, either first- or third-party, is missing or outdated.
+* Old or previous API versions are running unpatched.
+
+## Example Attack Scenarios
+
+### Scenario #1
+
+After redesigning their applications, a local search service left an old API
+version (`api.someservice.com/v1`) running, unprotected and with access to the
+user database. While targeting one of the latest released applications, an
+attacker found the API address (`api.someservice.com/v2`). Replacing `v2` with
+`v1` in the URL gave the attacker access to the old, unprotected API,
+exposing the personal identifiable information (PII) of over 100 Million users.
+
+### Scenario #2
+
+A social network implemented a rate-limiting mechanism that blocks attackers
+from using brute-force to guess reset password tokens. This mechanism wasn’t
+implemented as part of the API code itself, but in a separate component between
+the client and the official API (`www.socialnetwork.com`).
+A researcher found a beta API host (`www.mbasic.beta.socialnetwork.com`) that
+runs the same API, including the reset password mechanism, but the rate limiting
+mechanism was not in place. The researcher was able to reset the password of any
+user by using a simple brute-force to guess the 6 digits token.
+
+## How To Prevent
+
+* Inventory all API hosts and document important aspects of each one of them,
+  focusing on the API environment (e.g., production, staging, test,
+  development), who should have network access to the host (e.g., public,
+  internal, partners) and the API version.
+* Inventory integrated services and document important aspects such as their
+  role in the system, what data is exchanged (data flow), and its sensitivity.
+* Document all aspects of your API such as authentication, errors, redirects,
+  rate limiting, cross-origin resource sharing (CORS) policy and endpoints,
+  including their parameters, requests and responses.
+* 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
+
+### External
+
+* [CWE-1059: Incomplete Documentation][1]
+* [OpenAPI Initiative][2]
+
+[1]: https://cwe.mitre.org/data/definitions/1059.html
+[2]: https://www.openapis.org/