WordPress.org

Ready to get started?Download WordPress

Forums

BulletProof Security
[resolved] Bulletproof and dsIDXpress plugin (6 posts)

  1. BrattDev
    Member
    Posted 1 year ago #

    I have two sites that use the dsIDXpress premium MLS listing plugin. Everything is fine except the Next/Previous navigation buttons on the listings pages. What happens is that the first time you click Next, you get the page. And then when you click the Next button to go to page 3 (or the Previous button to go back to page 1) you get a 500 Error saying the requested url doesn't exist and that a 500 internal server error was encountered. The problem is recent but I couldn't tell you exactly when it cropped up (last month or so, nearest I can tell).

    I'm trying to ascertain if this is a Bulletproof issue or a dsIDXpress issue.

    The url is virtual -- there is no such directory on the server but dsIDXpress uses the url to call up data. The url contains the following string, or similar, for all page requests. The city name varies, obviously:

    http://domain.com/idx/city/dover/?idx-d-SortOrders%3C0%3E-Column=DateAdded&idx-d-SortOrders%3C0%3E-Direction=DESC

    Is there anything about this that sounds like it could be Bulletproof-related? Another problem is that even when navigating to a new page on the site, the error persists across pages until you refresh the browser.

    Thanks for any insight you might have.

    http://wordpress.org/extend/plugins/bulletproof-security/

  2. AITpro
    Member
    Plugin Author

    Posted 1 year ago #

    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: http://stackoverflow.com/questions/726662/what-characters-are-unsafe-in-query-strings

  3. BrattDev
    Member
    Posted 1 year ago #

    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:
    http://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.

  4. AITpro
    Member
    Plugin Author

    Posted 1 year ago #

    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.

  5. BrattDev
    Member
    Posted 1 year ago #

    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.

  6. AITpro
    Member
    Plugin Author

    Posted 1 year ago #

    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.

Topic Closed

This topic has been closed to new replies.

About this Plugin

About this Topic

Tags

No tags yet.