False alerts "Invalid idSite: '0'" when someone tries to SQLi this parameter

[Seb35]

Context

On a website where Matomo is correctly configured, some attackers try to find vulnerabilities by sending requests like:

/piwik.php?idsite=1%27%20AND%20EXTRACTVALUE%283565%2CCONCAT%280x5c%2C0x7162706271%2C%28SELECT%20%28ELT%283565%3D3565%2C1%29%29%29%2C0x71766b6b71%29%29%20AND%20%27KCzU%27%3D%27KCzU&rec=1&bots=1

which is obviously an attempt of SQL injection (SQLi).

Current Behaviour

Given the parameter idsite is sanitised and converted to an integer (and 0 in case of error), this type of request is interpreted as a tracking error labelled "The site does not exist.".

On one website I am managing (20k visits/day), it is triggered about once a day (since it is de-duplicated, actual access logs show the attackers try sometimes 30 different SQLi requests).

Expected Behavior

Matomo administrators should not be warned (at least not this way) of these "tracking errors" since it is out of their control: it is a 400 Bad Request from the (malicious) user (see #6661).

Possible Solution

Try to detect these "false alerts", it has to be discussed how to characterise them. It can be for instance:

1. presence of parameter idsite but resulting idsite is 0,
2. non-empty parameter idsite but resulting idsite is 0,
3. non-numeric parameter idsite,
4. the parameter idsite contains "AND" or "SELECT" or "ORDER" (some common SQL words).

I think the 4th solution is the more robust to catch SQLi and at the same time keep the effectiveness of the warning for real misconfigurations.

Steps to Reproduce (for Bugs)

1. Call the endpoint /piwik.php?idsite=1%27%20AND%20EXTRACTVALUE%283565%2CCONCAT%280x5c%2C0x7162706271%2C%28SELECT%20%28ELT%283565%3D3565%2C1%29%29%29%2C0x71766b6b71%29%29%20AND%20%27KCzU%27%3D%27KCzU&rec=1&bots=1
2. It triggers a tracking error Invalid idSite: '0' you can see as administrator in Administration > Diagnostic > Tracking failures.

Your Environment

• Matomo Version: 4.14.1
• PHP Version: not relevant
• Server Operating System: not relevant
• Additionally installed plugins: not relevant
• Browser: not relevant
• Operating System: not relevant

[Seb35]

PS: I observed also this same tracking error in #12264, it was different URLs (POST /matomo.php?undefined&pv_id=hnuJWg) and this was fixed in 4.11.0.

[bx80]

Hi @Seb35,

Thanks for drawing attention to this and the detailed report 👍

Solution 4 sounds like a good approach to me, it's very unlikely any misconfiguration of the site id would contain SQL keywords!

I'll assign this issue for prioritization by the product team

[sgiehl]

This could actually also be something we could add to the tracking spam prevention plugin.
Something like filtering out any tracking requests that contain any typical content used by security scanners.