refactor(a3:2019): move Filter Manipulation to a dedicated category

* remove "Filter Manipulation" references from A3:2019
* create a candidate "A11:2019 Filter Manipulation" category
* improve Fitler Manipulation "Is the API Vulnerable?" and
  "How to Prevent" sections

Author: PauloASilva

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

@@ -4,19 +4,13 @@ A3:2019 Excessive Data Exposure
 | Threat agents/Attack vectors | Security Weakness | Impacts |
 | - | - | - |
 | API Specific : Exploitability **3** | Prevalence **2** : Detectability **2** | Technical **2** : Business Specific |
-| Exploitation of excessive data exposure is simple, and is usually done by using different clients while sniffing the traffic they produce to analyze the API responses and look for sensitive data exposure that should not be returned to the user. | APIs rely on clients to perform the data filtering. Since APIs are used as data sources, sometimes developers try to implement them in a generic way without thinking about the sensitivity of the exposed data. Automatic tools usually can’t detect this type of vulnerability because it’s hard to differentiate between legitimate data returned from the API and sensitive data that should not be returned without a deep understanding of the application. | Excessive Data Exposure commonly leads to exposure of sensitive data. |
+| Exploitation of Excessive Data Exposure is simple, and is usually done by sniffing the traffic to analyze the API responses looking for sensitive data exposure that should not be returned to the user. | APIs rely on clients to perform the data filtering. Since APIs are used as data sources, sometimes developers try to implement them in a generic way without thinking about the sensitivity of the exposed data. Automatic tools usually can’t detect this type of vulnerability because it’s hard to differentiate between legitimate data returned from the API and sensitive data that should not be returned without a deep understanding of the application. | Excessive Data Exposure commonly leads to exposure of sensitive data. |
 
 ## Is the API Vulnerable?
 
-There are two types of Excessive Data Exposure:
-
-* **Client Side Data Filtering**: The API returns sensitive data to the client
-  by design. This data is usually filtered on the client side before being
-  presented to the user. An attacker can easily sniff the traffic and see the
-  sensitive data.
-* **Filter Manipulation**: the API performs data filtering in an unsafe manner
-  based on filters from the client. An attacker can send malicious filters
-  causing the API to return sensitive data they should not be exposed to.
+The API returns sensitive data to the client by design. This data is usually
+filtered on the client side before being presented to the user. An attacker can
+easily sniff the traffic and see the sensitive data.
 
 ## Example Attack Scenarios
 
@@ -29,24 +23,18 @@ comment’s author, is also returned. The endpoint implementation uses a generic
 `toJSON()` method on the `User` model, which contains PII, to serialize the
 object.
 
-### Scenario #2
-
-An open source team chat solution provides the endpoint `/api/v1/users.list`
-which supports two parameters: `query` and `fields`. Using a regular user
-account and manipulating both parameters an attacker can enumerate admin
-accounts, exposing sensitive information such as the password reset token:
-`GET /api/v1/users.list?query={“roles”:{$in:“admin”}}&fields={“services.password.reset”:1, “username”:1”, “email.0”:1}`.
-Via password reset, the attacker can takeover one of the admin accounts.
-
 ## How To Prevent
 
 * 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.
-* Be careful when performing data filtering based on filters from the client.
 
 ## References
 
 ### OWASP
 
 ### External
+
+* [CWE-213: Intentional Information Exposure][1]
+
+[1]: https://cwe.mitre.org/data/definitions/213.html

2019/en/src/0xab-filter-manipulation.md

@@ -0,0 +1,66 @@
+A11:2019 Filter Manipulation
+============================
+
+| Threat agents/Attack vectors | Security Weakness | Impacts |
+| - | - | - |
+| API Specific : Exploitability **3** | Prevalence **2** : Detectability **2** | Technical **2** : Business Specific |
+| Exploitation of Filter Manipulation is usually done by using different clients while sniffing the traffic they produce to analyze the API responses. API requests are then replayed with common values for each filter (e.g. replacing `{"role": "user"}` by `{"role":"admin"}`) | APIs rely on clients to perform the data filtering. Since APIs are used as data sources, sometimes developers try to implement them in a generic way leaving the door open to unauthorized data access through filter manipulation. | Filter Manipulation usually leads to sensitive data exposure. |
+
+## Is the API Vulnerable?
+
+The API performs data filtering in an unsafe manner based on filters from the
+client. An attacker can send malicious filters causing the API to return
+sensitive data they should not be exposed to.
+
+The API might be vulnerable if:
+
+* Accepts any object property as filter (unless this is a business
+  requirement).
+* Does not maintain a whitelist of allowed values for each filter.
+* Accepts wildcards (e.g. `{"role":"*"}`) as filter.
+* API clients are allowed to select what object properties should be included in
+  the API server response.
+
+## Example Attack Scenarios
+
+### Scenario #1
+
+An open source team chat solution provides the endpoint `/api/v1/users.list`
+which supports two parameters: `query` and `fields`. Using a regular user
+account and manipulating the `query` parameter an attacker can enumerate admin
+accounts:
+
+```
+GET /api/v1/users.list?query={“roles”:{$in:“admin”}}&fields={“username”:1”, “email.0”:1}
+```
+
+### Scenario #2
+
+An open source team chat solution provides the endpoint `/api/v1/users.list`
+which supports two parameters: `query` and `fields`. Using a regular user
+account and manipulating the `fields` parameters an attacker can expose
+sensitive information such as password reset tokens:
+
+```
+GET /api/v1/users.list?query={“roles”:“user”}&fields={“services.password.reset”:1, “username”:1”, “email.0”:1}
+```
+
+Via password reset, the attacker can takeover other users accounts.
+
+## How To Prevent
+
+* Be careful when performing data filtering based on filters from the client.
+* Validate that API client is authorized to filter data based on given object
+  properties.
+* Whenever possible validate given filter values against a whitelist of allowed
+  values.
+* Avoid using wildcards (e.g. `{"role":"*"}`) as data filter
+* Whenever the client should be able to select what object properties should be
+  included in the API server response, keep a whitelist of such allowed object
+  properties.
+
+## References
+
+### OWASP
+
+### External