Plugin Author
AITpro
(@aitpro)
Yes, the single quote coding character/Apostrophe is the most dangerous coding character there is. It is used in many different types of hacking methods. BPS blocks the single quote character in several different security filters since it is the #1 MOST dangerous hacking coding character using in hacking attempts.
Here are your options:
You can either decide not use the single quote character in search strings or you can modify these security filters in your root .htaccess file to allow the single quote character.
You would remove %27 from these security filters below and also remove the single quote coding character in the QUERY_STRING filter.
RewriteCond %{HTTP_USER_AGENT} (%0A|%0D|%27|%3C|%3E|%00) [NC,OR]
RewriteCond %{HTTP_REFERER} (%0A|%0D|%27|%3C|%3E|%00) [NC,OR]
RewriteCond %{QUERY_STRING} (<|>|'|%0A|%0D|%27|%3C|%3E|%00) [NC,OR]
Thanks for the quick reply!
Is it possible to allow the single quote ‘ and dot . (which is also blocked on Events Manager’s searches, though not on the site general search), only for specific URL structures?
Does it matter to which custom code section would I paste this code to make the exception update-safe?
Plugin Author
AITpro
(@aitpro)
Unfortunately, I believe it is an “all or nothing” thing. With that said post an exact example of what you would like to try and whitelist and I will tell you if that is possible and then post the whitelist rule if that is possible.
Plugin Author
AITpro
(@aitpro)
What is curious to me is why Event Managers search feature is not stripping out or sanitizing the single quote? That would be the safest approach.
Plugin Author
AITpro
(@aitpro)
A simple string replace or preg_replace in the search feature would do this such as…
if preg_match “list of dangerous coding characters”
// then do X sring replace or preg_replace the single quote with blank
str_replace blah with nothing
or
preg_replace blah with nothing
Plugin Author
AITpro
(@aitpro)
The last coding character that you want sent in a query to your database is the single quote code character. SQL Injection hacking attempts always use the single quote code character to hack your database. When you perform a search you are querying/searching your database.
An example where the user searches for Ed’s Band: http://demo.wp-events-plugin.com/events/?em_search=ed’s&town=&action=search_events
They don’t run BPS, at least not the default secure .htaccess file, so that search doesn’t return error message there. On our site runs BPS secure .htaccess and the corresponding search URL returns a 403 error. We’re getting user complaints for a search they consider broken.
Our users need to be allowed to search for any character in the two-three search boxes that we show in the UI without being shown 403 errors. The proper handling of all input values needs to be done without error messages to user, apart from the occasional “no search results found”. In this case Events Manager needs to sanitize the input before running it against the database or displaying it on their HTML (I noticed a slight problem regarding the latter, informing them).
Plugin Author
AITpro
(@aitpro)
Oh ok then if the URLs are coming from an external source that is not sanitizing/making URL’s safe then that is a different matter.
And to make things less complicated for you just modify the BPS security filters as I mentioned above. There are overlapping layers of security filters in BPS so your site is still protected against SQL Injection attacks primarily with this specific SQL Injection security filter below so it is really not a big deal to modify the other security filters above. My hope is always that other folks will apply/create the highest possible security measures when processing data/outputting strings/etc, but that is not always the case or not possible or for other personal reasons.
RewriteCond %{QUERY_STRING} (;|<|>|'|"|\)|%0A|%0D|%22|%27|%3C|%3E|%00).*(/\*|union|select|insert|drop|delete|update|cast|create|char|convert|alter|declare|order|script|set|md5|benchmark|encode) [NC,OR]
Thanks for the info and support. The way I believe we can guarantee the best user experience is:
1. The search URLs that we use accept any characters in them and pass them on to WP.
2. The applications handling the input of those specific URLs sanitize the input as necessary.
3. If BPS has a security enhancement, eg. a filter, that affects WP’s DB operations instead of URLs, I’d do further testing that it doesn’t disallow any valid searches.
I’ll check with Events Manager team and the theme team that the inputs are sanitized appropriately. http://www.joellipman.com/articles/web-development/503-basic-tests-for-sql-injection-vulnerabilities.html is a good checklist.
What’s the correct Custom Code rule to add to BPS to ensure that these three
domain/search/?*em_search=*
domain/locations/?*em_search=*
domain/?s=*
don’t trigger a 403 alert for *updated*: any of these characters inside the query parameters:
‘<>
Plugin Author
AITpro
(@aitpro)
Yikes that is a scary query string! LOL
Ok let me just rephrase what I said in a way that makes everything really simple – The BPS security filters are designed to have many different layers and are also designed in a way that if you have to remove/modify/edit some security filters then you will still always be protected.
In a nutshell – we start from the maximum security possible and have already factored in that less important security filters will be removed/commented out/edited/modified on case by case basis for personal reasons. This primary security filter below will never and has never needed to be modified in any cases over the years because it is so focused/targeted on an exact hacking/attack pattern/method. If you remove/edit/delete/comment out/modify top level/general security filters then this security filter is the primary security filter/fallback.
RewriteCond %{QUERY_STRING} (;|<|>|'|"|\)|%0A|%0D|%22|%27|%3C|%3E|%00).*(/\*|union|select|insert|drop|delete|update|cast|create|char|convert|alter|declare|order|script|set|md5|benchmark|encode) [NC,OR]
I understand that limiting those characters in a URL is a good shortcut on filtering certain attacks, but we need to have a way to allow users to search for anything they want and get all the related results. The security needs to be handled at a different level than blocking valid search URLs.
As Events Manager escapes the inputs it receives from its own search URLs, it should be secure enough to bypass the above security filter for the URLs for EMs searches (but to let it activate for other URLs).
What do you think, can such an exact exception be made?
In addition to the previously mentioned chars, also “..”, two consecutive dots, has caused unwanted error messages.
Plugin Author
AITpro
(@aitpro)
Ok let’s try this again. 😉
If you modify these filters then all problems are solved. The site is still protected against SQL Injection attacks. External URL’s using unsafe coding characters in the URL’s will not be blocked. Users can use unsafe coding characters in searches and they will not be blocked. The Primary SQL Injection security filter will block actual hacking attempts that are attempting to exploit the search feature – all problems are solved by modifying the security filters below.
You would remove %27 from these security filters below and also remove the single quote coding character in the QUERY_STRING filter.
RewriteCond %{HTTP_USER_AGENT} (%0A|%0D|%27|%3C|%3E|%00) [NC,OR]
RewriteCond %{HTTP_REFERER} (%0A|%0D|%27|%3C|%3E|%00) [NC,OR]
RewriteCond %{QUERY_STRING} (<|>|'|%0A|%0D|%27|%3C|%3E|%00) [NC,OR]
The .. pattern is used in Directory Traversal hacking methods against websites.
The security filter that you would comment out would be this one.
RewriteCond %{QUERY_STRING} (\.\./|\.\.) [OR]
The fallback is this security filter
RewriteCond %{QUERY_STRING} (\./|\../|\.../)+(motd|etc|bin) [NC,OR]
NOTE: The fallback security filter above is pending new additions to include additional new targets.
Thanks!
Is there a way to disable these in an update-safe way, for example in Custom Code?
Plugin Author
AITpro
(@aitpro)
These are primary/base/standard BPS security filters so you would not be adding them to Custom Code and would simply just modify the root .htaccess file directly.
When installing a BPS upgrade/update/new version of BPS the automatic htaccess file update does not replace/change/modify any custom modifications that you have made to your root .htaccess file. Since you are making custom modifications to the standard BPS security filters then it is recommended that you also use the BPS built-in .htaccess Backup feature so that you have backup copies of your custom modified .htaccess files and can restore them using the BPS built-in .htaccess file Restore feature if necessary.
