Jon, I understand what you are saying, but stop for a second and ask your self a question. you have the company who created the application since 1992 (inception). The underlying foundation of the code and the structure has not changed since. over 12,000 customers at times and yes there have been some fluctuations. 4 top guys on this list who do this for a living telling you... NO there is not a problem with security. But You a person in the desert yelling it is.. Which is more likely wrong in this situation? you or the original founders, and another 12000 people. Lets not be hard headed and kill ourselves if this is the wrong tree to be barking at... you can do this! People just mentioned very clear ways through the proper security features that already exists, to prevent it from happening. Just ask, and they will help you... sorry to be harsh... I am not being rude.. but ... be teachable..
On Wed, Apr 22, 2015 at 7:59 AM, Andrew Hicox <and...@hicox.com> wrote: > ** > > 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_ > > _ARSlist: "Where the Answers Are" and have been for 20 years_ > -- Patrick Zandi _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org "Where the Answers Are, and have been for 20 years"
