A web developer reached out to me to inquire if I could prevent the 403 Forbidden status from showing on a Drupal site. Of course I thought they just wanted a redirect to a 404 page or to the home page but that wasn't it. They wanted to know if I code make the 403 status code something else or prevent it from being sent to the browser.
Example: When someone browses to mysite.com/contact, they are sent to mysite.com/homepage by default because of redirection as I changed the how ErrorDocument handles 403 and 404 errors in Apache. However if you open devtools in any browser you can see that a 403 error is thrown.
The developer would like for that indication of the error code to be removed or replaced by something else. I am pretty sure it isn't possible but I have been wrong in the past so asking. I have done some Googling and can't find anything to put me on the path to finding where that is generated server-side to see if I can manipulate it. Any help would be appreciated as to find out if this is possible or not.
I agree with you, it is not possible to "override" 403 and 404 at server-side level.
What it is possible is to override 403 and 404 error pages through twig template, but it is only a frontend option
Related
I found a vulnerability for content-spoofing on my webpage.
This URL:
https://www.mygreatsite.com/www.mygreatsite.com%20has%20moved%20to%20www.evilsite.com.%20CHECK%200UT%20H0W%20COOL%20THE%20NEW%20SITE%20IS!%20Sadly,%20the%20file%00
Apache Output:
Not Found
The requested URL /www.mygreatsite.com has moved to www.evilsite.com. CHECK 0UT H0W COOL THE NEW SITE IS! Sadly, the file was not found on this server.
--
The URL Overrides the Apache-Error and outputs the text added to the URL in the Browser, along with a 404-Error.
Actually, all requests to the server should be redirected to the CMS (Typo3) which in turn handles the 404-error and shows a custom page.
When I enter an URL that doesn't exist, this works perfectly. Just the above mentioned URL screws everything up.
Interestingly, when I delete the «%00» from the end of the URL, the request is forwarded to the CMS and the correct error document is displayed.
I tried to add a separate ErrorDocument-Directive to the htaccess-file - with no success.
Any ideas what goes wrong and how I could solve this?
As Anubhava points out, when a NULL-Byte is detected, Apache doesn't load any modules and just throws the 404. That's why ErrorDocument and mod_rewrite in the htaccess don't work.
[Edit for clarification]
%00 or in Hex \x00 is a NULL byte. When web server finds a NULL byte at the end then web server thinks it is a spoofing request and considers it to be dangerous to be processed by any directives.
Due to security reasons web server doesn't load any modules for this request and returns a 404 / Not found status. Browser shows default 404 page with your decoded URL just below Not Found text.
Please help me on this.Already tried disable mode_security module through .htaccess no use.
PHP Version 5.6.30
Apache redirect the request to 403 page if pass parameter below.
&test[object_type]=0
The name (object_type) leads to 403 page.
eg:http://www.cudec.com.my/?test[object_type]=0 ✖ NOT WORKING LEADS TO 403
eg:http://www.cudec.com.my/?test[object_types]=0 ✓ WORKING
Will update this post to a full answer as soon as I got more information to work with ;)
I tried to call the 403-URL:
You don't have permission to access / on this server.
Additionally, a 403 Forbidden error was encountered while trying to use an ErrorDocument to handle the request.
You ensured that ModSecurity is the one replying with 403? Looks more like the folder permissions are insufficient.
Check if your DocumentRoot is at least readable for users (an 'r' at the last triple or 4 in the last byte).
If it's really ModSecurity, have a look into /var/log/apache2/modsecurity_audit.log and you should see which rule (by ID) is the one throwing 403 and also the reason (Error-Msg in the rule) why.
Does http://www.cudec.com.my/?test[object_types]=0 return the expected result?
The parameter doesn't seem to be interpretated when using &test[object_type] instead of &test[object_types] and the target ressource / seems to have insufficient rights, same for the error-pages...
I just did an SEO test of my site http://www.photographyattic.com using seositecheckup.com. It flagged up pages with 404 errors
From 100 distinct anchor links analyzed, 72 of them seems to be broken.
These pages don't seem to be broken when I view with my browser. Example http://www.photographyattic.com/category-1
Any idea why this would be?
http://www.photographyattic.com/category-1 is sending HTTP status code 404. The page doesn’t have to be broken because of that, you can display whatever you like on 404 pages.
You should send the status code 200 instead.
There are a lot of tutorials about error 404 handling and different solutions.
If I'm using TYPO3 6.1, Fluid/Extbase and RealURL, what is the best way to make an Error 404/500 handler that uses the page Uid = 13 (error/notfound/)
If you have an error 500, TYPO3 will not be able to handle it since it is "crashed". For 404 handling you will see a list of possibilites in the install tool, section [pageNotFound_handling].
The most straight-forward way for a website with one language is to enter an absolute URL to the [pageNotFound_handling] field. The URL could point to a TYPO3 page or a static HTML site. TYPO3 will not redirect to this page, but output this page and send the proper 404 status.
This is mostly a philosophical question about the best way to interpret the HTTP spec. Should a directory with no directory index (e.g. index.html) return 404 or 403? (403 is the default in Apache.)
For example, suppose the following URLs exist and are accessible:
http://example.com/files/file_1/
http://example.com/files/file_2/
But there's nothing at:
http://example.com/files/
(Assume we're using 301s to force trailing slashes for all URLs.)
I think several things should be taken into account:
By default, Apache returns 403 in this scenario. That's significant to me. They've thought about this stuff, and they made the decision to use 403.
According to W3C, 403 means "The server understood the request, but is refusing to fulfill it." I take that to mean you should return 403 if the URL is meaningful but nonetheless forbidden.
403 might result in information disclosure if the client correctly guesses that the URL maps to a real directory on disk.
http://example.com/files/ isn't a resource, and the fact that it internally maps to a directory shouldn't be relevant to the status code.
If you interpret the URL scheme as defining a directory structure from the client's perspective, the internal implementation is still irrelevant, but perhaps the outward appearance should indeed have some bearing on the status codes. Maybe, even if you created the same URL structure without using directories internally, you should still use 403s, because it's about the client's perception of a directory structure.
In the balance, what do you think is the best approach? Should we just say "a resource is a resource, and if it doesn't exist, it's a 404?" Or should we say, "if it has slashes, it looks like a directory to the client, and therefore it's a 403 if there's no index?"
If you're in the 403 camp, do you think you should go out of your way to return 403s even if the internal implementation doesn't use directories? Suppose, for example, that you have a dynamic web app with this URL: http://example.com/users/joe, which maps to some code that generates the profile page for Joe. Assuming you don't write something that lists all users, should http://example.com/users/ return 403? (Many if not all web frameworks return 404 in this case.)
The first step to answering this is to refer to RFC 2616: HTTP/1.1. Specifically the sections talking about 403 Forbidden and 404 Not Found.
10.4.4 403 Forbidden
The server understood the request, but is refusing to fulfill it. Authorization will not help and the request SHOULD NOT be repeated. If the request method was not HEAD and the server wishes to make public why the request has not been fulfilled, it SHOULD describe the reason for the refusal in the entity. If the server does not wish to make this information available to the client, the status code 404 (Not Found) can be used instead.
10.4.5 404 Not Found
The server has not found anything matching the Request-URI. No indication is given of whether the condition is temporary or permanent. The 410 (Gone) status code SHOULD be used if the server knows, through some internally configurable mechanism, that an old resource is permanently unavailable and has no forwarding address. This status code is commonly used when the server does not wish to reveal exactly why the request has been refused, or when no other response is applicable.
My interpretation of this is that 404 is the more general error code that just says "there's nothing there". 403 says "there's nothing there, don't try again!".
One reason why Apache might return 403 on directories without explicit index files is that auto-indexing (i.e. listing all files in it) is disabled (a.k.a "forbidden"). In that case saying "listing all files in this directory is forbidden" makes more sense than saying "there is no directory".
Another argument why 404 is preferable: google webmaster tools.
Indeed, for a 404, Google Webmaster Tool displays the referer (allowing you to clean up the bad link to the directory), whereas for a 403, it doesn't display it.