Merge pull request #1 from PauloASilva/develop

Develop

Author: inonshk

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

@@ -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
 
@@ -31,22 +25,31 @@ 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.
+An IOT-based surveillance system allows administrators to create users with
+different permissions.
+An admin created a user for a new security guard that should have access only to
+specific buildings in the site.
+Once the security guard uses his mobile app, an API call is triggered to:
+`"/api/sites/111/cameras"` in order to receive data about the available cameras
+and show them on the dashboard.
+The response contains a list with details about cameras in the following format:
+`{"id":"xxx","live_access_token":"xxxx-bbbbb","building_id":"yyy"}`
+While the client GUI shows only cameras which the security guard should have
+access to, the actual API response contains a full list of all the cameras in
+the site.
 
 ## 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/dist/owasp-api-security-top-10.pdf

@@ -20,6 +20,7 @@ following limits is missing or set inappropriately (i.e. too low/high)
 * 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
 
@@ -40,6 +41,18 @@ combinations using a multi-thread script, against the
 `/api/system/verification-codes/{smsToken}` endpoint to discover the right token
 within a few minutes.
 
+### Scenario #3
+
+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 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],
@@ -48,6 +61,9 @@ within a few minutes.
   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 control the number of records to be
+  returned in the response.
 
 ## References
 

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

@@ -60,6 +60,33 @@ vulnerable firmware:
 $ curl -k "https://${deviceIP}:4567/api/CONFIG/restore" -F 'appid=$(/etc/pod/power_down.sh)'
 ```
 
+### Scenario #3
+
+We have an application with basic CRUD functionality for operations with
+bookings. An attacker managed to identify that NoSQL injection might be possible
+through `bookingId` query string parameter in the delete booking request. This
+is how the request looks like: `DELETE /api/bookings?bookingId=678`.
+
+The API server uses the following function to handle delete requests:
+
+```javascript
+router.delete('/bookings', async function (req, res, next) {
+  try {
+      const deletedBooking = await Bookings.findOneAndRemove({'_id' : req.query.bookingId});
+      res.status(200);
+  } catch (err) {
+     res.status(400).json({error: 'Unexpected error occured while processing a request'});
+  }
+});
+```
+
+Attacker intercepted the request and changed `bookingId` query string parameter
+as below, the attacker managed to delete another user booking:
+
+```
+DELETE /api/bookings?bookingId[$ne]=678
+```
+
 ## How To Prevent
 
 Preventing injection requires keeping data separate from commands and queries.
@@ -73,6 +100,8 @@ Preventing injection requires keeping data separate from commands and queries.
 * Prefer a safe API which provides a parameterized interface.
 * Always limit the number of returned records to prevent mass disclosure in case
   of injection.
+* Validate incoming data using sufficient filters to only allow valid values for
+  each input parameter.
 
 ## References