Jon, I unfortunately must agree with BMC on this one....if they have change permission, they have change permission. There are any number of ways to update the data without using Mid-Tier....so, if they truly should not be modifying the data, you will need to either enforce it via permissions (give ability to submit, but not ability to change), or, as you stated, build Filter based workflow to lock the fields down from a change perspective.
On Tue, Apr 21, 2015 at 1:29 PM, Jon Young <jyo...@performanceworkflow.com> wrote: > ** > Hi Listers > > Sorry if this has been discussed recently before; I’ve got the tricky > task of explaining to clients that Read-Only fields can be modified by > users by a simple hack. I wondered if any of your employers/ clients see > this as a data security risk and if you have any solutions for this? > > Issue: > --------- > Sometimes, we want users to be able to modify a field so we give that > field a Change permission, and give the user that permission. For example, > we want a user to enter a short description on a Change Request. > > Later, we don’t want the user to modify that field. For example, when a > Change Request has been approved. We don’t really want the user to change > details. To prevent this, we make the field Read-Only. > > The vulnerability is that even though that field is Read-Only they can > modify the field using tools included in web browsers. If our users are > external to our organisation we can not control what browsers they use. > > So this is only an issue is a user is deliberately trying to misuse the > system – the sort or users we’d like to take security precautions against. > > BMC’s Stance > --------------------- > BMC, the lead architect, has stated that Read-Only fields are a display > characteristic to assist the user interface. > > Solutions > ------------- > We could crate filters that fire when we know a fields are read-only for > the current user to check the TR value and prevent the commit. This is a > lot of overhead for fixing this vulnerability in BMC’s ITSM application, > let alone customisations and bespoke applications. > > Alternatively, we could audit the fields. It doesn’t prevent the issue > but would at least help to check if the field was changed. > > As BMC don’t see this as a bug or a vulnerability my hopes of mid tier/ > server fix for this are somewhat muted! > > Thanks > Jon > _ARSlist: "Where the Answers Are" and have been for 20 years_ _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org "Where the Answers Are, and have been for 20 years"
