URL download links - Suspicious Core Parameter

[treat2day]

Can you tell me if this is just a bad actor/spammer or some other issue with jDownloads database.

I get several hundred of these daily.

This is one of the most frequent URL logged.

Link example:

index.php?option=com_jdownloads&view=%28SeLeCt%2F%2A%2A%2F%28CHr%28113%29%7C%7CCHr%28122%29%7C%7CCHr%28107%29%7C%7CCHr%28122%29%7C%7CCHr%28113%29%29%7C%7C%28 ... (rest part removed by admin)

Admin Tools blocks Suspicious Core Parameter

Explained here:

https://www.akeeba.com/support/admin-tools/40048-some-links-are-blocked-suspicious-core-parameter-cloaking.html#p217576

You are misunderstanding how URLs work. Let's take this URL here:

index.php?option=com_content&view=article&id=135&catid=2&lang=en-GB?ml=0&tmpl=template

The FIRST question mark – and ONLY that – separates the URL path from the URL query. Therefore the URL path is index.php and the URL query is option=com_content&view=article&id=135&catid=2&lang=en-GB?ml=0&tmpl=template

Let's break the URL query down into parameters and their values, remembering that URL parameter names are on the left of the equals sign, values are on the right hand side of the equals sign, and that key-value pairs are separated by ampersands (&), NOT BY QUESTION MARKS:

    option=com_content
    view=article
    id=135
    catid=2
    lang=en-GB?ml=0
    tmpl=template

Do you see the problem? It's in the lang parameter which I marked with red for you. Its value IS NOT en-GB as you mistakenly think. It is en-GB?ml=0. The lang parameter must also conform to the CMD filter which, as a reminder from our previous conversation, consists of lower- and upper-case characters a-z without accents or diacritics, numbers 0-9, dashes, underscores, and dots.

Since the actual value, which I remind you is en-GB?ml=0, has a question mark and an equals sign it is invalid. These characters do not conform to the CMD filter.

Therefore, Admin Tools is correct in blocking this request.

And yes, the Block Suspicious Core Parameters feature was only added in the last update which is why you only now see it. However, this does not change the fact that the URL was broken before and did not work the way you thought it does.

The question is, what kind of broken software generated this very broken URL? I can tell you it is neither Joomla! itself, nor any of our software. This smells of the work of an amateur, who took the current URL and naïvely appended ?ml=0&tmpl=template to it because they only ever tested their software on sites with SEF URLs enabled, and with page URLs which never had any URL parameters appended to them. Understandable rookie mistake, but this approach will never work right.

The proper way to do it is parse the current URL using Joomla\Uri\Uri, e.g.

$uri = clone \Joomla\CMS\Uri\Uri::getInstance();
$uri->setVar('ml', 0);
$uri->setVar('tmpl', 'template');
$correctUrl = $uri->toString();

That's the correct way to do it. Another working variant (which I've done when using Uri is too computationally expensive) is to check for the existence of a question mark, e.g.

$correctURL = \Joomla\CMS\Uri\Uri::getCurrent();
$correctURL .= (str_contains($correctURL, '?') ? '&' : '?') . 'ml=0&tmpl=template';

The latter method also works in client-side (JavaScript) code, which is something I have definitely done before as I didn't want to go through the server.

Find the problem software and contact its developer with the information I included in this reply so they can fix their software. Ignoring problems is not the right way to go about it. Problems must be fixed at their root.

[Arno]

Hi,
I will take a closer look, but unfortunately it will take a while.   

But it appears to be a normal SQL injection attack. However, jDownloads has no influence on this and is also not the cause.