-
Notifications
You must be signed in to change notification settings - Fork 871
fix(error-response-plugin): percentage-encode path to limit XSS #1134
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
base: master
Are you sure you want to change the base?
Conversation
Remove the ? From your url Chrome sends the url with escaped path variables |
Can you provide a reproducible example about your claim of js being executed?
|
Sure, will send something tomorrow. If you use curl you can see it isn't escaped by the server side |
When I log the http-proxy-middleware/src/plugins/default/error-response-plugin.ts Lines 28 to 29 in 56e3885
req.url: /?%3Cscript%3Ealert(document.cookie);%3C/script%3E Happy to see I reproduction of the issue 👍 |
Right, apologies; I only actually tested this with curl originally and misunderstood the encoding that browsers all do these days. So the browser is actually sending the escaped values, and that's being echoed verbatim. For example:
Given this, not sure if you want to include this "fix". Up to you! |
I tried a local request with Can you provide a working reproduction so it can be investigated? |
|
Ensures all unsafe characters in the request URL are percent-encoded before including the path in the error response, mitigating XSS risks.
Visiting the proxied page
https://host.com/?<script>alert(document.cookie);</script>
when an error occured, would result in the js being executed.Motivation and Context
We don't want to render arbitrary HTML and execute arbitrary just because it's in the path.
How has this been tested?
manually
Types of changes