Does anyone else use Script Includes for code in ACLs

[Daniel Peel]

Personally I'd never done it... but I noticed on Patch 4 of Madrid they added an ApproverUtils() SI and it's used on ACLs.  Doesn't this defeat the purpose of ACLs in some respects.  You can now modify who could/couldn't approve something simply by changing the SI.  This seems to bypass some of the security in needed in the security admin role... and elevating your roles to modify ACLs.

I'm sure this isn't the first one... just the first one I've noticed.

[Chris M3]

It's fairly common in many of the modules.  When the logic is complex, and needs to be repeated in several ACL's, it wouldn't make technical sense to duplicate all of that script code.  Yes though, it does bypass the security provided by security_admin.

[Daniel Peel]

While I agree technically it makes sense not to duplicate code, it seems security needs should trump that.  If doing this allows you to bypass the function/protection of an ACL then it doesn't make sense to do it.  If we had the ability to require elevation for editing some SI's then this would again be back inline with both coding best practice and security best practice.

[DScroggins]

Hello Daniel,

We use Script Include for ACL's which require complex evaluation and must be run on many field level write/read ACLS. Although I do agree that it is easier for the Script Include to now be modified which would alter the security of the ACL for our use case this is of no concern. If you wanted to lock it down more you could add a classification i.e. 'Security' vs 'Normal' to Script Includes and then use an ACL to restrict the modification of 'Security' type script includes to users with security_admin only. Perhaps this would alleviate some of the concerns with using script includes within ACL's.

Hope this helps.

--David

[Daniel Peel]

I appreciate the "how to resolve" answers... this wasn't posted as an I need help post... it was conversational... more I feel ServiceNow should offer this type of option when they remark in their documentation how ACLs are used to secure information.  This is a direct circumvention of that process with no OOB method to secure that data.  I as a user shouldn't need to modify the SI forms or tables to lock them down.  They certainly have a way to lock them down so we can't edit them... but they prevent us from modifying that information as well.  

I'm not creating an SI here that I need to lock down... I'm speaking to one directly added by SN with Madrid Patch 4 that is used directly on approval forms... to show or not show the approval record.  Moving this to an SI allows modification of ACL function without elevation.  

I like your idea of adding a classification to the SI table... but the point I guess I tried to convey was we shouldn't have to.