Hi,
This is not a security problem. Use the permission model to deal with this.
It can be as simple as having the user Login Name in the Assigned To field,
and allowing the Assignee group to change the field. When the it is approved,
just set the Assigned To field to $NULL$ to revoke change access the Assignee
group.
This kind of row level access can be done similarly with field 112 or the
60xxx fields/groups.
Best Regards - Misi, RRR AB, http://www.rrr.se (ARSList MVP 2011)
Ask the Remedy Licensing Experts (Best R.O.I. Award at WWRUG10/11/12/13):
* RRR|License - Not enough Remedy licenses? Save money by optimizing.
* RRR|Log - Performance issues or elusive bugs? Analyze your Remedy logs.
Find these products, and many free tools and utilities, at http://rrr.se.
> 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_
>
> _______________________________________________________________________________
> UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
> "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"
