Security issue on self service portal

Wayne Richmond · ‎05-09-2014

I have created a new application for out legal team that has its own CMS self service portal. During testing I they identified a potential security issue whereby a customer is able to see other customers requests. This only occurs when they Update their request having been sent there via a link/mail script in a notification or using a link in a List menu (called Recent Requests). If they navigate to their request via the navigation menu > My Requests > open a request > Update > they return the list of their requests as normal. The pages have different URLs and I'm not too sure why...

This is the url the customer gets from the notification email: https://oxfamprod.service-now.com/legal/legal_detail.do?sysparm_document_key=u_legal,aa7989822c24e90...

This opens the record. Once they click Update they see all records, not just theirs.

Likewise, if they click a link to their call in the Recent Requests List they go to this url https://oxfamprod.service-now.com/legal/legal_detail.do?sysparm_document_key=u_legal,aa7989822c24e90...

This link from the navigation menu takes them to their list of records: https://oxfamprod.service-now.com/legal/requests.do

Below is the link to the same record as above but the url looks significantly different to me

https://oxfamprod.service-now.com/nav_to.do?uri=u_legal.do?sys_id=aa7989822c24e9043ed6e30fe47aec0f%2...

Once they Update the record as before, they return to the previous page and only see their records.

I'm struggling to see where the issue is. I know that's probably hard to follow without seeing it in action. I hope someone can help!

Thanks

Wayne

domaners · ‎05-12-2014

Hi Wayne, there should be a similar ACL rule for "read" access to your table, which is where you can add the javascript:gs.getUserID() condition. This way, the user will see a truncated list when they click Update, with a message underneath stating that a number of records have been hidden due to security restraints.

Alternatively, you could configure the notifications to point to a custom view for these records by adding the sysparm_view parameter to the hyperlink. You'd then need to create a custom UI Action for your table that would replace the global Update button. This action can be set to only appear on your custom view, so that when the user accesses a ticket from a hyperlink, clicking the Update button will take them to a place of your choosing, such as "home.do", etc. See the following article:

UI Actions - ServiceNow Wiki

View solution in original post

Wayne Richmond · ‎05-12-2014

An interesting knock-on effect was that users with the 'legal_user' role could no longer see the records. I tried adding the role to the acl at the bottom of the record but because ServiceNow determines if all three statements are true, this still didn't work. How can I implement your suggestion without removing access to the staff who are meant to be dealing with the requests?

domaners · ‎05-12-2014

The best way to handle this would be to create another read ACL, then simply add the legal_user role and leave the rest of the fields. This is the only way I believe that you can add "or" type condition between the filter, script and role access, which seems a bit backwards at first but soon becomes second nature.

Wayne Richmond · ‎05-13-2014

Thanks Adam - that was one of those easy things that seemed too simple.

conmic · ‎05-12-2014

I suggest you use the debugging functionality of ServiceNow to determine which ACL rules are working on your record/fields.

Activate 'Debug Security' or 'Debug Security Rules', impersonate a normal user, navigate to the record list/form and you'll have a debug output and 'watch bugs' on the fields to see what happens.

When done, go back to your account and select 'Stop debugging'.

domaners · ‎05-12-2014

This is a great feature, but only available from Dublin onwards I believe?