Securing .list And .do Pages Via ACLs

Within ServiceNow, anyone can go to any table by manipulating the URL or via the navigation menu.

I.E, if you want to go to the incident table, even if you haven’t access to the incident module, you can just:

  1. go directly via the url: https://sn-instance.com/incident_list.do or https://sn-instance.com/incident.do
  2. in the navigation menu search bar, type incident.list or incident.do

Having ACLs in place makes sure that the actions that you don’t want to happen don’t happen (create, write, read, delete). However, what if you just want to stop navigating to that URL in the first place?

You can stop users getting to the page via the navigation menu by editing the ‘NavFilterExtension’ UI Script (it has very good comments in there and easy to edit to do what you want).

I accidentally stumbled across a neater solution, again using ACLs.
Continue reading

Intercepting Record Access

For years I’ve been working with ServiceNow and every time, one thing that always got to me that I never understood how it was accomplished was when viewing a sc_request record in self service view, it always re-directed to the order summary UI page.

order_summary

I just couldn’t figure it out and just assumed it was some hard-coded logic hidden away from us… until now! (yes, I’m a little excited about this…)

Continue reading

Tip For Creating Complex Before Query Business Rules

Before query business rules are great! I absolutely love them and use them all the time.

Sometimes though, I do find myself getting into a bit of a twist with the logic in the code.

Before I show you what I do now to overcome it, i’ll quickly explain what a before query business rule is. Put simply, it’s exactly as the name implies. It’s a business rule that runs before querying the database. More specifically, it can add additional query parameters to the search automatically and invisibly to the user.

For example, if a user wants to view all users, they can go to the sys_user table with no query parameters.

The system will essentially do the following code to bring back the results:

var current = new GlideRecord('sys_user');
current.query();

Now, if you want to only allow users to view active users, this is where a before query business rule comes into play. If I gave you the above script and asked you to only return active users, you would amend the code to be:

var current = new GlideRecord('sys_user');
current.addActiveQuery();
current.query();

A before query business rule is no different. You’d create the business rule and add the line current.addActiveQuery() to the body and that’s it (side note, a before query business rule is one where the ‘when’ field is set as before and the ‘query checkbox is ticked’). So essentially, the before query business rule is made to add additional query conditions to the query GlideRecord. The above example can be seen in the business rule called ‘user query’ out of the box on the sys_user table.

Now that’s out of the way, adding a simple parameter like above to a query is simple, but when you have 5/6 different parameters and different conditions for each one, and different values, things gets a little/lot more complicated.

The way I get around that is simple.
Continue reading

Securing The Activity Formatter (Or Any Formatter For That Matter)

The activity formatter on a form is a great part of ServiceNow. As long as it’s added to the form, and the table is audited, you can get a quick glance of the most important updates.

However, my only issue with it (and it’s my issue with all formatters), is that you can’t apply an ACL to it. For some users, I don’t want them to see it at all, but I don’t want to have to create a custom view just to hide it.

What I did therefore was found a way to apply ACLs to the formatter. This little trick can be used on all formatters.

Continue reading

Automated Login Using A HTA File

One of our clients had the concept of kiosks in particular locations/office/factories. These kiosks were used to give users access to a number of applications for information. One of the things they wanted the kiosk to have access to was their ServiceNow knowledge base.

We didn’t want to make the knowledge base public because it contained sensitive information, and at the same time didn’t want the users to have to enter a username and password to login.

I experimented with a login using a HTA file (same technology as Help the help desk functionality). The idea being that this could sit on the desktop and when clicked, will login automatically to ServiceNow.

We never used this solution, but I thought the idea was interesting and one I haven’t played with before so posting it here just as a concept.

So the approach was this (actual code at the end):

I created a new user record specific for each kiosk. The username was the windows username that the kiosk was logged in with. On the user table, we created 2 new fields:

1) u_ip which IP restricted who could access using this account

2) u_automated_login which was a True/False field to determine if this user record could use automated login or not

Then I created a HTA file which would read the username of the logged in user. Then it would do a HTTP post which was the same as the login.do page, except it would also pass an additional parameter across with it of ‘AutomatedLogin’.

Editing the Login installation exit, I then would check if the additional parameter was passed through, if so, I would check if this user had the Automated Login checkbox ticked, and finally, would check if their IP address matched against the one on record. If all these passed, I would log the user in automatically.

 
Continue reading

How To Pass Sensitive Data Via GlideAjax

Sometimes the data that you’re passing back from the client is sensitive data which nobody should be able to read (including administrators).

One particular instance for this is if you are passing a password back to do validation.

Also, sometimes some GlideAjax’s you just do so many times, that it’ll clog up the logs and possibly cause performance issues with the constant writing.

The logs I am talking about here are the Apache Tomcat logs (https://instance.service-now.com/channel.do?sysparm_channel=logtail)

Give it a go, have one window open with the logs and in another window run a GlideAjax and watch the information that’s written to the logs.

There’s a very simple parameter which you can use to prevent this logging:
Continue reading