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

[David Yearsley]

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]

I have found much more on this issue. The major problem is that the UI Action is running on the Client so that all of the UI Policy's can be enforced before the record can be submitted for Approval. As the UI Action is doing the update and is on the Client that the User has to have Write access to the field. I am now looking for a way to do the update on the Server but still enforce the UI Policy's.

Your answers have me started down the correct path, but I still don't have a working solution.

Thanks for you help and if you have any ideas I would appreciate the help.

[Slava Savitsky]

What exactly is your UI action doing? Can you share the code please? Perhaps, it can be reconfigured to work on the server side.

[David Yearsley · Accepted solution]

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);

}

[Slava Savitsky]

First and foremost, UI Policies should never be used as a security measure. They are client-side scripts and can easily fail if there is an error in another client-side script that runs earlier or if you are using a browser that is not very good at processing JavaScript. Moreover, for a malicious user client-side scripts are very easy to bypass. Therefore, you should always use security rules (ACLs) when you need to protect fields and tables in your system. For additional security, use high security settings. In your case, setting "glide.security.strict.updates" system property to "true" can be quite helpful.

Security Best Practices - ServiceNow Wiki

Using Access Control Rules - ServiceNow Wiki

High Security Settings - ServiceNow Wiki

[ssb]

The solution is to run server side code on submit, often that's going to be a Business Rule.or the server side of a UI Action, as above