I have an application which is accessed via HTTPS, but is "reverse proxied" to the server using plain HTTP. It is set up on AWS as follows:
[BROWSER] --(https)--> [ELB] --(http)--> [SERVER]
Everything works fine except when a page is being accessed by an unauthenticated user, the server responds with a HTTP 302 redirect using the whole protocol://server/path string. Like so:
Location: http://my.server.com/Account/Login?ReturnUrl=%2F
The problem is, it specifies HTTP as the protocol (presumably because it is being connected to by the ELB using HTTP. So the browser redirects the request using HTTP and now an error occurs. Is there a way to customize the redirect such that it redirects using just the path, so irregardless of protocol or hostname, it is redirected properly? Like so:
Location: /Account/Login?ReturnUrl=%2F
If this is not advisable, what can be done?
(note: I've checked other solutions posted on SO. All I've seen so far involve customizing the Path, not removing the protocol://hostname)
Related
How can you determine the current request URL if using off box SSL termination?
E.g.
Browser has url httpS://yourserver/
SSL Termination decrypts and sends onto http://yourserver
IIS/ASP.NET receives request at http://yourserver
At (3) if you use Context.Request.Url, Page.Request.Url or Page.Request.RawUrl it show a url with a http protocol and not httpS
How do get the public httpS URL that was origionally used at (1) in this case?
The convention used for Microsoft Products is to add a header at the reverse proxy.
Front-End-Https : On
So you know the http url is really https.
You could also add in your own header containing the original URL if you did something like URL translation (e.g. something like "Original-Uri").
This page shows how to do this using IIS AAR as the reverse proxy, though in my testing I could only get headers to pass through if they are prefixed with HTTP_ (which is later stripped out).
I am using response.sendRedirect() to redirect the user to Home page, once the user gets authenticated successfully. This is to avoid the "Login redirect vulnerability".
However, because of above change, One of my customer is facing issue where his HTTPS request are getting converted to HTTP (with ip address in the URL). The reason for the same is explained here
http://geekexplains.blogspot.in/2008/06/https-becoming-http-in-case-of.html
Now, How can i reproduce the issue (or setup the environment) so that I can verify my fix. I thought I could reproduce by setting up Apache server infront of tomcat but I am not able to reproduce above mentioned issue.
In Apache httpd.conf i have below entries
ProxyPass /myconsole ajp://localhost:8009/myconsole
ProxyPassReverse /myconsole ajp://localhost:8009/myconsole
Accessed the application like,
http://myapacheserver/myconsole/Login.jsp
After the successful login, I am getting redirected to
http://myapacheserver/myconsole/Home.jsp
I am expecting to redirect to the IP address. something like http://10.32.24.14:8080/myconsole/Home.jsp.
In the customer environment he is getting redirected to the ip address of App server (tomcat).
Any pointer would be helpful.
Thanks
Note:
For those interested, I am building the full URL by getting the first part of URI from the configuration file.
//Get the LB URI part. Eg: https://dev.loadbalancer.com/
String loadBalancerURI = getConfig().getLoadBalancerRequestURI();
String redirectURL = request.getContextPath() + "/Home.jsp";
//Prepend the LoadBalancer URI with redirect URI
if(loadBalancerURI != null)
{
redirectURL = loadBalancerURI + "/" + redirectURL;
}
//redirect to home page
response.sendRedirect(redirectURL);
return;
Edit: More info on the setup. The customer has F5 load balancer where the SSL traffic stops and then there is a Apache Reverse Proxy servers which proxy to pool of tomcat servers. The issue is when we do redirect the redirect URL is for Tomcat Servers. What we are expecting is to have the load balancer URL in the redirect URL.
Is it possible to do some change in the Apache server which will rewrite the URL in the HTTP header in the response send by Tomcat?
I'm not sure if you're really using a load balancer or if you just called one of your methods getLoadBalancerRequestURI, but where you only have one server, just use :
response.sendRedirect("./Home.jsp");
Its not necessary to specify the full url.
But if you do need to build the full url as you are doing, you can use something like this to check if its https://
String protocol = "https";
if( request.getRequestURL().toString().toLowerCase().startsWith("http://" ) )
{
protocol = "http";
}
Then make sure to build the url with the proper protocol.
See this link ..
So when an https request redirect happens, the target server has no clue what's the original request's protocol. It only receives an http request. Thus, the response for that would be an http response.
http://www.hoitikwong.com/2013/03/the-mystery-case-of-https-becoming-http.html
I was able to reproduce the issue (when HTTP-HTTPS redirect) which my customer was facing.
The communication from Apache (HTTPD server) to Tomcat (Web container) generally happens by using one of the following connectors (may be some other way as well).
mod_jk
mod_proxy_ajp
mod_proxy_http
mod_rewrite
I am able to reproduce the issue only when i use the mod_rewrite. If i use either mod_jk or mod_proxy_ajp or mod_proxy_http approach then the redirect works fine. But when i use mod_rewrite then when the redirect happens I am able to observe the HTTPS-HTTP conversion.
I am restricted some folders in my server to http and https using htacess, In some of my non https pages, I need to call a ajax script (php) which is using https (In the same domain), it is not working (https to https are working fine ).
I have tutorials/ path which is rewritten to use http only, i have one more folder(path) ajax/ rewritten to use https and I am making a call from tutorials/ to ajax/, it is failing.
It is the restriction of ajax for security reasons that you can not access any https page from http page. It is recommended that If you want to use https then all of the pages in your website must be accessed using https. To ensure this you should use relative path. If you use related path then http or https will automatically be calculated based on the source page from where you are accessing other page.
I Recently set an aspnet application under win 7 IIS 7 and got enabled SSL for this app.
the app works great under ssl, but when i change the schema from https to http, using a response.redirect, the request get a timeout, i am stuck with it, any idea is welcome.
regards
You cannot switch protocols unless you provide an absolute URL. The reference must be absolute.
make use of the encryptedUri and unencryptedUri attributes. "unencryptedUri" may be specified to send the user back to another domain or specific URI when the module removes security.
You can have a custom configuration..
<secureWebPages
mode="RemoteOnly"
encryptedUri="secure.mysite.com"
unencryptedUri="www.mysite.com"
maintainPath="True"
warningBypassMode="AlwaysBypass">
...
</secureWebPages>
An example would be to redirect secure requests to secure.mysite.com and requests that don't need to be secure could be redirected back to www.mysite.com. maintainPath is used in conjunction with the above attributes. When the module redirects to the encryptedUri or unencryptedUri, it appends the current path before sending users on their way.
How does web server implements url rewrite mechanism and changes the address bar of browsers?
I'm not asking specific information to configure apache, nginx, lighthttpd or other!
I would like to know what kind of information is sent to clients when servers want rewrite url?
There are two types of behaviour.
One is rewrite, the other is redirect.
Rewrite
The server performs the substitution for itself, making a URL like http://example.org/my/beatuful/page be understood as http://example.org/index.php?page=my-beautiful-page
With rewrite, the client does not see anything and redirection is internal only. No URL changes in the browser, just the server understands it differently.
Redirect
The server detects that the address is not wanted by the server. http://example.org/page1 has moved to http://example.org/page2, so it tells the browser with an HTTP 3xx code what the new page is. The client then asks for this page instead. Therefore the address in the browser changes!
Process
The process remains the same and is well described by this diagram:
Remark Every rewrite/redirect triggers a new call to the rewrite rules (with exceptions IIRC)
RewriteCond %{REDIRECT_URL} !^$
RewriteRule .* - [L]
can become useful to stop loops. (Since it makes no rewrite when it has happened once already).
Are you talking about server-side rewrites (like Apache mod-rewrite)? For those, the address bar does not generally change (unless a redirection is performed).
Or are you talking about redirections? These are done by having the server respond with an HTTP code (301, 302 or 307) and the location in the HTTP header.
There are two forms of "URL rewrite": those done purely within the server and those that are redirections.
If it's purely within the server, it's an internal matter and only matters with respect to the dispatch mechanism implemented in the server. In Apache HTTPD, mod_rewrite can do this, for example.
If it's a redirection, a status code implying a redirection is sent in the response, along with a Location header indicating to which URL the browser should be redirected (this should be an absolute URL). mod_rewrite can also do this, with the [R] flag.
The status code is usually 302 (found), but it could be configured for other codes (e.g. 301 or 307).
Another quite common use (often unnoticed because it's usually on by default in Apache HTTPD) is the redirection to the the URL with a trailing slash on a directory. This is implemented by mod_dir:
A "trailing slash" redirect is issued
when the server receives a request for
a URL http://servername/foo/dirname
where dirname is a directory.
Directories require a trailing slash,
so mod_dir issues a redirect to
http://servername/foo/dirname/.
Jeff Atwood had a great post about this: http://www.codinghorror.com/blog/2007/02/url-rewriting-to-prevent-duplicate-urls.html
How web server implements url rewrite mechanism and changes the address bar of browsers?
URL rewriting and forwarding are two completely different things. A server has no control over your browser so it can't change the URL of your browser, but it can ask your browser to go to a different URL. When your browser gets a response from a server it's entirely up to your browser to determine what to do with that response: it can follow the redirect, ignore it or be really mean and spam the server until the server gives up. There is no "mechanism" that the server uses to change the address, it's simply a protocol (HTTP 1.1) that the server abides by when a particular resource has been moved to a different location, thus the 3xx responses.
URL rewriting can transform URLs purely on the server-side. This allows web application developers the ability to make web resources accessible from multiple URLs.
For example, the user might request http://www.example.com/product/123 but thanks to rewriting is actually served a resource from http://www.example.com/product?id=123. Note that, there is no need for the address displayed in the browser to change.
The address can be changed if so desired. For this, a similar mapping as above happens on the server, but rather than render the resource back to the client, the server sends a redirect (301 or 302 HTTP code) back to the client for the rewritten URL.
For the example above this might look like:
Client request
GET /product/123 HTTP/1.1
Host: www.example.com
Server response
HTTP/1.1 302 Found
Location: http://www.example.com/product?id=123
At this point, the browser will issue a new GET request for the URL in the Location header.