I'm using an app (MediaCP) that thinks both HTTP and HTTPS can coexist on the same port. I cannot modify the code since it uses IonCube and some other shenanigans, but I could edit the JS player, or add files if needed. Since it's minified it's hard to know where to look for, I'm attaching it if you want to take a look at it: https://pastebin.com/DiCnMq32
The thing is that when I request a .js file while being on an HTTP page, it tries to load the content using HTTP, probably because it uses /// as a request protocol...
If entering https://mywebsite.com, then the jwplayer.js file loads https://example.com:2000/jwplayer.flash.swf and works just fine
If entering http://mywebsite.com, then the jwplayer.js file tries to load http://example.com:2000/jwplayer.flash.swf and it fails with a 400 error since the server obviously expected an HTTPS handshake. It doesn't matter that jwplayer.js was loaded using https.
I've been using ErrorDocument 400 to redirect these requests to HTTPS but the REQUEST_URI is lost on the process...
ErrorDocument 400 https://example.com:2000
This work just fine for users trying to login, but when entering http://example.com:2000/jwplayer.flash.swf it will always redirect to https://example.com:2000 and the JS code won't work.
I cannot use the REDIRECT_ server variables, because of the https:// prefix, that makes Apache think that the redirect is going to a remote server and by default it won't sent those headers.
I cannot remove the https://example.com:2000 prefix to use a local php / cgi file since it causes an infinite loop (oh, https is wrong lets try to load the 400 error page, oh https is wrong, lets...). Perhaps using a ScriptAlias would override the HTTPS check? I haven't got any luck with it but I'll try if you think it will make it work.
I've also tried to add %{REQUEST_URI} to the ErrorDocument line but it seems the variable is always empty.
Any ideas?
PS: I´m using Apache 2.4.25 on CentOS 7
Try to reference the JavaScript files as src="//url/somfolder/somefile.js" in the tags, it should use the current ref prefix http: or https: without specifically calling it out. Example:
<script src="//example.com/script.js"></script>
Note CSS can be referenced in a similar fashion:
<link rel="stylesheet" href="//example.com/style.css">
Related
I have a basic project running on IIS 8.5
sites
-> test.domain.com
--->virtualPath
----->index.html
On the browser when enter https://test.domain.com/virtualpath, it is return 301 (redirect) to test.domain.com/virtualpath/
I don't have any URL Rewrites in IIS configuration. Just trying to figure out why it is redirecting to test.domain.com/virtualpath/
How can avoid this 301 redirect?
The short answer is that IIS doesn't handle extensionless URLs very well. URLs are processed based on the file extension, otherwise it's presumed to be a directory you're looking to get served. The normal convention however is to omit the index.html file.
But most services like IIS take that for granted, and if nothing is specified, it will lookup if there's a /index.html.
Lets take a simple example:
google.com
In reality what's being served to you is:
google.com/index.html
Lets take your request as an example https://test.domain.com/virtualpath
test.domain.com
- virtualPath/
- index.html
As you can see, you're essentially trying to get a directory rather than a specific file. It's up to IIS to try to find and understand that you want a file instead of a directory now. That's why you're getting a 301. It's redirecting you to the /index.html file.
I have been running some automated security scans and the following URL triggers a 404:
/%FF%FE%3Cscript%3Ehaikumsg%28326%29%3C%2Fscript%3E
This is run from the route on the domain on an Apache server (so this should be easy to replicate).
My htaccess is setup with ErrorDocument 404 /site/404 but this isn't being caught. I know this because if I completely empty the htaccess file I am still presented with the same standard apache 404 page.
Clearly this is a tag hack so I have to be careful how its handled, however I'd like to know how to manage it so it at least does my /site/404 instead of nothing.
It turns out the solution is to move your 404 redirect to the Vhosts not htaccess!! Very simple solution and that will fix it. Apache obviously works with the URL before even getting to the htaccess file so moving the 404 redirect is needed at a higher level.
However if you need to decode and use the URLs then the following begins to help:
https://serverfault.com/questions/261683/how-does-apache-process-a-path-with-a-percent-encoded-url-in-it
Basically the solution is to add AllowEncodedSlashes On to the Vhosts file.
As per https://httpd.apache.org/docs/2.0/mod/core.html#allowencodedslashes.
This is a relatively recent behavioral change and appears to be related only to requests which include a "Upgrade-Insecure-Requests: 1" request header.
Apache has started rewriting such requests for sites which are HTTP-only to an HTTPS URL using the default site name instead of just adding the / at the end of the requested URL.
Example: URL submitted in browser: http://www.example.com/blah
Intended redirect: 301 to http://www.example.com/blah/
Instead redirects: 301 to https://default.site.configured/blah/
This happens whether it's a named virtual on the same address as the default server or a virtual using a separate address with separate Listen directives.
I understand all the arguments in favor of the idea that everything should always be encrypted and I don't want to get into a debate about that. This site doesn't consider the tradeoffs desirable at this time.
The default site does have SSL and is configured to redirect HTTP->HTTPS, but the www.foo.com site is not configured that way and does not wish to implement SSL at this time.
Is there any way to get Apache 2.4 to disregard that "Upgrade" header and simply rewrite the URL as desired rather than altering the domain name?
After banging on this some more, I finally found the source of my woes.
This happens when you have IP based virtual hosts and did not configure a name for them using the "ServerName" directive.
tl;dr: If you are having this problem, try adding a "ServerName www.example.com" directive within the VirtualHost definition for the site and that should resolve it.
Details:
It does not happen until you encounter a URL that requires a rewrite other than adding a trailing /. (i.e. if you get a request that doesn't contain the "Upgrade-Insecure-Requests: 1" header, it only gets the trailing / added, but if you get one with that header, it also tries to rewrite the protocol to https which triggers the full URL rewrite).
In my case, the default host name had an SSL configuration, so it didn't fall back to HTTP after the rewrite or reject the rewrite as invalid.
YMMV, I did not continue to do an exhaustive test of all permutations once I found the solution.
I have Apache installed on my server and I need to redirect from http to https. The reason for this is our load balancer solution cannot hand https so requests come in on http and then we transfer them to https using the below lines in the httpd.conf file.
<VirtualHost 10.1.2.91:80>
Redirect 302 /GladQE/link https://glad-test.com/GladQE/link.do
</VirtualHost>
This works fine for GET requests but POST requests will lose the parameters passed on the URL. What would be the easiest way to perform this redirect and maintain POST params?
I need to get from http://glad-test.com/GladQE/link.do to here https://glad-test.com/GladQE/link.do maintaining POST params
Thanks
Tom
You can try with the HTTP status code 307, a RFC compilant browser should repeat the post request.
Reference: http://en.wikipedia.org/wiki/List_of_HTTP_status_codes
In contrast to how 302 was historically implemented, the request
method is not allowed to be changed when reissuing the original
request. For instance, a POST request should be repeated using another
POST request.
To change from 302 to 307, do that:
<VirtualHost 10.1.2.91:80>
Redirect 307 /GladQE/link https://glad-test.com/GladQE/link.do
</VirtualHost>
Standard Apache redirects will not be able to handle POST data as they work on the URL level. POST data is passed in the body of the request, which gets dropped if you do a standard redirect.
You have an option of either using a PHP script to transparently forward the POST request, or using a combination of Rewrite (mod_rewrite) and Proxy (mod_proxy) modules for Apache like follows:
RewriteEngine On
RewriteRule /proxy/(.*)$ http://www.example.com/$1 [P,L]
P flag passes the request to the Proxy module, so anything that comes to your site (via GET or POST doesn't matter) with a URL path starting with a /proxy/ will transparently be handled as a proxy redirect to http://www.example.com/.
For the reference:
http://httpd.apache.org/docs/current/mod/mod_rewrite.html
http://httpd.apache.org/docs/current/mod/mod_proxy.html
Either your public facing website MUST use SSL to protect confidentiality or there is no sensitive data enver passing through it, and no possibility that your site will ever be used for a lauinchboard for sslstripping (there's a very good reason why Google serve up search results over HTTPS).
If you are not encrypting traffic between browser and your site then why are you trying to encrypt them between your load balancer and your webserver? If you do happen to have a SSL termination outside the load balancer (a very silly approach) then using HTTPS between the load balancer and the webserver is far from efficient. The question also implies lots of other security problems like session fixation/sniffing and SSLStripping vulnerabilities.
Im trying to use a .htaccess file on an apache server to point /cmsfiles/flipbooks/thisFlipBook/ to /thisFlipBook
Ive tried:
RewriteRule ^/thisFlipBook/ /cmsfiles/flipbooks/thisFlipBook[L,R=302]
as well as:
RewriteRule ^/thisFlipBook/cmsfiles/flipbooks/thisFlipBook[L]
(without the R tag so that mod_rewrite knows its an internal apache redirect instead of having the browser send a new request for the rewritten resources.)
The first rule results in a 404, and the second results in:
/thisFlipBook/index.php/index.php/index.php/index.php/index.php/index.php/index.php/index.php/index.php/index.php/index.php/index.php/index.php/index.php/index.php/index.php/index.php/index.php/index.php/index.php/index.php/index.php/index.php/index.php/index.php/index.php/index.php/index.php/index.php/index.php/index.php/index.php/index.php/index.php/index.php/index.php/index.php/index.php/index.php/index.php/index.php/index.php/index.php/index.php/index.php/index.php/index.php/index.php/index.php/index.php/index.php/index.php/index.php/index.php/index.php/index.php/index.php/index.php/index.php/index.php/index.php/index.php/
However if you manually navigate to /cmsfiles/flipbooks/thisFlipBook it manages to find the index.html file and load it successfully.
Am i doing something wrong?
Also: server side apache redirects and unmounted folder are the correct way to be doing this right? Client started requesting so many flipbooks that we've moved them out of the project for deployments sake.