So - here's the scenario.
Lohan is busy testing an application which uses remote web-services on a server called (example) www.target.com, but the program bypasses all proxy servers etc, making it impossible to trap and mangle requests.
So, we do the following:
1 - We make a note of the IP address of www.target.com (in this case, we'll assume it is 196.310.150.126 )
2 - Add a host entry in hosts, mapping www.target.com to 127.0.0.1
3 - Fire up a quick C# app written by yours truly which listens on 127.0.0.1:80
4 - Fire up a proxy server
5 - Configure the C# app to use proxy server 127.0.0.1:port of proxy
Now, the C# app does the following:
1 - Intercepts the HTTP request addressed to www.target.com
2 - Mangles the HTTP request to convert it into a proxied request (ie: Request "GET / HTTP/1.0" now becomes "GET http://196.31.150.216/ HTTP/1.0")
3 - Writes the request to the proxy server
4 - Writes the response back to the application
So, we're now able to intercept, fuzz, mangle etc all the requests and responses between the application and the web service. Not really rocket science, but rather handy...
The screenshot shows something similar, but using a web browser in place of the application here. I am using paros in this example because I am still doing large chunks of work on Suru...
/ian
Available at http://proxy-firewall.com/
Available at http://proxy-firewall.com/
What then?
Usually you can generate your own CA cert, add it to whatever source of trust your app uses (probably the JVM or host OS), and then use it to mint certs for your proxy to present. Much harder if the app does not consult an external authority to decide who to trust, then you can try to find the cert it does use and replace it.
For what it is worth, WebScarab has supported this exact "reverse proxy" functionality since approx Aug 2003.
Yes, it gets tricky in various cases, for example, when you are testing a thick client that accesses a hard-coded IP address rather than a domain name, and checks the SSL cert.
If you are intercepting a call directly to the IP address, one way around this is to run the app in a VMWare instance, and play routing/NAT tricks in the container OS. Keep in mind that the container OS running your intercepting proxy still needs to be able to reach the destination IP, so you need to be selective about which streams you NAT.
I also had to deal with a thick client validating the cert presented by WebScarab. In that case, I had to find the keystore that the app was validating against, and add my own CA cert to it, as well as generating a specific cert for WebScarab to present, since the default cert doesn't have the right hostname either. (Unfortunately, there is no UI for this - I had to rebuild the JAR with a different server.p12 key file)
Finally, this same app was using SSL client certs for mutual auth, but fortunately, the client was just assuming that if the SSL connection was successfully negotiated, all was OK. Taking a copy of the client cert and loading that into WebScarab allowed the "second hop" to successfully authenticate to the real server.