Page MenuHomePhabricator

500: Internal Server Error with ArticleInfo when using an apostrophe in article title
Closed, ResolvedPublic

Description

I tried the page history tool with several articles, e.g. 2017 NCAA Division I Women's Basketball Tournament

Received an error almost immediately

XTools version: 3.0.2-a9e1895

Event Timeline

Restricted Application added a subscriber: Aklapper. · View Herald TranscriptJul 17 2017, 1:07 PM
Samtar added a subscriber: Samtar.Jul 17 2017, 1:12 PM
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.

Samtar set Security to Software security bug.Jul 17 2017, 1:32 PM
Samtar added a project: Security.
Samtar changed the visibility from "Public (No Login Required)" to "Custom Policy".

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.

I'll take a look.

Matthewrbowker triaged this task as High priority.Jul 17 2017, 4:32 PM
Matthewrbowker moved this task from Inbox to Working on the XTools board.
Matthewrbowker renamed this task from 500: Internal Server Error to 500: Internal Server Error with ArticleInfo when using an apostriphe in article title.Jul 17 2017, 4:46 PM

This is fixed and will be deployed shortly.

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.

MusikAnimal closed this task as Resolved.EditedJul 17 2017, 6:39 PM

See http://xtools.wmflabs.org/articleinfo/en.wikipedia.org/2017_NCAA_Division_I_Women%27s_Basketball_Tournament

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.

% is a valid page title, so we can't assume you're entering a percent-encoded title. It will be up to the user to ensure this doesn't happen. For example, nothing is found if you enter 2017_NCAA_Division_I_Women%27s_Basketball_Tournament into Special:Search

We should more gracefully handle this error, though, so thanks for bringing it up :) http://xtools.wmflabs.org/articleinfo/en.wikipedia.org/2017_NCAA_Division_I_Women%252527s_Basketball_Tournament

Restricted Application added a project: Security. · View Herald TranscriptJul 17 2017, 6:54 PM
Aklapper changed the visibility from "Custom Policy" to "Public (No Login Required)".Jul 17 2017, 7:28 PM

[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

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.

Aklapper renamed this task from 500: Internal Server Error with ArticleInfo when using an apostriphe in article title to 500: Internal Server Error with ArticleInfo when using an apostrophe in article title.Jul 19 2017, 6:18 PM

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.

MusikAnimal moved this task from Working to Complete on the XTools board.Jul 23 2017, 7:33 PM
Restricted Application added a project: User-Matthewrbowker. · View Herald TranscriptMon, Feb 10, 10:55 PM