.htaccess file access hardeningDisabled
info@elgg.org
Security issues should be reported to security@elgg.org!
©2014 the Elgg Foundation
Elgg is a registered trademark of Thematic Networks.
Cover image by RaĆ¼l Utrera is used under Creative Commons license.
Icons by Flaticon and FontAwesome.
- Jerome Bakker@jeabakker
Jerome Bakker - 0 likes
- Christoph Heck@ChristophHeck
Christoph Heck - 0 likes
- Jerome Bakker@jeabakker
Jerome Bakker - 0 likes
- you're using Apache webserver?
- mod_rewrite is enabled (probably yes otherwise Elgg won't work)
- if, in your browser, you go to http://yoursite.com/vendor/autoload.php what kind of response do you get (check your browser developers info (F12) then the network tab)
- Christoph Heck@ChristophHeck
Christoph Heck - 0 likes
-
Request-URL:
http://192.168.56.102/vendor/autoload.php
-
Request method:
GET
-
Statuscode:
403 Forbidden
-
Remote-Address:
192.168.56.102:80
- Jerome Bakker@jeabakker
Jerome Bakker - 0 likes
- Jerome Bakker@jeabakker
Jerome Bakker - 0 likes
You must log in to post replies.We try to access the 'vendor/autoload.php' file, the hardening should prevent this.
Is the 3rd line of your sample code correctly pasted? Because that should be
No, it wasn't correctly pasted. I have edited my warning description.
Do you have any other ideas?
The htaccess hardening isn't something that needs to be active, it just helps with the protection of your website.
Of course I can understand that you wish to do the best you can to secure your site.
I can't think of more things you could check. Maybe Google "apache rewritecond not working" for suggestions???
Yes, I am using an apache webserver. mod_rewrite is enabled. If I go to http://yoursite.com/vendor/autoload.php the following 403 Error occures:
So the hardening does work (yay!!), it's just the detection that isn't working.
Any errors in the webservers/php error log?
Maybe there is a firewall rule on your webserver which prevents it from checking the hardening rules?
The page does a curl call to the autoload.php file and checks if the response is 403. If a firewall would prevent the 'outgoing' call the response wouldn't be 403, thus no check mark.
I also thought it could be an SSL verification issue, but in your example I see the website doesn't run on an https site (for internal testing of course ;)