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

Testing production servers may be insecure (according to the docs) #28

Closed
GoogleCodeExporter opened this issue Mar 22, 2016 · 2 comments

Comments

@GoogleCodeExporter
Copy link

The RatproxyDoc wiki page says:

"[T]he proxy is not designed for dealing with rogue and misbehaving HTTP
servers and clients - and offers no guarantees of safe (or sane) behavior
there."

Does that mean that it might allow a malicous server to execute arbitrary
code with the privileges of the user running ratproxy?

If so, that would be unfortunate for people trying to test their production
servers hosted elsewhere, even over SSL. At least if they're using public
wifi. Maintaining a separate machine as a sandbox for running dangerous
tests can be too expensive or cumbersome for some developers.

Could you please clarify what does "safe" mean in the above quotation? Can
it be remote code execution or is it limited to manipulating ratproxy into
performing arbitrary HTTP requests, writing strange things to the logs, etc.?

Some suggestions:

1. Include a warning in the documentation about possible MITM attacks even
when you're testing your own server and mention the possibility of remote
code execution.

2. Verify the server's SSL/TLS certificate in ratproxy. That would remove
the risk when working over HTTPS.

3. I guess hardening ratproxy for use with malicious servers is not an
option for you because it would help the bad guys too much. Or maybe it's
just not worth the effort. But frankly that would be nice for the good
guys, too.

Original issue reported on code.google.com by alexkon on 13 Jan 2009 at 12:41

@GoogleCodeExporter
Copy link
Author

The text means just this. The proxy is engineered with certain assumptions about
usual HTTP client and server behaviors; no effort was made, and absolutely no
guarantees are given, regarding the accuracy of collected logs, or even proper
operation of the proxy itself, if any of the parties to the proxied 
communications
are grossly misbehaving or rogue.

I am not aware of any obvious vector that would allow remote code execution 
under
such circumstances, but as noted, there are no guarantees. If you are testing 
your
corporate networks on an open wifi network with no VPN, I'd guess the risk I 
messed
up something with the code is one of your least concerns, however :-)


Original comment by lcam...@gmail.com on 15 Feb 2009 at 11:00

  • Changed state: WontFix

@GoogleCodeExporter
Copy link
Author

I see. Thanks for your response.

I don't work for a company. I wanted to use ratproxy to test my App Engine site 
(so
there is no VPN; and the App Engine dev server is sufficiently different from
production to warrant performing the tests on the live website). So I guess 
I'll just
throw in a MITM proxy that would verify the *.appspot.com SSL certificate and 
use
ratproxy through it.

Original comment by alexkon on 15 Feb 2009 at 11:38

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

No branches or pull requests

1 participant