Skip to content

Fix: added information about query string parameters validation #7

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
Closed
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
18 changes: 18 additions & 0 deletions 2019/en/src/0xa3-improper-data-filtering.md
Original file line number Diff line number Diff line change
Expand Up @@ -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
Expand All @@ -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

Expand Down
11 changes: 11 additions & 0 deletions README.md
Original file line number Diff line number Diff line change
@@ -1,3 +1,11 @@
:warning: **OWASP API Security Top 10 2019 RC is waiting for comments and
contributions.** :warning:

Please check the [PDF][2] and [how to contribute][4]. The working draft is in
branch [develop][3].

---

OWASP API Security Top 10
=========================

Expand Down Expand Up @@ -48,3 +56,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/
[4]: https://github.com/OWASP/API-Security/blob/master/CONTRIBUTING.md