Clearing Filter list causes SQLiShield blocking with Akeeba Admin tools

[p38]

Can anyone perhaps tell me how to get around this.......

I have Akeeba admin tools in place, and when a user clears the filter in a list, after 10 subsequent filter clear's, the user gets blocked: reason SQLiShield

Here is the url
/index.php/incidents-textsep/closed-incidents?resetfilters=0&clearordering=0&clearfilters=0

I have setup Akeeba rules to block any hacker after 10 attempts in 15mins, so if the user clears teh filter 10 times in 15mins, it gets blocked.

Anyway around this problem?

Paul

 

[cheesegrits]

Which site / list?

Our filter submissions do contain minimal amounts of SQL, like the condition (and, or) and the comparison (contains, like), and the key (`table`.`field`). So it's likely that the SQLiShield rules are interpreting those as an injection attack. Not much we can do about that, you'll have to figure out how to either tweak Akeeba's rule sets, or turn it off.

-- hugh

 

[cheesegrits]

I've asked Akeeba for a Pro license so I can test it.

-- hugh

 

[p38]

Thanks Hugh,

This used to work Ok, until I updated to latest Akeeba Admin Pro, as well as Fabrikar.

So between the 2 extensions, either Akeeba has become stricter in the rules, or Fabrikar clearing filter has changed something.

For now, I switched off SQLiShield and it works fine, but would prefer not to, as this is key in protecting all my fabrikar sites.
Looking at the exception logs, this type of hack attack happens a lot across all my sites so SQLiShield block is vital.

Paul

 

[cheesegrits]

It would have only started happening with Akeeba Admin Pro, as the freebie doesn't have the Application Firewall, which is what SQLiShield is part of.

Akeeba just this minute responded, so hopefully I'll be able to talk the in to giving me a copy I can test with.

-- hugh

 

[cheesegrits]

OK, I have a copy. Unfortunately I gave in and purchased a copy about an hour before they got back to me again. But it'll be useful to have anyway.

I'll find some time to play with it soon.

Hugh


Sent from my HTC One using Tapatalk

 

[p38]

Thanks Hugh, let me know if you need anything.

 

[p38]

Hi Hugh, any luck yet.

Further to this, I just had my service provider blocking my IP due to this url being marked as brute force hacking attempt. They have a default of 20 attempts in 1 minute. If this is teh case I would need to call the url every 2.5 seconds which is next to impossible

/administrator/index.php?option=com_fabrik&view=form&layout=edit&id=90

I was doing a fair amount of editing in administrator backend.

Now I have been using Fabrik for over 6 years now extensively on all development, and these issues have only started appearing when I updated Fabrik to latest, with latest Joomla version.

Any idea why this would be.

Here is my server log item.
- [15/Jan/2016:00:31:34 +0200] "POST /administrator/index.php HTTP/1.1" 200 1043 "/administrator/index.php?option=com_fabrik&view=form&layout=edit&id=90" "Mozilla/5.0 (Windows NT 10.0; WOW64; rv:43.0) Gecko/20100101 Firefox/43.0" 825 1558

 

[cheesegrits]

Nope, haven't had time to work on it yet, been kinda swamped with the 3.4 release, etc.

I suspect that's the AJAX loading of the various plugins. We haven't changed anything in the way the backend loads. We fire off an AJAX call to load each form plugin, plus additional AJAX call to initialize things like dropdowns of element lists, etc.

http://screencast.com/t/LdKXMbNzG

As you can see, that index page gets hit about 8 or 9 times during the page load, and they are all POST requests with the same query string as the main page load.

So if you have a few plugins, and you load a form edit page and save it a few times in quick succession, it'd be very easy to rack up 20 hits in a minute.

I had a similar issue with the standard firewall WHM uses on our main fabrikar.com site - not just for Fabrik pages, but with other AJAX heavy admin tasks as well - and I had to whitelist the J! backend.

Bottom line, it's not us changing, it's just hosts tightening up security, which is a Good Thing <tm>, but it does mean you occasionally have to tweak any overly aggressive rules in the application firewall. Or the firewall vendors need to better recognize XHR requests that are obviously part of a page load, not distinct page loads.

-- hugh

 

[p38]

Thanks hugh for a perfectly valid and concise explanation, much appreciated.

I will put the ball back in the hands of my hosting provider, I suspect they may have tightened up security recently.

Paul