security issue about miniproxy HOT 3 CLOSED

• I'm not sure I fully understand the security issue you're trying to point out. The request headers that the browser sends will only contain data that was set by using the proxy. So, if you sign into GitHub without using the proxy, then access GitHub through the proxy, no GitHub cookie information will be sent because the browser is making requests to the proxy rather than to GitHub. Also, as of right now, miniProxy doesn't actually support cookies; the proxy doesn't persist them between page loads. Adding cookie support would be interesting since the browser always sees the proxy as a single site, but the proxy would need to properly handle cookies across multiple sites without exposing cookies between sites. The only reason I unset() specific request headers is because cURL needs to set those headers (and ignore the browser's headers) since cURL is actually talking to the remote server, not the browser.
• Nice catch with the port numbers, I've just pushed a fix in adf9810.
• Basic authentication inside URLs appears to work fine for me, so could you elaborate on this issue? The markup <a href="http://test:[email protected]/password-ok.php">testing basic auth</a> results in the properly proxied URL http://path/to/miniProxy.php/http://test:[email protected]/password-ok.php, and clicking on the proxied link shows that the server was able to read the basic auth credentials with no issues.

I'll keep this issue closed for now, until there's further action to be taken on it.

Thanks for your feedback!

from miniproxy.

• i run the miniproxy on http://bla.com which requires authentication and uses cookies. so every request to bla.com contains those elements. miniproxy takes all headers and passes them on (without my fix). so in fact if i have a session-id inside the cookie-header, miniproxy passes this session-id on to another server, which is unnecessary. as miniproxy also sets its own url as referer, the target server basically got the the url bla.com and my session-id, which could lead to a security issue...
• basic auth works for the first url, but if you click any link on that, the credentials are gone...

from miniproxy.

• I believe I understand the issue now, but just to make sure: You're saying that you run the proxy at a domain where a DIFFERENT application requiring authentication/cookies also runs? And because they're both sharing the same domain, the browser request headers contain the cookie data for any/all applications associated with that domain, which the proxy is transparently passing through?
• I see what you mean about the basic auth URLs. They were were broken in the same way as the previous port problem. I've pushed 7755481 which fixes that issue.

from miniproxy.