View Issue Details

IDProjectCategoryView StatusLast Update
0023561mantisbtapi soappublic2017-12-17 05:13
ReportercproensaAssigned Tovboctor 
PrioritynormalSeveritymajorReproducibilityhave not tried
Status closedResolutionfixed 
Product Version1.3.0-beta.1 
Target Version1.3.13Fixed in Version1.3.13 
Summary0023561: mc_project_get_issues_for_user() is retrieving issues in the authorization context of target user
Description

mc_project_get_issues_for_user() is used to build a filter to get issues referred to a target user.

Running that function there are two users involved:

  • logged user (from resolving $p_username, $p_password)
  • target user to get issues associated with

I suspect that the filter is being built and called in the context of target-user

$t_rows = filter_get_bug_rows( $p_page_number, $p_per_page, $t_page_count, $t_bug_count, $t_filter, $p_project_id, **$t_target_user_id**, $t_show_sticky );

The user parameter for filter_bug_rows is the user which is used to evaluate the config options needed to resolve visibility thresholds, etc.
This means that if target user has different privileges that logged-user, the filter may return information that should not be visible to him.

I am not able to test the soap api to reproduce this, i'd appreciate if someone with better knowledge on this can test and tell if it's actually an issue.

TagsNo tags attached.

Relationships

related to 0022790 closedvboctor Support standard filters defined by the system when retrieving issues 

Activities

cproensa

cproensa

2017-10-30 14:25

developer   ~0058088

I have reproduced this with a sample client
having:

  • user A can see private issues
  • user B can't see private issues
  • create private issue, assign it to user A

Then calling mc_project_get_issues_for_user authenticated as user B, filter type 'assigned' for target user A, it returns the private issue.
The private issue should not be visible for user B.

rombert

rombert

2017-11-04 16:26

developer   ~0058133

@cproensa - definitely looks like a bug to me. The filter_get_bug_rows docs states that the $p_user_id is "User id to use as current user when filtering." @vboctor and @dregad should also be able to comment here as the committer/author of change. This was introduced for bug 0015807

vboctor

vboctor

2017-11-29 21:24

manager   ~0058266

@cproensa, @rombert, @atrol

It seems that we use target user to do two things:

  1. Create a filter - e.g. assigned to target user (which can be 0), monitored by target user, reported by target user, etc.
  2. Get issues matching the filter - we pass target user id.

I suspect that the right behavior is to fix step 2 to use the logged in user id rather than the target user id. If that makes sense, I can provide a fix that is targeted for 2.8.1.

atrol

atrol

2017-11-30 03:14

developer   ~0058272

I suspect that the right behavior is to fix step 2 to use the logged in user id rather than the target user id

+1

vboctor

vboctor

2017-11-30 17:52

manager   ~0058288

PR: https://github.com/mantisbt/mantisbt/pull/1248

vboctor

vboctor

2017-12-01 18:58

manager   ~0058296

Thanks @atrol for the review and @cproensa for reporting the issue. I have used SoapUI to test.

  • Issue confirmed before the fix.
  • Fix verified to address the issue.

I'll merge this before cutting 2.8.1.

atrol

atrol

2017-12-02 10:17

developer   ~0058303

@vboctor the issue has been introduced in version 1.2.16 0015807.
As it's a major security issue, shouldn't this also be fixed in 1.3?

Related Changesets

MantisBT: master-2.8 732ebc16

2017-11-30 12:58:02

vboctor

Details Diff
Fix SOAP API standard filters

Fixes 0023561
mod - api/soap/mc_project_api.php Diff File

MantisBT: master-1.3.x 7168f49d

2017-11-30 12:58:02

vboctor

Details Diff
Fix SOAP API standard filters

Fixes 0023561
mod - api/soap/mc_project_api.php Diff File

Issue History

Date Modified Username Field Change
2017-10-29 19:00 cproensa New Issue
2017-10-29 19:03 cproensa Severity minor => major
2017-10-30 14:25 cproensa Assigned To => cproensa
2017-10-30 14:25 cproensa Status new => confirmed
2017-10-30 14:25 cproensa Note Added: 0058088
2017-10-30 14:25 cproensa Assigned To cproensa =>
2017-11-04 16:26 rombert Note Added: 0058133
2017-11-29 04:44 atrol Relationship added related to 0022790
2017-11-29 21:24 vboctor Note Added: 0058266
2017-11-30 03:14 atrol Note Added: 0058272
2017-11-30 17:52 vboctor Note Added: 0058288
2017-12-01 18:58 vboctor Note Added: 0058296
2017-12-01 18:59 vboctor Assigned To => vboctor
2017-12-01 18:59 vboctor Status confirmed => assigned
2017-12-01 18:59 vboctor Product Version => 2.8.0
2017-12-01 18:59 vboctor Target Version => 2.8.1
2017-12-02 10:17 atrol Note Added: 0058303
2017-12-02 16:01 vboctor Changeset attached => MantisBT master-2.8 732ebc16
2017-12-02 16:01 vboctor Status assigned => resolved
2017-12-02 16:01 vboctor Resolution open => fixed
2017-12-02 16:04 vboctor Changeset attached => MantisBT master-1.3.x 7168f49d
2017-12-02 16:04 vboctor Fixed in Version => 1.3.13
2017-12-02 17:15 atrol Product Version 2.8.0 => 1.3.0-beta.1
2017-12-02 17:15 atrol Target Version 2.8.1 => 1.3.13
2017-12-04 02:17 vboctor Status resolved => closed
2017-12-17 05:13 atrol View Status private => public