It's possible to inject text in the not-found message in order to trick the user to make him visit website or do something an attacker might be interested in.
It is returning the user input in the not-found message body. This can be misused in a number of ways.
Attacker injecting text can redirect users to malicious sites.
Attacker injecting text can prompt users with false messages.
Proof Of Concept:
https://drupal7.example/.htcaccess/***Attention!***%2f../Site%20has%20been%20replace%20by%20a%20new%20one%20https://www.google.com%20so%20go%20to%20the%20new%20one%20since%20this%20one
In some other cases, like
https://drupal7.example/htaccess // without dot for example
everything's fine and
# Make Drupal handle any 404 errors.
ErrorDocument 404 /index.php
in .htaccess file working as expected and Drupal handle all 404 errors.
Any idea how to fix this and make Drupal handle all 404 errors including the one from example?
This behavior is due to the presence of %2F (encoded slash /) in URL.
Apache uses the AllowEncodedSlashes directive to determine whether encoded path separators in URLs are allowed to be passed through. Default is Off, in which case getting an Apache 404 instead of a Drupal 404 is "normal" when you have %2f in URL :
The AllowEncodedSlashes directive allows URLs which contain encoded path
separators (%2F for / and additionally %5C for \ on accordant systems)
to be used in the path info.
Off : such URLs are refused with a 404 (Not
found) error.
On : such URLs are accepted, and encoded slashes are
decoded like all other encoded characters.
NoDecode : such URLs are accepted, but encoded slashes
are not decoded but left in their encoded state.
Default is Off because letting Apache blindly decodes path separators would expose your machine to directory traversal attacks (see CVE-2007-0450), setting this directive to On is not safe.
Hopefully, the NoDecode option (available since version 2.3.12) allows to accept such URLs without exposing your server, so to fix that and let Drupal handle such requests in 404 or whatever, just add the directive in httpd.conf :
AllowEncodedSlashes NoDecode
Note : Virtual hosts don't inherit this directive from the global context, it's required to reset the directive to the desired value in virtual host container(s), otherwise it will take the default value.
Now, if you still get a server 404 instead of a drupal 404, that's probably because the directive ErrorDocument 404 is not taken into account, or is overridden somewhere.
A quick way to check whether or not this directive is actually loaded is precisely to set a static content (by the way in this case there's no input display issue ;) :
ErrorDocument 404 "Page not found"
Maybe the correct behavior for Apache would be to catch this kind of urls as 403, and to let drupal handle it as well you would set ErrorDocument 403 /index.php.
It's also worth noting that the generic drupal 404 "page not found" page can easily be overridden at admin/config/system/site-information, as well as the 403 "access denied" page.
Related
So, my problem goes like this:
I created a custom 404 error page (error.html) and I want it to be displayed without actual redirection to the page, thus, keeping the user-entered URL. Examples:
User puts "http ://localhost/whatever.the.url/would/be" in their address bar.
error.html displays, but the URL in the address bar remains as entered by user: "http
://localhost/whatever.the.url/would/be"
I tried other people's guides and answers but they didn't work for me, perhaps because I'm really amateur and I have no idea how .htaccess actually works, sorry.
In addition to that, my .htaccess currently looks like this:
ErrorDocument 404 http://localhost/www.minimalistik.de/fejle/404/fejl.html/
Yeah it isn't much. Thanks to everyone who'd help me with this :)
To serve the error document via an internal subrequest (ie. the URL in the browser's address bar does not change) then simply specify a root-relative URL (starting with a slash) to your error document in the ErrorDocument directive (this is generally considered "normal" behaviour).
For example, if your error.html file is in the /error-documents subdirectory off the document root then you would use the following:
ErrorDocument 404 /error-documents/error.html
The user is not externally redirected to the error document.
ErrorDocument 404 http://localhost/www.minimalistik.de/fejle/404/fejl.html/
However, when you specify an absolute URL (ie. with scheme + hostname) as in this example then Apache triggers a 302 (temporary) redirect to the error document and the user is externally redirected. No "404 Not Found" response is returned to the client, unless the error document itself is returning a 404 status. And if it's returning a 200 OK (the default) then the error document itself could potentially be indexed by search engines! Needless to say, this is not recommended and is an error in most scenarios.
Reference:
https://httpd.apache.org/docs/2.4/mod/core.html#errordocument
I had injected some urls to crawl that is one round and I found some urls as db_redir_temp.
{"url":"http://www.universityhealth.org","pst":"temp_moved(13), lastModified=0: https://www.universityhealth.org/"}
{"url":"http://silvercappartners.com","pst":"temp_moved(13), lastModified=0: http://silvercappartners.com/index.html"}
may i know that the http://www.universityhealth.org is pointing to same url why it is showed db_redir_temp.
This url is pointing to http://silvercappartners.com to this url http://silvercappartners.com/index.html
should I consider the pst column will give the redirected url page.
The two URLs
http://www.universityhealth.org
https://www.universityhealth.org/
differ in one important point, the protocol (or scheme) - http vs. https. These are not always equivalent, eg. a web server may not support https. The other point (the trailing /) is irrelevant, the HTTP request for both the empty path and the server root path is GET / HTTP/1.1 (maybe using a different protocol version).
But true reason is simply that the server responded with HTTP/1.1 302 Found which is a redirect, see HTTP 302.
The "pst" or "protocol status" metadata field may include a message. For redirects it contains the redirect target.
I have the following code in my htaccess file to handle 404 codes:
ErrorDocument 404 https://www.mywebsite.co.uk/lost.php
RewriteEngine On
And of course a custom 404 page is returned (works fine).
I did a nibbler check and it said the following:
It is a common mistake to setup missing page handling by using a
redirect. The missing page should directly return a 404 error and not
redirect to another page.
This website does not return a 404 error HTTP status code for missing
pages. This is bad because search engines like Google might mistake
this for a real page of content.
What is the best practice to handle 404 error codes if the above is no good? I am just wanting something generic that is a catch all. No need to use a 301 because the point of my 404 is just to let visitors know that what they are looking for is not there or they have made a typo.
If it is a "common mistake" to to use a redirect how should it be done?
Thank you for any help.
You need to remove https:// or http:// from 404 handler otherwise it forces Apache to do a full redirect instead of internal rewrite.
So you can use:
ErrorDocument 404 /lost.php
It depends. If you have an application running on the webserver that takes in every URL coming in and has some logic implemented, that by itself has to figure out if the URL exists, then the application should directly return a 404 error page under the given URL and not redirect to another page like 404.html or so. But if your webserver handles the url requests with the .htaccess file then it is OK to setup a document that is returned in case of an invalid URL.
At LTCperformance.com, I've created a custom 404 page. If the user types in ltcperformance.com/fakepage.html, it forwards to the 404 page. But if there's no extension (ltcperformance.com/fakepage), it simply shows a default system 404 page.
I'm controlling the 404 page using htaccess:
ErrorDocument 404 http://ltcperformance.com/404.php
ErrorDocument 403 http://ltcperformance.com/404.php
ErrorDocument 500 http://ltcperformance.com/404.php
I have URL Rewriting in Joomla Administrator = on
Also, in Joomla Administrator, the Adds Suffix to URL = off
Any ideas? I've gone through every answer I can find on other posts and nothing will bring up my custom 404 page if there isn't an extension on the file.
ADDITIONAL INFO:
Any non-existent pages go to the homepage when I do these settings:
- Search Engine Friendly URLs / NO
- Use URL rewriting /Yes
- Adds Suffix to URL /No
I have someone taking a look at it on the server side, but I don't know what server issue it is - everybody online says it's a server issue but the support can't pinpoint what the actual server issue is. It's Godaddy; I did set their 404 page settings (they have a separate place to put it) to my 404 page, but that didn't work either.
Joomla .htaccess routes all requests to the index.php in order to support SEF urls.
In case it can't route a page, it will load the templates' error.php page. You can edit that to your requirements, this will be the easiest.
Should the error.php not be included in your template, copy the one in /templates/system to your template folder and customize it.
I have two separated vhost. On the www. one, I have instaled this only line on .htaccess
redirectMatch 301 ^(.*)$ http://d_blur_blur_s.com$1
All works as expected except that in the case where the POST is converted to GET.
Please notice that the post has parametres as a get (i didn't do it, and I won't change it) i am just trying to avoid duplicated content. I am showing firebug trace.
I expect to have the POST redirected on the main domain with redirectmatch or other trick.
Update
I have half of the internal links on the site written with www and the other half without it. So I need to keep both public but not duplicated. I need the GETs forwarded as GETs and the POSTs frowarded as POSTs. the problem is big, I have 12000 pages indexed, and lot of forms. So I am first searching for a generic solution without changing code. I full control de server.
Thanks a lot
A redirect response from your server for whatever request you made, regardless of it being POST or GET request, always results in your client making a GET request (unless you somehow enable it to NOT automatically follow redirects--sometimes I do this with curl, but I don't know any widely used browsers with this functionality available easily to the user). The client browser takes the URL provided by the redirect and treats it as a URL to perform a GET request. No way around it, the POST data is discarded by the server since it was intended for the server resource at the original URL.
If you redirect outside of .htaccess, say in a PHP file to construct redirect response, your only option is to convert the POST parameters into a string of GET parameters and add it to the end of the URL you send back to the client with your redirect response.
I'm fairly confident there is not a way to do automatic POST parameter appending to redirect in the .htaccess file or in the httpd.conf files whether you use the redirect directive or the rewrite directive via the mod_rewrite module.
You redirect using 307 instead of 301 to keep the post data, but some browsers show a dialog to the user if he is sure he want to sent the post data, so not real pretty.
But I'd rather go and fix the problem at the root. The only way you would get a post to the wrong domain is if the html-form refers to the wrong domain (e.g. <form action="www.d_blur_blur_s/public/main/loginGenerator.php" ...). Just fix the html.
Don't worry about duplicated content as search engines never send post-requests, only get. You current solution should do the trick to prevent duplicated content.
The only way to do a redirect and preserve POST data (that I am aware of) is to use mod_rewrite with mod_proxy and then use P flag in RewriteRule.
On your www host enable mod_rewrite, mod_rewrite and .htaccess through httpd.conf and then put this code in your .htaccess under DOCUMENT_ROOT directory:
Options +FollowSymLinks -MultiViews
# Turn mod_rewrite on
RewriteEngine On
RewriteBase /
RewriteRule ^ http://d_blur_blur_s.com%{REQUEST_URI} [P]
I bumped into this POST->GET rewrite as well. An API call like this:
curl -X POST https://example.com/api/user/123456789
was entering my API framework with a GET request method.
The cause seems to be related to POST requests with an empty body. To avoid this issue you can set the Content-Length header:
curl -X POST https://example.com/api/user/123456789 -H 'Content-Length: 0'
or pass something in the body:
curl -X POST https://example.com/api/user/123456789 -d ''
In HTTP 1.1, statusCode (307) indicates that the request should be repeated using the same method and post data. Change the redirect type to fix it.
Adding www to the base URL did it for me.