Fix possible information disclosure within filter api #351
Conversation
| if( access_has_project_level( $t_access_required_to_view_private_bugs, $t_pid, $t_user_id ) ) { | ||
| $t_private_and_public_project_ids[] = $t_pid; | ||
| # limit reporters to visible projects | ||
| if( ( ON === $t_limit_reporters ) && ( !access_has_project_level( REPORTER + 1, $t_pid, $t_user_id ) ) ) { |
There was a problem hiding this comment.
I'm wondering if REPORTER shouldn't actually be config_get( 'report_bug_threshold' )
There was a problem hiding this comment.
For the purposes of this, i'm going to go with 'no'.. however, will submit a PR for us to evaluate whether to move away from using REPORTER like this.
|
Do we need a CVE for this exposure (looks like CWE-200)? |
|
hmm, I wrote on a comment on this before: In terms of CVE, I'm thinking not - or well: to disclose the any information on a bug, you'd need to be a manager in one project for instance, and a reporter in another project on the same instance. The danger if you start treating these sort of things as needing CVE's, we'd have to evaluate whether any config_get -> config_get($t_bug->project) we've made, would require the same treatment. So for example, lets take the SOAP api for one moment: We allow enum strings to be set per-project. ... and whilst I think these sort of things do need fixing, i'm not sure we really want to be generating a CVE for each one. |
This fixes visibility of bugs within filter api for users who have different roles in different projects.
OK, fair enough |
|
We do however need to review use of config_get() for projects which is on On Mon, Sep 29, 2014 at 9:45 AM, Damien Regad notifications@github.com
|
This fixes visibility of bugs within filter api for users who have
different roles in different projects.