0023561: mc_project_get_issues_for_user() is retrieving issues in the authorization context of target user - MantisBT - Signup temporarily disabled due to spam

ID	Project	Category	View Status	Date Submitted	Last Update

0023561	mantisbt	api soap	public	2017-10-29 19:00	2017-12-17 05:13

Reporter	cproensa	Assigned To	vboctor
Priority	normal	Severity	major	Reproducibility	have not tried
Status	closed	Resolution	fixed
Product Version	1.3.0-beta.1
Target Version	1.3.13	Fixed in Version	1.3.13

Summary	0023561: 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.
Tags	No tags attached.

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 2017-11-04 16:26 reporter ~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 2017-11-29 21:24 manager ~0058266	@cproensa, @rombert, @atrol It seems that we use target user to do two things: Create a filter - e.g. assigned to target user (which can be 0), monitored by target user, reported by target user, etc. 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 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 2017-11-30 17:52 manager ~0058288	PR: https://github.com/mantisbt/mantisbt/pull/1248

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 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?

MantisBT: master-2.8 732ebc16 2017-11-30 07:58 vboctor Details Diff	Fix SOAP API standard filters Fixes 0023561		Affected Issues 0023561
	mod - api/soap/mc_project_api.php		Diff File
MantisBT: master-1.3.x 7168f49d 2017-11-30 07:58 vboctor Details Diff	Fix SOAP API standard filters Fixes 0023561		Affected Issues 0023561
	mod - api/soap/mc_project_api.php		Diff File