Skip to content

Specification should explicitely allow the validation of the Content-Type of incoming requests #1578

New issue

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

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

Already on GitHub? # to your account

Open
randomstuff opened this issue Mar 12, 2021 · 1 comment

Comments

@randomstuff
Copy link

The specification does not specify the Content-Type used for WebDriver requests. Even if the content of the request body is JSON, it appears to be valid (according to the specification) to send the request using Content-Type: application/x-www-form-urlencoded (for example).

Relevant snippets:

If request’s method is POST: Let parse result be the result of parsing as JSON with request’s body as the argument.

Where “parsing as JSON” is defined as:

The result of JSON deserialization with text is defined as the result of calling JSON.[Parse].

No mention that a suitable value for the Content-Type should be checked. This is only mandated for responses. This appears to be an involuntary omission in the specification.

Enforcing the value of the request Content-Type header is a simple way to prevent CSRF attacks against the WebDriver service. However, it has been argued that this is a violation of the specification.

Would it be possible to at least suggest the usage of a suitable of application/json for requests and allow the servers to enforce this?

For reference, Geckodriver now rejects application/x-www-form-urlencoded, multipart/form-data and text/plain as a CSRF mitigation.

@whimboo
Copy link
Contributor

whimboo commented Mar 15, 2021

@AutomatedTester can you please have a look? Thanks.

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

No branches or pull requests

2 participants