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

Test complex ops backend against inner query encoding #318

Open
rpkilby opened this issue Oct 9, 2019 · 0 comments
Open

Test complex ops backend against inner query encoding #318

rpkilby opened this issue Oct 9, 2019 · 0 comments

Comments

@rpkilby
Copy link
Collaborator

rpkilby commented Oct 9, 2019

The complex ops backend expects inner query strings to be URL encoded so that they may contain "unsafe" characters. If an inner query string contains any of the characters used by complex ops ()~|& and it is not URL encoded, then parsing on the backend could break.

Here's an "unsafe" example: (a=b) | (c=d())

Correct encoding would roughly look like:

  • (a=b) | (c=d()) (raw)
  • (a%3Db) | (c%3Dd%28%29) (inner encoded)
  • %28a%253Db%29%20%7C%20%28c%253Dd%2528%2529%29 (outer encoded)

Improper encoding in a single step would look like:

  • (a=b) | (c=d()) (raw)
  • %28a%3Db%29%20%7C%20%28c%3Dd%28%29%29 (outer encoded)

The backend should already function as expected, but tests should be added to prevent a regression. Should test both expected/malformed examples.

Also, need to check if there are cases where encoding the inner query string is optional when safe. e.g., is (a=1&b=2) & (c=3&d=4) safe? The inner querystring uses operators that the regex parses, but given that they're wrapped by parens, it should be fine?

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

No branches or pull requests

1 participant