Support

Admin Tools

#28151 Blocked GET parameters

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 n3t.cz on Monday, 24 July 2017 17:11 CDT

n3t.cz
Hello,

I found some of request are blocked based on GET parameters. Blocking rule is default list[select] rule, which is automatically installed when admin tools are installed, however seems that the rule is misinterpreted. Blocked are addresses like (weth SEF off)

/index.php?option=com_content&view=article&id=1:test&catid=2&Itemid=101&6
but not
/index.php?option=com_content&view=article&id=1:test&catid=2&Itemid=101&a6

Note the las GET parameter without any value, this is causing the block. If list[select] is disabled, requests are not blocked. If I understand well, the rule should check only list[select] GET parameter, so should not block such requests.

I attached screenshot of the rule, however as I noted, it is ruled automatically installed by clean Admin Tools installation.

best regards

Pavel

PS: I tried to search tickets before posting this one, but on yur new website search does not seem to work (see https://www.akeebabackup.com/search.html?q=admin)

n3t.cz
Forgot to attach Log file:

-------------------------------------------------------------------------------
Blocking reason: wafblacklist
-------------------------------------------------------------------------------
Date/time : 2017-07-20 11:26:20 GMT
URL : http://****/index.php?option=com_content&view=article&id=1:test&catid=2&Itemid=101&6
User : Guest
IP : 212.67.69.245
Country : (unknown country)
Continent : (unknown continent)
UA : Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/59.0.3071.115 Safari/537.36
Hash : POST
Variables :
Array
(
[option] => com_content
[view] => article
[id] => 1:test
[catid] => 2
[Itemid] => 101
[6] =>
[_ga] => GA1.2.410194759.1452789515
[7a6ab2aabeb0af19d3a430edc056c892] => en-GB
[c78b3442b4ea1fa75e6f30e1678a3d9a] => a0606c149eb90d751681d4478e7caa64
[cdccfaecd114f5f7eea0cd32ca6f3562] => 08345b10eb0be862a70261f9de089fcf
[0] =>
)

nicholas
Akeeba Staff
Manager
I am going to take a look at this. This week I am alone here due to summer vacations. Due to a rather high number of tickets requiring developer oversight it will take me much longer than usual to clear the queue. Please expect a reply to your ticket within a 3-5 working days.

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!

n3t.cz
Thank you. I temporarily disabled that rule, if I understood well, it was targeting security issue in older Joomla version, 3.7.3 should be secured for this, correct?

Pavel

nicholas
Akeeba Staff
Manager
Yes, you do not need this rule in Joomla! 3.7. You can safely disable it.

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!

nicholas
Akeeba Staff
Manager
The problem is the &6 at the end. I have no idea why that ends up in your URL. It creates a query string parameter with a key of (integer) 6 and null value. This is obviously a typo.

When Joomla! processes the request it figures out that this kind of parameter has no place. Unfortunately, what it does is worse. It creates a query string parameter with key '' (empty string) and null value. And because we're heading to a perfect storm, when we are getting the query string parameters as an array PHP converts the empty string to the integer value 0. Continuing on our perfect storm, PHP treats the string literal 'list[select]' as being equal to the integer value 0.

Are you still with me? Due to some Joomla! and PHP quirks that lone 6 at the end of the URL is considered to be an exact match to list[select]. Of course at this point we have to compare its value (null) against the regular expression assigned to this blacklist rule. The regular expression is to the tune of "if it doesn't contain X or Y raise an alarm". Since the value is null this negative regular expression matches. Hence the blocked request.

After two hours and half a bottle of cola I can tell you that I have figured out why this happens and found a way to work around it. When the ticket system reopens on Monday please do tell me how the heck was that URL generated because that freaking lone 6 at the end is most definitely NOT right (and the source of all our problems). Kindly note that tomorrow I'll keep the ticket system closed as I need to go through the developer-level ticket backlog, something I've been trying to do the last 2 days (only that it kept growing faster than I could chop it down).

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!

n3t.cz
Hi,

I used the 6 just as an example, simplified to minal to make things more obvious. Real URLs were with longer number (but always just number), and propably added by some kind of Cache Breaker. I mentioned 2 occasions, where first one is some kind of error, and second one is some kind of search engine query.

1/ In administration. There were incorrect URLs, propably created by JCE Media manager (however I am not able to emulate it, still waiting description from end useres, how they were able to achieve it). The URL was pointing image, but was incorrectly encoded, so it looks like /images/my-image.jpg%3Fabcdefg?123456 - this leads correctly to 404 error, however Admin Tools blocked it by the rule above as hack, so those authors were very fast blocked by IP.

2/ I also found that some search engines tried to access the web with this kind of addition. They just add this paramatere to URL, propably some kind of encoded time, propably to break the Cache. Again, this leads to blocking IP address of such serach engine (even it was legal search engine).

Pavel

nicholas
Akeeba Staff
Manager
Adding arbitrary numbers to the end of URLs is not supported by Joomla!. The JInput class does not expect to see numeric parameters. It's a case not covered so when a numeric parameter with no value is used everything falls apart in interesting ways. Well, at least the next version of Admin Tools will have a workaround against misbehaving search engines which are acting more like penetration testing software than indexing services, but I digress :)

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!

n3t.cz
Thanks for your time and help. You are right, that search engine is not acting correctly, however it is imprtant search engine for us, so we have to accept it :/

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!