I have a form with many inputs. Some named "date", "type" etc.
The form action points to http://www.xxx.com/admin/links/create, via POST.
When I try to submit it (having required fields populated correctly), I get a 403 response.
In the following cases, I get either 302 or 200 response codes (depending on log-in cookie):
plain http://www.xxx.com/admin/links/create URL in address bar (I know that's GET);
using websniffer (GET & POST)
curl/wget from local
I checked the permissions, the .htaccess (I only have FTP access to web-root) and various other places and everything looks fine.
I hope it's not naming collision of the inputs (actually, I do hope so, because that'll be easy to fix).
All the above happen in production, which is Linux (Apache/2.0.51 on Fedora). Everything works fine on local, which is Windows. Don't tell me it's permissions...
Does somebody know what could be the cause for this - in my own perception - strange behavior?
Culprit: Apache's mod_security.
I didn't have that module installed in my Windows machine (that's why it worked locally), but the server had it installed.
Here's what I did:
I checked the access logs. Found this:
[...] mod_security: Access denied with code 403. Pattern match "!(^application/x-www-form-urlencoded$|^multipart/form-data;)" at HEADER("Content-Type") [...] [uri "/admin/links/create"] [...]
As I don't know how to handle mod_security (yet!), I removed it altogether, and it worked. In your .htaccess:
<IfModule mod_security.c>
SecFilterInheritance Off
</IfModule>
Of course, you can pin-point your Apache targets only to apply that rule to certain files/folders using directives.
Some links that might help:
http://community.mybb.com/showthread.php?tid=7592
http://wordpress.org/support/topic/upgrade-to-22-dashboard-not-working
http://energy-4-3.com/uncategorized/mod_security-access-denied-with-code-403-pattern-match-http/
http://www.modsecurity.org/ (homepage)
Related
I have a simple custom MVC app using $_GET to parse a url, and i've got it working on my dev server as well as a few different webhosts using php 7.1... but I'm trying to use x10hosting's free lamp hosting and the data being passed from $_GET is coming through as 403...
I've proved that it works on other servers as well as my own dev server with this
echo '<pre>', $route->path, $_GET['url'], '</pre>';
when going to the url http://app/admin... this line in my loop gives me what should be expected...
/admin
adminadmin
but on x10's server i get this
/403.shtml
admin403.shtml
I have tried encoding to base64 with urlencode($_GET) as well as disabling mod_sec in the .htaccess with
<IfModule mod_security.c>
SecFilterEngine Off
SecFilterScanPOST Off
</IfModule>
neither solution worked... I'm almost certain it's a server config issue but access is pretty much limited to .htaccess and php.ini .... I haven't touched php or apache in a while and am a little lost... any help would be greatly appreciated
This does sound like a mod_security type issue. And, as you have found, you are unable to disable mod_security on the free hosting platform.
I have encountered mod_sec rules on a number of shared hosts that simply block the request based on certain parameter names (supposedly blocking common XSS attempts). url is a common one. site is another. Simply changing the parameter name might be all that's required.
"Free" hosting accounts are always going to have some restrictions. If this is the only thing that holds you back then you are lucky.
I am trying to create a new domain which runs on SilverStripe 3.0. I am unable to figure out the issue. If I upload a custom php page then it runs fine, but my website is not working. It shows blank page but shows the favico.
If I try to open up www.mydomain.com/admin/, I get the error
Page Not Found
The requested URL /admin/pages was not found on this server.
Additionally, a 404 Not Found error was encountered while trying to use an ErrorDocument to handle the request.
This is not a Silverstripe error page. Here is my php info Info
Please let me know if I am missing something or there is any way to figure out the issue.
Try www.yourdomain.com/index.php/admin
If that works then it is because your rewrites are not working. This can be because .htaccess isn't configured properly, or because .htaccess is not used at all (in which case you need to edit your server config).
Last I used Plesk it always used apache. If that is different now and you're using nginx as more than a forward proxy, then you will need to set up the redirects for your site manually.
It does sound like your .htaccess is not being respected. Does Plesk allow overrides for .htaccess in the local directory?
At an apache level we would have something like this stanza to ensure the the .htaccess of the project was respected;
AllowOverride All
If your .htaccess is being processed, make sure that your host has mod_rewrite enabled as that is required to access to pretty URLS.
I have a website on a lamp stack with little to no extra configuration other than FallbackResource /index.php present in my root .htaccess
When I load the root page (localhost ) in Chrome I receive
GET http://192.168.163.171/ net::ERR_INCOMPLETE_CHUNKED_ENCODING VM110:1
in the chrome console after about 10 seconds. If I attempt to follow the link at VM110:1 it takes me to the top of my inline Javascript.
More information / What I've tried
This does NOT occur on any other page but root
There are no 404's in the access log nor any other abnormal codes
There are no errors appearing in the apache error log.
The error does not occur in the latest version of IE or Firefox.
It caused a problem in both my local environment and hosted. The latter has absolutely no config changes and I expect to be a near default install.
When I remove the FallbackResource directive my page loads fine without the error
In index.php the root is treated no different than any other page.
This would all be a non-issue because everything loads properly BUT it prevents javascript relying on a finished page load from working.
Any further ideas on what is causing the problem or new things I can try? I've considered moving to just using mod_rewrite but this is much simpler.
Finally found the answer while working on another site:
Before FallbackResource directive be sure to add a DirectoryIndex directive with the same file. Haven't had time to research why but it fixed my issue. I blame it on a Chrome bug or possibly Chrome being super picky because no other major browser has an issue.
I fixed this error by removing the following lines from my php5filter.conf file in the Apache configuration:
<FilesMatch ".+\.ph(p3?|tml)$">
SetInputFilter PHP
SetOutputFilter PHP
</FilesMatch>
To add to Blaine's answer (as I can't yet comment):
I believe this is an Apache configuration issue, not specific to Chrome.
I recently experienced this issue, and noted the following effects in various clients, again only with the home page:
Chrome, as stated, displayed the ERR_INCOMPLETE_CHUNKED_ENCODING error, but also didn't display the page correctly. The page continued to "load" for another 5 seconds even after all the content was visible.
A simple CURL request outputted the error curl: (18) transfer closed with outstanding read data remaining. The full HTML appeared, followed by the error after a delay.
Firefox and IE initially displayed the page incorrectly, as with Chrome, and again had the ~5 second additional loading time. However, after this period, the page suddenly reformatted itself correctly. No errors were seen in the respective developer consoles.
The solution to set the DirectoryIndex to the same location as FallbackResource resolved this for all clients.
Edit: An alternative if using mod_rewrite is to use something like RewriteRule ^$ index.php which will avoid affecting all subdirectories.
I don't know whether this is expected behaviour of Apache or a bug.
In my json response '\n' causing the issue. So after removing it, issue has been solved.
I wrote a very simple Magento module that sends an email but doesn't use Magento's core emailing system. I'm using ajax to POST to email.php
I've tested this to oblivion in three separate environments: local, development, and staging. It works flawlessly on all three.
Now when I took these changes live on a fourth server, all post requests return the following:
POST http://mydomain.com/dir/path/email.php 403 (Forbidden)
And all post requests log the following to my error log:
client denied by server configuration: /var/www/vhosts/mydomain.com/httpdocs/dir/path/email.php, referer: http://mydomain.com/myCategory/myProduct
Everything appears to be exactly the same between the four servers. I've checked permissions and httpd.config as well as .htaccess files.
I can add the following to the /apps/.htaccess to get everything to work on live, however I can't keep it this way for obvious reasons.
<Limit POST>
order deny,allow
deny from all
allow from all
</Limit>
I thought there was a possibility that the magneto root .htaccess file could be the culprit but the staging and dev servers are clones of the live site.
Basically, I've checked everything I can think of on the server side of things. I'm completely perplexed as to why my module would work on three separate servers but not on the live site. Is there anything file related that could be causing this? Maybe firewall rules? The generic error in my log file is making this difficult to troubleshoot.
I believe I'm looking for the Apache setting or mod that accomplishes this behavior because I need to turn it off or alter it in some fashion. Here's the deal:
I have my own CMS that has its own router to handle redirects, includes, 404 errors, and pretty URLs. The mod_rewrite rules work perfectly to direct the appropriate requests to this router, but there's a strange case that causes Apache to freak out and never even send the request to the router.
File located at www.example.com/contact.form.php
CMS content located at www.example.com/contact/contact-us
Requests for the CMS content should be going to the router because it does not match a file or directory that exists in the file system. What is actually happening is some sort of bizarre request that finds the contact.form.php file but somehow still causes Apache to give its own 404 error.
The router is designed to catch 404 errors, so Apache's 404 screen should never be seen. All URLs entered for this domain outside of the contact "directory" (no matter how absurd) make it to my router and either retrieve the correct content or show my 404 page.
The work-arounds I've come up with so far:
Change the filename to form.contact.php -- which disables any CMS content that may eventually exist in www.example.com/form/...
Create an empty directory at www.example.com/contact/
The conflict is clearly tied to the "directory" name matching the first part of a PHP filename. This behavior exists any time this condition is met, and it is non-existent when it is not met. Unfortunately, with a CMS, I can never guarantee that "directory" names won't collide with PHP file names. For this reason, my focus is on tweaking Apache.
I've searched with all kinds of keyword combinations, and I can't find the answer anywhere. Any ideas?
Found the answer elsewhere after a lot of searching.
The problem is Options MultiView is turned on.
For me, I am using virtual hosts, but I am configuring most of my settings in the user.conf file for apache on Mac OSX Lion. I am not sure if I added this, or if it was already there...
Here is what I did
Open Terminal App
type: cd /etc/apache2/users
type: ls
From the list that prints out, you should see a file that matches your username: USERNAME.conf, where USERNAME is your actual username
type: sudo nano USERNAME.conf
You will probably have to enter your password
Find this line: Options Indexes MultiViews
Change it to: Options Indexes
ctrl+x to exit, hit "y" when prompted to save the file and enter when it asks about the filename
Alternatives
You can add Options -MultiViews if you don't see anything there.
Also you can edit your httpd.conf file if the above does not apply.
And if you use virtual hosts, you can edit your httpd-vhosts.conf file. For each site, edit the MultiViews Option within the tags. Either by adding "Options -MultiViews" or removing "Options MultiViews" if it exists.
Hope this helps somebody else...