Thank you for your comments. I have slightly different outlook with regard to data security. I understand why the ars design means that the ui is vulnerable.
Thanks Jon ---- Jason Miller wrote ---- >** > >I agree with LJ and BMC. Read Only functionality is not meant to be a data >security enforcing measure. It is a UI feature. > > >True permissions and enforcing workflow is going to be even more critical >assuming a very easy to use RESTful web service is right around the corner. >Any user can simply install Postman and have their way with your data easier >that ever before. > > >That makes me wonder if maybe there should be an option to disable RESTful web >services? Maybe shutting down Jetty is sufficient enough? This will allow >organizations perform a security review prior to enabling this powerful >feature. > > >Jason > > >On Tue, Apr 21, 2015 at 1:00 PM, LJ LongWing <[email protected]> wrote: > >** > >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 <[email protected]> >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_ > > >_ARSlist: "Where the Answers Are" and have been for 20 years_ > > >_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"
