[Plugin: BulletProof Security] Bulletproof and dsIDXpress plugin

Yes, BPS will block this Query string.
%3C is <
%3E is >

These are script tags and will be seen as a threat.
what is odd about this Query string is that when you translate it from ASCII it looks like this, which is very strange looking query string and also totally unsafe. You should contact them to change this.

?idx-d-SortOrders<0>-Column=

In the meantime if you want to allow this Query string on your website, which i obviously do not recommend then you would need to modify this security filter in your root .htaccess file and remove the < and > characters and the ASCII equivalents %3c and %3e. You may need to do this for the HTTP_REFERER security filter and the HTTP_USER_AGENT security filter if for some reason these are still blocking the script tags.

RewriteCond %{QUERY_STRING} ^.*(\[|\]|\(|\)|<|>|%3c|%3e|%5b|%5d).* [NC,OR]

Unsafe:

Characters can be unsafe for a number of reasons. The space
character is unsafe because significant spaces may disappear and
insignificant spaces may be introduced when URLs are transcribed or
typeset or subjected to the treatment of word-processing programs. The characters “<” and “>” are unsafe because they are used as the
delimiters around URLs in free text; the quote mark (“””) is used to
delimit URLs in some systems. The character “#” is unsafe and should
always be encoded because it is used in World Wide Web and in other
systems to delimit a URL from a fragment/anchor identifier that might follow it. The character “%” is unsafe because it is used for
encodings of other characters. Other characters are unsafe because
gateways and other transport agents are known to sometimes modify such characters. These characters are “{“, “}”, “|”, “\”, “^”, “~”, “[“, “]”, and “`”.

Source: https://stackoverflow.com/questions/726662/what-characters-are-unsafe-in-query-strings

Thanks for the quick reply. I tried what you suggested, removing the two ascii codes as you indicated. For the record, now the rewrite condition looks like this:

RewriteCond %{QUERY_STRING} (;|<|>|’|”|\)|%0A|%0D|%22|%27|%00).*(/\*|union|select|insert|drop|delete|update|cast|create|char|convert|alter|declare|order|script|set|md5|benchmark|encode) [NC,OR]

Here’s what’s happening with the .htaccess change. I get page-2 of results now, but without the style sheet or page graphics — it isn’t recognizing the CSS file or any of the images on the page. I checked the source and the links are absolute and correct so there should be no trouble loading the items but it’s not. Then when I go to page-3 by hitting the Next button again, I get the same result as before — a 500 error and a page not found message.

Here’s the url the plugin is trying to load to get to page-3:
https://domain.com/idx/city/dover/page-3?idx-d-SortOrders%3C0%3E-Column=DateAdded&idx-d-SortOrders%3C0%3E-Direction=DESC

To me, it seems like the .htaccess change I just did should take care of this string as well as the page-2 string but maybe I’m missing something.

That said, the site is broken in terms of listing navigation, so if I can’t get Diverse Solutions to make the change (unlikely that they’ll be able to do it quickly, if they can at all), then I might have to disable Bulletproof which I am reluctant to do. So hopefully we can get BPS to make this exception for the short term and load the site’s listings pages.

Thanks again for your help with this.

You posted the SQL Injection security filter and not the Dangerous Query String security filter. I assume that you meant to paste the other modified security filter? The SQL Injection filter would Not need to be modified because it is a 2 part security rule and would not block your Query string.

Ok, I did this incrementally — changed the SQL Injection filter back (is that’s what that’s called ?? and then deleted the %3C and %3E codes from the rewrite condition you referred to above. Didn’t work. So I went back and deleted those codes from the rewrite conditions for HTTP_USER_AGENT and HTTP_REFERRER and then it worked. So that’s a relief. Thanks for helping me with that.

I’ve written to support at DS, the IDX plugin developers, and hopefully they’ll make changes in a future release so we can use the plugin without sacrificing security.

thanks again, we’re all set here.

Yep i think the 2 security filters that are going to block that Query string are just the HTTP_REFERRER and QUERY_STRING security filters. I doubt that the HTTP_USER_AGENT security filter would be blocking the query string, but i have not looked at the coding of that plugin so i am not sure how the string is handled/created/etc.

Yep having them change the query string that is generated using the safest possible coding practices is of course the optimum end result. ??
Thanks.