Page MenuHomePhabricator

Security review of TargetProcess Bugzilla module
Closed, DeclinedPublic

Description

We're considering using TargetProcess's KanBan board (http://www.targetprocess.com/). This is a commercial service, but it would simply be acting as an interface on top of Bugzilla, so all data and activity would still be managed on our infrastructure using OSS tools. And the KanBan board itself could be set to 'public', allowing anyone to view it.

TargetProcess's Bugzilla integration requires adding an additional entrypoint to our Bugzilla instance: http://core.tpondemand.com/JavaScript/Mashups/Bugzilla%20ProfileEditor/Scripts/4.2/tp2.cgi.zip

There are two blockers to using it:

  • The file is currently missing a license header. I contacted TargetProcess support and they are prepared to release the file under an open-source license.
  • The file needs security review.

Version: unspecified
Severity: enhancement

Details

Reference
bz62272

Event Timeline

bzimport raised the priority of this task from to Lowest.Nov 22 2014, 3:01 AM
bzimport set Reference to bz62272.
bzimport added a subscriber: Unknown Object (MLST).

There is a GPL PHP software https://github.com/EvanOman/KanbanBoard which uses a custom field in Bugzilla to track the column of the bug.

An intern at Mozilla coded an Angular.js with a python backend which does Kanban as well: https://github.com/DerekRies/kanbanzilla

For hhvm project purposes, maybe we can just stick to mingle which is already used by various teams and the base of the scrum of scrums.

(In reply to Ori Livneh from comment #0)

We're considering using TargetProcess's KanBan board

Who's "we" in this context?

tp2.cgi says

my $supportedBugzillaVersion = '4.2';

But we run 4.4. ("we" = the Wikimedia servers ;-)

As it's written, it does a very poor job of security. They parameterize most of their sql (except the one on 376, but hopefully bugzilla wouldn't have an extra feature name that contained sql), so it probably won't take down the server.

They don't do any xss filtering, and rely and outputting text/plain content type. So xss is only exploitable on ie6, iOS 6's Safari, or any other browser that interprets scripts in text/plain.

It would probably be safe to deploy this if you could lock down access to only their IP address (so xss wouldn't be an issue). But it certainly isn't something I would feel comfortable having up and accessible on our servers.

Is this still wanted, or can this ticket be closed?

Setting to "Lowest" for now, and when we migrate to Phabricator, let's close this as INVALID (ie: keep it around on the very very slim chance something in Phabricator land blows up and we don't end up using it).

Wikimedia has migrated from Bugzilla to Phabricator. Learn more about it here: https://www.mediawiki.org/wiki/Phabricator/versus_Bugzilla - This task does not make sense anymore in the concept of Phabricator, hence closing as declined.