fix: moved query string scenario to lack of resources section

Author: IgorSasovets

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
 

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