I've written a proxy that provides tunnelling for secured connections. However, the proxy tends to redirect (non-secured, HTTP GET) connections to a redirected page if the site being accessed is invalid. It does it by returning a "HTTP/1.0 302 Moved Temporarily" message. Will returning a HTTP/1.0 302 Moved Temporarily to a HTTP CONNECT also result in the same browser behaviour?
I've tried and it doesn't work as expected.
Therefore I was wondering if anyone could suggest the correct way of asking a HTTP CONNECT request to redirect to a different page?
If the site being accessed is invalid, you probably want to do something other than a 302 redirect. Where would you redirect to? A 302 redirect should probably only be passed back to the client from the destination site itself, but in that case it would still be a valid site.
If the site the client is requesting is not accepting connections, you should probably return a 502 Bad Gateway error to the client. See:
https://www.rfc-editor.org/rfc/rfc2616#section-10.5.3
If you can actually connect to the destination site, you should return a 200 OK to the client and then whatever the destination site returns over the proxied connection.
Related
I am working on a RESTful web application using Go + gorilla/mux v1.4 framework. Some basic security testing after a release revealed an Open URL Redirection vulnerability in the app that allows user to submit a specially crafted request with an external URL that causes server to response with a 301 redirect.
I tested this using Burp Suite and found that any request that redirects to an external URL in the app seems to be responding with a 301 Moved Permanently. I've been looking at all possible ways to intercept these requests before the 301 is sent but this behavior seems to be baked into the net/http server implementation.
Here is the raw request sent to the server (myapp.mycompany.com:8000):
GET http://evilwebsite.com HTTP/1.1
Accept: */*
Cache-Control: no-cache
Host: myapp.mycompany.com:8000
Content-Length: 0
And the response any time is:
HTTP/1.1 301 Moved Permanently
Location: http://evilwebsite.com/
Date: Fri, 13 Mar 2020 08:55:24 GMT
Content-Length: 0
Despite putting in checks for the request.URL to prevent this type of redirect in the http.handler, I haven't had any luck getting the request to reach the handler. It appears that the base http webserver is performing the redirect without allowing it to reach my custom handler code as defined in the PathPrefix("/").Handler code.
My goal is to ensure the application returns a 404-Not Found or 400-Bad Request for such requests. Has anybody else faced this scenario with gorilla/mux. I tried the same with a Jetty web app and found it returned a perfectly valid 404. I've been at this for a couple of days now and could really use some ideas.
This is not the claimed Open URL redirect security issue. This request is invalid in that the path contains an absolute URL with a different domain than the Host header. No sane client (i.e. browser) can be lured into issuing such an invalid request in the first place and thus there is no actual attack vector.
Sure, a custom client could be created to submit such a request. But a custom client could also be made to interpret the servers response in a non-standard way or visit a malicious URL directly without even contacting your server. This means in this case the client itself would be the problem and not the servers response.
I want to block some sites with my proxy by responding with 403. I succeeded with responding in such a way in an HTTP proxy, but when I get the CONNECT method, I respond with:
HTTP/1.1 403 Forbidden
Status: 403 Forbidden
Proxy-agent: smth
Connection: close
But users still get the ERR_TUNNEL_CONNECTION_FAILED. What can I do to provide users with a nice 403 error?
RFC 2817 does not disallow 4xx codes, and the Draft has the section "4. Extensibility" that states that
"The tunneling handshake is freely extensible using the HTTP/1.x headers;"
But it looks like all browsers decided to just ignore almost every non-2xx codes for security reasons.
Here are some bugs reports:
https://learn.microsoft.com/en-us/previous-versions/windows/internet-explorer/ie-developer/compatibility/dd565641(v=vs.85)
Internet Explorer 8 has a feature that ensures that the secure connection is made all the way to the target server. If it isn't, then no page is displayed.
https://bugzilla.mozilla.org/show_bug.cgi?id=479880
I realize that I'm way late to the party here, but [...] this fix is terrible for proxy admins (myself included). Our proxy returns a 403 forbidden for filtered SSL content and an error page about why the content is blocked, and Firefox just drops all of it on the floor
https://bugs.chromium.org/p/chromium/issues/detail?id=7338
So that's the way it is.
I have configured Jersey client to automatically follow HTTP 302 redirects:
DefaultApacheHttpClientConfig config = new DefaultApacheHttpClientConfig();
config.getProperties().put(ClientConfig.PROPERTY_FOLLOW_REDIRECTS, true);
Client client = ApacheHttpClient.create(config);
This works perfectly fine when I receive HTTP 302 for HTTP GET request: the client redirects me automatically and the last response I got from client is HTTP 202.
However, when submitting HTTP POST request that results in HTTP 302, the client does not redirects me automatically. I.e., the last response from the client is HTTP 302 and I need to follow redirects manually. This behavior seems counter-intuitive for me, as Web browsers are handling such redirects automatically. The use case also seems quite common, for instance, when trying to login with HTTP POST, you often get redirected to a new page.
Why is it so? And is there a way to handle it automatically, in a same way Web browser does it?
I'm getting this error when trying to make an ajax request in a custom module:
XMLHttpRequest cannot load https://www.vossmarket.com/index.php/shoppinglist/index/showLists/product/4294/form_key/6erZKqom1ynOWDKI/qty/1/. No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://www.vossmarket.com' is therefore not allowed access.
I'm assuming the problem is that I am calling https from the http, but I'm not able to figure out why it is calling the https. I've turned off https in the magento config (I changed secure_base_url to http://vossmarket.com and I turned Use Secure URLs in Frontend to "no"). Now all links stay http, but when I visit my custom module, it is still redirecting (302) to https. This happens to every link http://vossmarket.com/shoppinglist (my custom module), any other route stays http, but any route that hits my module in any ways 302s to https
Any ideas what might be happening or the best way to fix it?
Have you tried putting a file called crossdomain.xml in your web root (accessible by both http and https), ie at http(s)://vossmarket.com/crossdomain.xml
This should help define that cross site origin is allowed between http and https.
In your case, I think the custom module is upset about being accessed over http and is sending the 302 to your browser, so it would be a case of studying the controller action of the custom module to figure out why it is forcing https (instead of asking Magento what the secure URL is).
Actually, if you try this crossdomain.xml you will need the browser to request https out of the http loaded page otherwise I think you will still get the 302 redirect - but with crossdomain.xml in place you should be able to XMLHttpRequest from http://vossmarket.com to https://vossmarket.com
But, you know, often there is good reason for https so I think you should understand why https is being forced and also I don't know about that XML secure="false" - does it really mean an https request is returned over http? I hope not but I don't know.
For more information read up on CORS although your 'cross domain' is http crossing to https.
I have to integrate a 3rd party newsletter signup form that makes an AJAX call to HTTP url.
That form I'm placing on pages that use HTTP or HTTPS protocols ( http for home pg., ect.; https for ecommerce related stuff )
I don't think anything is sent back from the destination server ( at least I can't see the response) other than status code.
I'm getting 200 OK whether I submit the form from HTTP or HTTPS page and watch what's going on with it in Firebug. Wonder if it's safe to assume the call gets processed successfully?
Usually, I like to have a proof positive that something worked or didn't, but in this case all test signups show up the next day, ( due to sign up getting processed as some scheduled task I'm guessing ), hence the unease.
You can call https server from http but can't call http from https directly using AJAX.
To call http user from https server you need to call your server side application from java script using AJAX, and then call http url from your server side application then send back this to the client.
You can use window.location.protocol to check whether you're currently on a Secure connection, and if so, you should AJAX a secure url.