From 463a0b4bd9e63936659d749f20e5dc5f8fe6695e Mon Sep 17 00:00:00 2001 From: PauloASilva Date: Thu, 6 Jun 2019 11:14:59 +0100 Subject: [PATCH 1/3] chore: advertise Top 10 2019 RC --- README.md | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/README.md b/README.md index 9a70cc12e..ea0b2b823 100644 --- a/README.md +++ b/README.md @@ -1,3 +1,10 @@ +:warning: **OWASP API Security Top 10 2019 RC is waiting for comments and +contributions.** :warning: + +Please check the [PDF][2], [source][3] and [how to contribute][4]. + +--- + OWASP API Security Top 10 ========================= @@ -48,3 +55,6 @@ one. [0]: https://www.owasp.org/index.php/User:ErezYalon [1]: http://creativecommons.org/licenses/by-sa/3.0/ +[2]: https://github.com/OWASP/API-Security/blob/develop/2019/en/dist/owasp-api-security-top-10.pdf +[3]: https://github.com/OWASP/API-Security/tree/develop/2019/en/src +[4]: https://github.com/OWASP/API-Security/blob/master/CONTRIBUTING.md From 023486b2c09cf966af449ab08591aa87c70f9003 Mon Sep 17 00:00:00 2001 From: PauloASilva Date: Thu, 6 Jun 2019 13:23:46 +0100 Subject: [PATCH 2/3] refator: add note about branch `develop` --- README.md | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/README.md b/README.md index ea0b2b823..8c83aa43b 100644 --- a/README.md +++ b/README.md @@ -1,7 +1,8 @@ :warning: **OWASP API Security Top 10 2019 RC is waiting for comments and contributions.** :warning: -Please check the [PDF][2], [source][3] and [how to contribute][4]. +Please check the [PDF][2] and [how to contribute][4]. The working draft is in +branch [develop][3]. --- @@ -56,5 +57,5 @@ one. [0]: https://www.owasp.org/index.php/User:ErezYalon [1]: http://creativecommons.org/licenses/by-sa/3.0/ [2]: https://github.com/OWASP/API-Security/blob/develop/2019/en/dist/owasp-api-security-top-10.pdf -[3]: https://github.com/OWASP/API-Security/tree/develop/2019/en/src +[3]: https://github.com/OWASP/API-Security/tree/develop/ [4]: https://github.com/OWASP/API-Security/blob/master/CONTRIBUTING.md From 22cd9ea582332b619f5ce5c8d62f9c4d4608690f Mon Sep 17 00:00:00 2001 From: IgorSasovets Date: Mon, 17 Jun 2019 22:28:44 +0300 Subject: [PATCH 3/3] fix: added information about query parameters validation --- 2019/en/src/0xa3-improper-data-filtering.md | 18 ++++++++++++++++++ 1 file changed, 18 insertions(+) diff --git a/2019/en/src/0xa3-improper-data-filtering.md b/2019/en/src/0xa3-improper-data-filtering.md index bdf431300..145aef72b 100644 --- a/2019/en/src/0xa3-improper-data-filtering.md +++ b/2019/en/src/0xa3-improper-data-filtering.md @@ -18,6 +18,12 @@ There are two types of Improper Data Filtering: 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. +One more issue is Improper Query String Parameters validation. It could lead to +DDoS attacks against the server. Widely spread problem is validation of such +query string parameters as `size`, `page`, .etc. Absence of limitation for max, +min values of these parameters might cause performance issues, Internal Server +Errors. + ## Example Attack Scenarios ### Scenario #1 @@ -38,12 +44,24 @@ 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. +### Scenario #3 + +We have a MEAN stack application that contains the users list on a UI. List of +users can be retrieved from the server using a following query: +`/dashboard/users?page=1&size=100`. There are limitation on maximum number of +users per page (on UI side) - 200 users. An attacker changes the size parameter +in order to retrieve large number of users, for example 200 000 or more and it +causes performance issues. The same scenario might be used to provoke `Integer Overflow` +or `Buffer Overflow` errors. + ## 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. +* Add proper validation for query string parameters and request body on the server + side. ## References