-
Notifications
You must be signed in to change notification settings - Fork 445
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
Toxiproxy API access from browser #219
Comments
My understanding is that you're suggesting we only allow I think we discussed that another option would be to do some kind of fancy token exchange where a client can't add a proxy without first making a request for an identifying token which it then passes to the next request to add a proxy. I don't remember what this is called. Likely @JackMc or @EiNSTeiN- would know. I think this would be a breaking change too. edit: I just noticed the conversation here. The token thingy I mentioned above is the header that @EiNSTeiN- mentions. |
Hey @xthexder! Thanks for pointing this out. I think that was changed after the PR shipped. Validating the |
@jpittis This wouldn't affect the proxies at all, but we would only allow localhost for the api endpoint. Right now this is configurable via the The token exchange thing is something we may need to add still, but it's not useful until we start validating the hostname. Otherwise we aren't protected by Same-Origin, and any malicious code could just request its own token. I'm not sure there's a good way to patch this without requiring updates to the clients. @JackMc The DoS thing I mentioned was more about an attacker being able to use Toxiproxy as a way to amplify traffic to some other target. I'd rather my computer wasn't used as part of a DDoS, but it's a fairly unlikely scenario, considering the number of variables for it to work. Still something that should be patched for other potential security reasons. |
Hey, sorry for the delay but this is the actual hackerone report related to this: https://hackerone.com/reports/236349 |
It's not only browser but if I use powershell rest command then also I need to override user-agent.
gives following error
One need to pass empty user-agent then only you able to see response.
|
I think this issue can be closed as browser are not allowing the User-Agent to be changed anymore, going by the comments on https://stackoverflow.com/a/44367690/525616 and the fact I couldn't make it happen in latest Firefox (tried against https://httpbin.io/user-agent). |
This was previously "fixed" in PR #184, but it looks like it is still possible to access Toxiproxy from a malicious page.
I was looking deeper into this, and the
User-Agent
header is programmable via JS.See: https://developer.mozilla.org/en-US/docs/Glossary/Forbidden_header_name
Generally this means a malicious page can make requests from the user's IP. The
Host
header can't be set, so this isn't terribly useful to an attacker, but there's still definitely DOS possibilities, and issues around unsecured internal endpoints.I think the main thing that needs to happen is to lock down and verify the hostname requests are being sent to.
127.0.0.1
andlocalhost
should be safe, but we should disallow requests to other hostnames unless explicitly set when starting the service.CC-ing people on the original PR/issue:
@JackMc @jpittis @sirupsen @EiNSTeiN-
The text was updated successfully, but these errors were encountered: