Users using debugging tools to change values of read only fields.

David Yearsley · ‎10-21-2014

The issue: The Approve field on our Change form the is driven by programming so there is a UI Policy to set the field to read only. There is also an ACL the give ITIL the ability to write to the field so they can save the record when the value is changed by programming. The Recently one of our programmers was entering a Change Request and use the inspect element on Firefox to change the value of this field and then saved the record, which allowed him to have set the State to Approved without going through Approvals. After discovering this issue I discovered several other fields that can be changed and saved by using the inspect element feature. I have been working with ServiceNow but they have not come up with a viable solution. Looking for a way to lock a field down so you can't used the inspect element to change the value.

To duplicate:

The easiest way is create a UI Policy to make the Approval field on the Change Request to Read Only. Then inspect element on this field with Firefox or IE. Once the inspect element opens, then open the selection list. If there is one of the selections that has the text: selected="SELECTED", just move the text to another value. If not then just add the text to one of the values. Then save and the value will change on the record.

You can't set it to read only with and ACL because then the use can't save the record when Approval value changes, they don't have permissions to write to that field.

If you need more information let me know.

David Yearsley · ‎10-22-2014

I actually found the answer on the web. I am running a UI on the client to require the UI Policy's to run before the user can save. I just moved the set fields to the server side of the UI Action and then removed the ACL that let the user Write to the field and now it updates and the user can't use firebug to change the value.

Thanks for you help as you pointed me in the right direction. Here is the UI Action.

UI Action.

Action Name: uSubmit.approval

Client: Yes

function runApproval() {

gsftSubmit(null, g_form.getFormElement(), 'uSubmit.approval');

}

if(typeof window == 'undefined')

submitApproval();

function submitApproval() {

current.approval = 'requested';

current.update();

action.setRedirectURL(current);

}

View solution in original post

David Yearsley · ‎10-21-2014

If you have access to the issue at ServiceNow I have an issue open. The number is INT2438010

Community Alums · ‎10-21-2014

Interesting, thanks for posting. We implemented ACL on the State field to only allow admin to change the state (not even itil role can), otherwise it is automatically updated as the workflow progresses.

Curious, did the user do this maliciously, or was it more of an attempt to point out security hole(s) which succeeded?

David Yearsley · ‎10-21-2014

No the user was new to the Change Request and could not get it to submit, so he found away around the requirements.

Quick question: This is running from a UI Action that is running on the Client. Is that why the workflow won't update the record unless the user has the a role that allows him to Write to that field.

Community Alums · ‎10-21-2014

I believe so, yes. What does your UI action look like? If it's conditions are set to only allow write by a certain role, then yes, the user would need a certain role to update the record.

We had originally implemented a UI policy to handle the security, but our implementation specialist frowned upon this method, and suggested the ACL method, which we now have in place. Having the ACL in place also prevents record updates in the list view and mobile view, which a UI policy would not....