Skip to content
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

[QUESTION] how to properly sanitize API request payloads #1089

Open
tezvi opened this issue Apr 4, 2019 · 6 comments
Open

[QUESTION] how to properly sanitize API request payloads #1089

tezvi opened this issue Apr 4, 2019 · 6 comments
Labels

Comments

@tezvi
Copy link

tezvi commented Apr 4, 2019

Just a general question what do you guys recommend as a best practice to sanitize user request payloads for XSS and other potential harmful data.

There are several ideas that come on my mind, like:

  • Entity fields validation using Symfony Validator and annotations
  • Decorating deserializer / denormalizer / decoder and filtering string data from payload requests
  • Additional Apache / Nginx handling and filtering

Any other ideas? Does api-platform have it's own way of handling this? It seems to me that data is persisted straight from the request.

@soyuka
Copy link
Member

soyuka commented Apr 4, 2019

Data is validated after the denormalization phase. To avoid type errors you can disable type checking in the normalizers.

@tezvi
Copy link
Author

tezvi commented Apr 4, 2019

I understand. However I was aiming more into a security kind of checking.
For an example I would like to prevent malicious javascript data from even reaching a validation phase and deserialization to an entity.

I've come up with a simple implementation by decorating a default decoder and manually inspecting string values from a raw JSON payload and throwing HTTP 400 if funky business was detected. It's a bit defensive I know so i was wondering about alternatives.

@teohhanhui
Copy link
Contributor

  1. Always use parameterized (database) queries.
  2. Always escape (for the correct context) untrusted data (anything that came from user input) on the client.

@tezvi
Copy link
Author

tezvi commented Apr 5, 2019

Hi, thanks for input.
You are absolutely right, but how do you suggest to accomplish 2nd rule if you are using a default api POST endpoint configuration without custom controller or any custom listener and only default constraint validators on entity (no fancy custom filtering).
If you send a HTTP POST payload with malicious XSS it will be persisted to database. It means it will go through ReadListener -> DeserializeListener -> ValidationListener -> WriteListener and end up in database.

@sclausen
Copy link

If a string containing javascript is stored in the database, it’s not harmful per se. You shouldnt evaluate the javascript on output though.

@tezvi
Copy link
Author

tezvi commented Apr 23, 2019

Of course, that might be the solution. However, by using a default ApiPlatform implementation the XSS content will be returned to client. So you'll have to tweak around that.
Concerning security in general, a proper course of action should be to prevent any malicious data from entering into persisting layer. Better safe than sorry :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

4 participants