You have an error in your SQL syntax; check the manual that corresponds to your MariaDB server version for the right syntax to use near 's_Basketball_Tournament' AND log_timestamp > 1 AND log_type IN' at line 4

Having checked with titles without a ' (which work, like Google) it appears input is not being escaped correctly

Thanks for the incredibly timely response (maybe we could use you at OTRS).

I like to make sure I'm interpreting your response correctly. The first and it sounds like I'm supposed to look up some manual to figure out how to enter a page name correctly but I hope I'm misinterpreting it.Copy and pasting an article title shouldn't require special handling by the user in such a common situation. I just tried the following title:
Brrrº

And that worked. I'm sure there are thousands of titles with apostrophes in them. I hope the plan is to fix the tool not expect users to do something special.

Given this could potentially be used for SQL injection, better to be safe than sorry. Apologies if my initial debugging is incorrect

@Sphilbrick This is a bug which the developers will fix, so you'll soon be able to view statistics for article titles with apostrophes in :)

Tsk tsk. Who didn't sanitize their inputs? :p

If I may make one more related point - when I copy and paste an article title to use in some way, I often copy it from the top of the article, but sometimes. I copy it from the url.

If I did that, I would use:
2017_NCAA_Division_I_Women%27s_Basketball_Tournament

I got a slightly different error. I will leave it up to you to decide whether that is a user error, but I suspect I'm not the only one who does it.

This is fixed and will be deployed shortly.

In T170808#3443541, @Samtar wrote:

Given this could potentially be used for SQL injection, better to be safe than sorry. Apologies if my initial debugging is incorrect

It's very bad, no doubt, but this db is read-only and public so there's no real harm.

[Task made public as patch was deployed]

Thanks, my limited test now works.

Phil

It's very bad, no doubt, but this db is read-only and public so there's no real harm.

Note, this is not neccesarily true - it depends on context, and I don't know for this tool, but sql injections can also target other databases than the one in use (For example if xtools has a private database). It also may be possible to overwrite php files with malicious code if the SQL user has the FILE permission

In T170808#3453048, @Bawolff wrote:

It's very bad, no doubt, but this db is read-only and public so there's no real harm.

Note, this is not neccesarily true - it depends on context, and I don't know for this tool, but sql injections can also target other databases than the one in use (For example if xtools has a private database). It also may be possible to overwrite php files with malicious code if the SQL user has the FILE permission

I hashed that out with MusikAnimal until his ears were bleeding.

In T170808#3453471, @Cyberpower678 wrote:

In T170808#3453048, @Bawolff wrote:

It's very bad, no doubt, but this db is read-only and public so there's no real harm.

Note, this is not neccesarily true - it depends on context, and I don't know for this tool, but sql injections can also target other databases than the one in use (For example if xtools has a private database). It also may be possible to overwrite php files with malicious code if the SQL user has the FILE permission

I hashed that out with MusikAnimal until his ears were bleeding.

Yes, my ears are bleeding! I want to say you're preaching to the choir but I'm not a dick, I promise :) Feedback is always appreciated. The query was built this way because, at the time, I did not know how to do prepared statements with Doctrine. Moreover, our private database is not on Toolforge and uses a different database connection. I knew this, and even knew it would break for titles with an apostrophe. I merely took a shortcut during development with intention of fixing it later. That was foolish, sure. Should have done my Doctrine research :( Anyway, other places were fixed, this one was simply overlooked. In short, any harm that could have been done here could much more easily be done by creating your own Toolforge account and connecting to replicas directly. If it means anything, the legacy XTools apparently does not prepare queries and exerts the same vulnerability.

No need for ears to bleed, I just want to ensure that the potential impact of sql injections are not underestimated, or underestimated by other people who might be reading the comments on this bug.