From db4ff579cdc8aa0a6ba6f7026b3a096d0efe5636 Mon Sep 17 00:00:00 2001 From: Inon Shkedy <31135573+inonshk@users.noreply.github.com> Date: Mon, 30 Sep 2019 16:12:13 +0300 Subject: [PATCH 1/8] Update 0xa3-excessive-data-exposure.md We can't ask developers to define and enforce all data returned by all API methods. It's like asking "Implement input validation on every single input on the system" - for many companies it won't be a feasible solution. As security engineers who provide recommendations for the broad community, we should always keep in mind the trade off between security and the available resources of the company that uses OWASP to improve the security posture.We should always assume that companies have limited resources. With this mindset, OWASP has been provided recommendations for many years. Recommendations like "Explicitly define and enforce data returned by all API methods including errors: give all JSON objects schemas, all string objects patterns, use clear field names." don't align with this mindset. The second part of the last recommendation already appears in the second recommendation. --- 2019/en/src/0xa3-excessive-data-exposure.md | 11 +++++------ 1 file changed, 5 insertions(+), 6 deletions(-) diff --git a/2019/en/src/0xa3-excessive-data-exposure.md b/2019/en/src/0xa3-excessive-data-exposure.md index 30a39b2c7..8cf718a56 100644 --- a/2019/en/src/0xa3-excessive-data-exposure.md +++ b/2019/en/src/0xa3-excessive-data-exposure.md @@ -42,12 +42,11 @@ 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. +* Use generis methods like "to_json" and "to_string" from the ORM / Model level + carefully. Backend engineers should always ask themselves "who is the consumer + of the returned data?" +* Classify sensitive and personally identifiable information (PII) that your + application stores and works. ## References From 49ad57ac2d3aa657558f8d8b96aa15c9ad1ca34a Mon Sep 17 00:00:00 2001 From: Inon Shkedy <31135573+inonshk@users.noreply.github.com> Date: Mon, 30 Sep 2019 16:17:15 +0300 Subject: [PATCH 2/8] Update 0xa5-broken-function-level-authorization.md Authorization mechanisms (not exploitation of mass assignment) that rely on "is_admin = true" are extremely not common in APIs. You could find them many years ago, and maybe today in WebGoats and CTF machines. --- 2019/en/src/0xa5-broken-function-level-authorization.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/2019/en/src/0xa5-broken-function-level-authorization.md b/2019/en/src/0xa5-broken-function-level-authorization.md index d4ee7a7c0..2f5f729d0 100644 --- a/2019/en/src/0xa5-broken-function-level-authorization.md +++ b/2019/en/src/0xa5-broken-function-level-authorization.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", 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. | +| 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. | ## Is the API Vulnerable? From 748286715872db45f7f0604b9d631e2ac14cdae8 Mon Sep 17 00:00:00 2001 From: Inon Shkedy <31135573+inonshk@users.noreply.github.com> Date: Mon, 30 Sep 2019 16:21:18 +0300 Subject: [PATCH 3/8] Update 0xa8-injection.md "* To prevent data leaks, define and enforce schemas for all API responses" sounds like a marketing message. Let's keep the list professional without any agenda. --- 2019/en/src/0xa8-injection.md | 1 - 1 file changed, 1 deletion(-) diff --git a/2019/en/src/0xa8-injection.md b/2019/en/src/0xa8-injection.md index c5729b6a6..f08179333 100644 --- a/2019/en/src/0xa8-injection.md +++ b/2019/en/src/0xa8-injection.md @@ -103,7 +103,6 @@ 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 From 9b2d99daeee6402292d10c20227152e3ee8d3005 Mon Sep 17 00:00:00 2001 From: Inon Shkedy <31135573+inonshk@users.noreply.github.com> Date: Mon, 30 Sep 2019 16:31:05 +0300 Subject: [PATCH 4/8] Update 0xa7-security-misconfiguration.md The right way to avoid detailed errors is to use built-in features in the framework to override detailed errors. API schemas are another layer of protection. Not a solution for the problem. --- 2019/en/src/0xa7-security-misconfiguration.md | 3 --- 1 file changed, 3 deletions(-) diff --git a/2019/en/src/0xa7-security-misconfiguration.md b/2019/en/src/0xa7-security-misconfiguration.md index d59ac37ca..63dc66fb3 100644 --- a/2019/en/src/0xa7-security-misconfiguration.md +++ b/2019/en/src/0xa7-security-misconfiguration.md @@ -65,9 +65,6 @@ 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 From 038610ca418a2048e28336905714e315252af4e1 Mon Sep 17 00:00:00 2001 From: Inon Shkedy <31135573+inonshk@users.noreply.github.com> Date: Mon, 30 Sep 2019 16:35:31 +0300 Subject: [PATCH 5/8] Update 0xa4-lack-of-resources-and-rate-limiting.md "* 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)." is related to A2, not A4. "* If your API accepts compressed files check compression ratios before expanding the files to protect yourself against "zip bombs"." - very niche example, I don't think it has a place in the list. --- 2019/en/src/0xa4-lack-of-resources-and-rate-limiting.md | 6 +----- 1 file changed, 1 insertion(+), 5 deletions(-) diff --git a/2019/en/src/0xa4-lack-of-resources-and-rate-limiting.md b/2019/en/src/0xa4-lack-of-resources-and-rate-limiting.md index 127e5dfe2..608ee2454 100644 --- a/2019/en/src/0xa4-lack-of-resources-and-rate-limiting.md +++ b/2019/en/src/0xa4-lack-of-resources-and-rate-limiting.md @@ -49,9 +49,6 @@ 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 @@ -60,8 +57,7 @@ errors. * 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 From 20b011ef9c5190e4a5e1f6202c543c2882c4dc96 Mon Sep 17 00:00:00 2001 From: Inon Shkedy <31135573+inonshk@users.noreply.github.com> Date: Wed, 23 Oct 2019 15:39:17 -0700 Subject: [PATCH 6/8] Update 0xa3-excessive-data-exposure.md --- 2019/en/src/0xa3-excessive-data-exposure.md | 13 +++++++++---- 1 file changed, 9 insertions(+), 4 deletions(-) diff --git a/2019/en/src/0xa3-excessive-data-exposure.md b/2019/en/src/0xa3-excessive-data-exposure.md index 8cf718a56..a7408485a 100644 --- a/2019/en/src/0xa3-excessive-data-exposure.md +++ b/2019/en/src/0xa3-excessive-data-exposure.md @@ -39,14 +39,19 @@ the site. ## How To Prevent -* Never rely on the client side to perform sensitive data filtering. +* Never rely on the client side to filter sensitive data. * Review the responses from the API to make sure they contain only legitimate data. -* Use generis methods like "to_json" and "to_string" from the ORM / Model level - carefully. Backend engineers should always ask themselves "who is the consumer - of the returned data?" +* Backend engineers should always ask themselves "who is the + consumer of the data?" before exposing a new API endpoint. +* Use generic methods like "to_json" and "to_string" from the ORM / Model level + very carefully. * Classify sensitive and personally identifiable information (PII) that your application stores and works. +* Implement a schema-based response validation mechanism as an extra layer of + security. As part of this mechanism define and enforce data returned by all API + methods. + ## References From 735f37591ad7d96bd24c949495ab52a18fa50c21 Mon Sep 17 00:00:00 2001 From: Inon Shkedy <31135573+inonshk@users.noreply.github.com> Date: Mon, 16 Dec 2019 11:04:14 -0800 Subject: [PATCH 7/8] Update 0xa3-excessive-data-exposure.md --- 2019/en/src/0xa3-excessive-data-exposure.md | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-) diff --git a/2019/en/src/0xa3-excessive-data-exposure.md b/2019/en/src/0xa3-excessive-data-exposure.md index a7408485a..2d7ab4c71 100644 --- a/2019/en/src/0xa3-excessive-data-exposure.md +++ b/2019/en/src/0xa3-excessive-data-exposure.md @@ -44,13 +44,14 @@ the site. data. * Backend engineers should always ask themselves "who is the consumer of the data?" before exposing a new API endpoint. -* Use generic methods like "to_json" and "to_string" from the ORM / Model level - very carefully. -* Classify sensitive and personally identifiable information (PII) that your - application stores and works. +* Avoid using generic methods such as to_json() and to_string(). + Instead, cherry-pick specific properties you really want to return +* Classify sensitive and personally identifiable information (PII) that + your application stores and works with, reviewing all API calls returning such + information to see if these responses pose a security issue. * Implement a schema-based response validation mechanism as an extra layer of security. As part of this mechanism define and enforce data returned by all API - methods. + methods, including errors. ## References From ee6d5275885b0d85738708c0cb745103f9291f16 Mon Sep 17 00:00:00 2001 From: Inon Shkedy <31135573+inonshk@users.noreply.github.com> Date: Mon, 16 Dec 2019 11:21:27 -0800 Subject: [PATCH 8/8] Update 0xa7-security-misconfiguration.md --- 2019/en/src/0xa7-security-misconfiguration.md | 3 +++ 1 file changed, 3 insertions(+) diff --git a/2019/en/src/0xa7-security-misconfiguration.md b/2019/en/src/0xa7-security-misconfiguration.md index 63dc66fb3..d59ac37ca 100644 --- a/2019/en/src/0xa7-security-misconfiguration.md +++ b/2019/en/src/0xa7-security-misconfiguration.md @@ -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