url params not allowed to pass

[AITpro Admin]

Yes, having a Referer other than the Host site in the Query string would definitely trigger BPS to block the Query string if it mimicked an RFI hacking attempt.

Classic RFI hacking attempt example:  example.com/file2.php?src=http://hacker-site.com/hack-the-site-with-RFI.php

If another Referer is in the Query string or if the file is being called from another Referer other than the Host site then this would definitely be a factor. One of the primary hacking methods that BPS is designed to protect against is RFI.

[Patrick]

I took the most straightforward approach and altered the htaccess inside that specific directory, commenting out the old stuff (I didn’t create) and adding the “RewriteEngine Off” line. It seems to have fixed the issue. I will continue poking around with it and get back with any curiosities.

[AITpro Admin]

Ok so at this point if it were me what I would do is create a customized .htaccess file for this 3rd party app or whatever else it is if it just a stand alone Form of some kind.  I would take the root .htaccess file, edit it to work for this app or Form and then copy it into the folder where this app or Form exists.  In order to do this an index file also would need to exist/be created in that folder.  It can be either a blank php index.php file or a blank HTML index.html file.  You would need to manually create the correct RewriteBase and RewriteRules and then what I would do is comment out the entire BPS Query string exploits code except for this code:

RewriteCond %{QUERY_STRING} (sp_executesql) [NC]
RewriteRule ^(.*)$ - [F,L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]

Then I would uncomment the Query string exploits code in groups of 3’s until the exact security filter that is blocking whatever is being blocked is located.  Once you find that rule or rules then leave them commented out in that custom .htaccess file.

[Author]

Posts