Viewing 8 replies - 1 through 8 (of 8 total)
  • Plugin Author AITpro

    (@aitpro)

    I think this has to do with the OAuth Token. I am looking at the coding of this plugin now and it looks like it will require more than just a standard quickie fix.

    Ok i see the filter that is blocking this plugin and why and this filter will need to be defined a little more. Currently it is a bit too general.

    Anyway here is what you need to do for now. In both your Root .htaccess file and your wp-admin .htaccess file….

    change this security filter…

    RewriteCond %{QUERY_STRING} ^.*(\[|\]|\(|\)|<|>).* [NC,OR]
    
    to this...
    
    RewriteCond %{QUERY_STRING} ^.*(\[|\]|<|>).* [NC,OR]

    Plugin Author AITpro

    (@aitpro)

    Actually I decided not to define this security filter any more because really all of these characters should not be used in a Query String so leaving this generalized as it is is fine.

    Typically with Non <SCRIPT> Events and JavaScript Entities types of hacking methods, hackers can insert an exploit string by using the left square bracket and right square bracket characters in a Query String. Luckily removing just the left parenthesis and right parenthesis is still very safe because the hacker would need to use a combination of characters that would include the greater-than and less-than characters so it is completely safe to just remove the parenthesis characters. I may decide to remove the parenthesis characters altogether at a later date, but this requires further investigation.

    In summary, it is completely safe to remove the parenthesis characters from this Query String security filter.

    Thread Starter mayday

    (@mayday)

    Thank you! That fixed my plugin.

    Plugin Author AITpro

    (@aitpro)

    And most importantly your website is just as secure as it was before. ?? Thanks for the confirmation.

    Also just an FYI – the BPS security filters contain a lot of redundancy because they have been put together with the forethought that along the way an exception or mod to the security filters may need to made here and there for other plugins. The overlap in security filters minimizes the range of possible vulnerabilities if an exception needs to be made.

    Plugin Author AITpro

    (@aitpro)

    And this is the new security filter that will replace this filter. It is still undergoing testing, but it looks good so far. ??

    RewriteCond %{QUERY_STRING} ^.*(\[|\]|\(|\)|<|>|\x3c|\x3e|%3c|%3e|\x5b|\x5d|%5b|%5d).* [NC,OR]
    Plugin Author AITpro

    (@aitpro)

    And actually we will be doing this instead.
    Keeping the Anti-XSS filters separate.

    Anti-XSS-ASCII filter
    Anti-XSS-Hex filter

    RewriteCond %{QUERY_STRING} ^.*(\[|\]|\(|\)|<|>|%3c|%3e|%5b|%5d).* [NC,OR]
    RewriteCond %{QUERY_STRING} ^.*(\x00|\x04|\x08|\x0d|\x1b|\x20|\x3c|\x3e|\x5b|\x5d|\x7f).* [NC,OR]

    Thread Starter mayday

    (@mayday)

    You are doing great work here. Have you looked at the efforts and the posts over at Perishable Press? Doing a similar thing with htaccess file oriented towards WP.

    Plugin Author AITpro

    (@aitpro)

    Yep I have looked at the Perishable Press site and see that their focus is more on UA filtering, blocking, etc. I tend to avoid that security route because I have a huge collection of hackers scripts that i study and research and the majority of them contain coding that completely hides their true GEO location or any other identifying UA info. Typically with timer coding, which changes their UA and GEO info every X seconds. So basically they can appear to be in China 1 second and the next second be in Antartica. LOL So i tend to be more in favor of taking the “action” approach. X does this bad action and Y is the result = Forbidden. ??
    I have not looked at their site for quite a while so things might have changed since the last time i visited.

Viewing 8 replies - 1 through 8 (of 8 total)
  • The topic ‘[Plugin: BulletProof Security] Google Analytics Dashboard plugin not working’ is closed to new replies.