The UI is not vulnerable, if your application is not vulnerable. Same as any other web form in existence.
If you didn't use ARS and just designed an html form that passes data to a post, is that post "secure" because you used a hidden form element? Permissions must be enforced on the backend, in any Web application. Front end permissions are not permissions, they're just display properties, and as others have pointed out, it's trivial to bypass the GUI entirely using the API, anyhow :-) -Andy On Apr 22, 2015 1:36 AM, "Jonathan Young" <jyo...@performanceworkflow.com> wrote: > ** > > 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 <lj.longw...@gmail.com> > 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 < >> 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_ >> >> >> _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"
