Re: Read-Only Field Vulnerability
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 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" > 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 >> wrote: >> >>> ** >>> Jon, >>> I unfortunately must agree with BMC on this oneif they have change >>> permission, they have change permission. There are any number of ways to >>> update the data without using Mid-Tierso, 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 t
Re: Read-Only Field Vulnerability
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" 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 > wrote: > >> ** >> Jon, >> I unfortunately must agree with BMC on this oneif they have change >> permission, they have change permission. There are any number of ways to >> update the data without using Mid-Tierso, 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"
Re: Read-Only Field Vulnerability
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 wrote: >> >>** >> >>Jon, >> >>I unfortunately must agree with BMC on this oneif they have change >> permission, they have change permission. There are any number of ways to >> update the data without using Mid-Tierso, 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 >> 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"
Re: Read-Only Field Vulnerability
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 wrote: > >** > >Jon, > >I unfortunately must agree with BMC on this oneif they have change >permission, they have change permission. There are any number of ways to >update the data without using Mid-Tierso, 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 >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"
Re: Read-Only Field Vulnerability
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 wrote: > ** > Jon, > I unfortunately must agree with BMC on this oneif they have change > permission, they have change permission. There are any number of ways to > update the data without using Mid-Tierso, 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 > 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_ > ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org "Where the Answers Are, and have been for 20 years"
Re: Read-Only Field Vulnerability
Jon, I unfortunately must agree with BMC on this oneif they have change permission, they have change permission. There are any number of ways to update the data without using Mid-Tierso, 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 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"
