Support

Admin Tools

#28336 Custom API requests to our server are classed as attacks and IPs blocked under SQLi Shield

Posted in ‘Admin Tools for Joomla! 4 & 5’
This is a public ticket

Everybody will be able to see its contents. Do not include usernames, passwords or any other sensitive information.

Environment Information

Joomla! version
n/a
PHP version
n/a
Admin Tools version
n/a

Latest post by bizhanr on Thursday, 31 August 2017 11:55 CDT

bizhanr
Hi,

Our Joomla installation runs a custom API server(its handled by a custom component we built) for our custom WP plugins. So all the sites which has our plugin installed contacts our Joomla site via our custom API.

But Admin tools blocks these IPs regularly under SQLi shield. Adding individual IPs to while list is not possible as we will have hundreds of clients connecting from their WP plugin installations and disabling SQLi shield is not preferred as then we are remiving an important protection mechanism.

So please let me know:

1. What in the APIs might be triggering Admin tools to block the IP address? Is there a log or something which I can have a look at to see what exactly caused the IP to be blocked?

2. We are open to do any changes in our custom API so that the admin tools do not block the IPs of our customers. What changes we have to make to accomplish this?

Thank you

tampe125
Akeeba Staff
Hello,

you can review the blocked URL in the Security Exceptions page.
If the params triggering the SQLi Shield protection are inside the POST array, you can review the detailed log inside the log folder. There is a file named admintools_breaches.log, there you can find all the params that are contained inside the request.

Davide Tampellini

Developer and Support Staff

🇮🇹Italian: native 🇬🇧English: good • 🕐 My time zone is Europe / Rome (UTC +1)
Please keep in mind my timezone and cultural differences when reading my replies. Thank you!

bizhanr
Hi,


I have analyzed the log and it looks like a big plugin log in POST that we sent from our plugin to Joomla site is the one that is getting blocked. Please let me know:

1. If we base64 encode the log string, will it be blocked? Although I am not in favour of this as the POST is already very big.
2. Can we send this big plugin log string as a file so that it is not blocked?
3. Is it possible that the length of the POST is triggering SQLi Shield?

Thank you.

nicholas
Akeeba Staff
Manager
1. Nope, it won't. The SQLiShield tries to match what looks like SQL code inside any parameter submitted through POST, GET, PUT etc. I'd recommend compressing the log and then encoding it. This will result in a much smaller log POST anyway.

2. Yes. File uploads are not query parameters, therefore are not scanned by SQLiShield.

3. No. The SQLiShield is just a (very complex) regular expression.

Nicholas K. Dionysopoulos

Lead Developer and Director

🇬🇷Greek: native 🇬🇧English: excellent 🇫🇷French: basic • 🕐 My time zone is Europe / Athens
Please keep in mind my timezone and cultural differences when reading my replies. Thank you!

tampe125
Akeeba Staff
Just a little addition to Nicholas answer:
Before changing the whole plugin logic, I'd suggest you to take a look at the WAF Exceptions page. Since you have your own plugin, you can easily whitelist a specific task of your component, so SQLi Shield (and other features) are turned off.
In this way you won't have to rewrite and deploy a new version of your plugin on all your customers.

Davide Tampellini

Developer and Support Staff

🇮🇹Italian: native 🇬🇧English: good • 🕐 My time zone is Europe / Rome (UTC +1)
Please keep in mind my timezone and cultural differences when reading my replies. Thank you!

bizhanr
Hi,

Thanks for the suggestions. After looking at all the options mentioned, we have decided to send logs as files instead of POST.

Thank you so much for help.

Support Information

Working hours: We are open Monday to Friday, 9am to 7pm Cyprus timezone (EET / EEST). Support is provided by the same developers writing the software, all of which live in Europe. You can still file tickets outside of our working hours, but we cannot respond to them until we're back at the office.

Support policy: We would like to kindly inform you that when using our support you have already agreed to the Support Policy which is part of our Terms of Service. Thank you for your understanding and for helping us help you!