Library Settings Editor History Feature Exposes Sensitive Data to Unauthorized Staff

Bug #1450519 reported by Jason Stephenson on 2015-04-30
This bug affects 9 people
Affects Status Importance Assigned to Milestone

Bug Description

This bug is a followup to The reason for opening this bug is that the fix to the previous bug is incomplete. That fix prevented unauthenticated, third party access to the library settings history, but it did not address the underlying issue that made that access possible. The history feature still has the bugs of not following the permission model used by the org. unit settings and of exposing data for locations outside of the current user's organizational unit ancestor hierarchy. At this point, however, the data is only exposed to accounts with the STAFF_LOGIN permission.

To address these problems, the following changes need to be made:

* The open-ils.pcrud controller, along with the associated pcrud permissions, should be removed from the coustl (config.org_unit_setting_type_log) object definition in the IDL.

* OpenSRF calls need to be added to to retrieve settings history. These calls will need to be given the user's authtoken as well as the setting name and possibly the desired organizational unit to look up. The latter can be derived from the user's authtoken and current working location, and so may be deemed optional or unnecessary. These calls should only expose the settings to the user that are in that user's org. unit hierarchy as defined by the appropriate database or other functions.

* The library settings editor interface in the staff client then requires modification to use the new OpenSRF calls and to stop using the openils.PermaCRUD JavaScript module.

Changed in evergreen:
milestone: none →
Kathy Lussier (klussier) on 2015-06-10
Changed in evergreen:
status: New → Confirmed
no longer affects: evergreen/2.6
Changed in evergreen:
milestone: → none
no longer affects: evergreen/2.7
no longer affects: evergreen/2.8
Changed in evergreen:
status: Confirmed → Won't Fix
Andrea Neiman (aneiman) wrote :

I am removing the won't fix because I think this is still an issue -- as of 3.2 I am still able to see Settings History for OUs outside of my assigned OU hierarchy.

Changed in evergreen:
status: Won't Fix → Confirmed
tags: added: admin-pages orgunitsettings webstaffclient
removed: admin staffclient
Rogan Hamby (rogan-hamby) wrote :

This is and can expose things like PayPal settings at other org units, which we definitely don't want.

Kyle Huckins (khuckins) wrote :

Noting that I'm looking at a solution to this within bug #1839341, specifically in regards to the new API method.

Ruth Frasur (rfrasur) wrote :

Has this ticket been resolved in the above-mentioned ticket?

To post a comment you must log in.
This report contains Public Security information  Edit
Everyone can see this security related information.

Other bug subscribers