From 139114b88e281ee8945b96271c3e423956a34627 Mon Sep 17 00:00:00 2001 From: IgorSasovets Date: Mon, 17 Jun 2019 22:37:21 +0300 Subject: [PATCH 1/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..105365e38 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 From ef9d311be3aa59d2874ec40eb6ee56cbe77e6114 Mon Sep 17 00:00:00 2001 From: IgorSasovets Date: Mon, 24 Jun 2019 21:39:25 +0300 Subject: [PATCH 2/3] fix: moved query string scenario to lack of resources section --- 2019/en/src/0xa3-improper-data-filtering.md | 18 ---------------- ...xa4-lack-of-resources-and-rate-limiting.md | 21 +++++++++++++++++++ 2 files changed, 21 insertions(+), 18 deletions(-) diff --git a/2019/en/src/0xa3-improper-data-filtering.md b/2019/en/src/0xa3-improper-data-filtering.md index 105365e38..bdf431300 100644 --- a/2019/en/src/0xa3-improper-data-filtering.md +++ b/2019/en/src/0xa3-improper-data-filtering.md @@ -18,12 +18,6 @@ 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 @@ -44,24 +38,12 @@ 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 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 8f62ea7da..1db3cc511 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 @@ -21,6 +21,13 @@ following limits is missing or set inappropriately (i.e. too low/high) * Request payload size (e.g. uploads) * Number of requests per client/resource +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 @@ -40,6 +47,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 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. For example, load on database increases and it isn't +able to handle other requests; on UI side all functionality take more time to +proceed because server doesn't return required information from the DB. 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 +67,8 @@ 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 validation for query string parameters and request body on the server + side. ## References From 55eb86adaa10f68ecb82e1faa97521cdd887e1be Mon Sep 17 00:00:00 2001 From: IgorSasovets Date: Mon, 24 Jun 2019 21:52:11 +0300 Subject: [PATCH 3/3] fix: removed redundant empty line --- 2019/en/src/0xa4-lack-of-resources-and-rate-limiting.md | 1 - 1 file changed, 1 deletion(-) 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 1db3cc511..158dd4083 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 @@ -27,7 +27,6 @@ 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