The Security Policy determines the level of security to which the system is configured.

Although all Users are subject to the same Security Policy, you can provide more stringent security for Virtual Users using the Virtual Custom node. Standard Users can thereby derive their security settings from the Sapphire Custom node, while Virtual Users derive their security settings from the Virtual Custom node.

 

Property Description
REST Services Determines the level of security when running REST Web Services:
Property Name Description
Enable Determines if REST Web Services are enabled within a configuration:
Yes=REST Web Service requests will be accepted.
No=REST Web Service requests will be rejected. This is the default.
Enforce SSL Determines if REST Web Services must be run over an HTTPS (SSL/TLS) connector:
Yes=REST Web Service requests will be accepted only if they run over an HTTPS (SSL/TLS) connector. This is the default.
No=REST Web Service requests will be accepted whether or not they run over an HTTPS (SSL/TLS) connector.
Host Access List This is provided to allow "host checking", which restricts the machines that can process a REST Web Service request. You can define a list of hostnames or IP addresses here, then REST Web Services can be run only if the request is sent to one of these hosts.

Note that if you add an item to this property collection, it assumes you are doing host checking - even if all three of the properties below are left blank.

Property Name Description
TypeDetermines whether the "IP Address" or "Host Name" is used to conduct host checking.
IP or Host NameIP Address or Host Name used to conduct host checking, depending on which you specified above.
Enabled Provides control over each host:
Yes=Enables the connection.
No=Disables the connection.
Action Processing and Permitted ActionsAs of LabVantage 8.5, these settings have been moved to the REST Policy.
Web Services Determines the level of security when running Axis/JAX Web Services:
Property Name Description
Enable Determines if Axis/JAX Web Services are enabled within a configuration:
Yes=Web Service requests will be accepted.
No=Web Service requests will be rejected. This is the default.
Action Processing Determines the scope of Action processing supported by Axis/JAX Web Services:
Full=Provides unrestricted access to all Actions defined through the LabVantage System Action Public Interfaces.
None=Prevents all Action processing. This is the default.
Restricted=Allows only the Actions specified by "Permitted Actions" (below) to be called and processed.
Defined By Roles=Allows only the Actions allowed by the User's Role Level Access to be called and processed. To use this option, you must grant the desired Role-Level Access to each required Action using the "Manage Roles" button on the Action List Page.
Permitted ActionsActions that can be called and processed if "Action Processing" (above) is "Restricted":
Property Name Description
ActionAction that can be called and processed.
Allow Action Class ProcessingDetermines whether or not (Yes/No) Action classes can be used in Action or Action Block processing calls. The default is No.
Allow Unregistered SQLDetermines the type of query arguments that can be processed:
No=Does not allow SQL text to be processed on the Application Server when received from Web Services. This allows only a sqlcode (integer), which equates to the SQL text in the SQL register. This is the default.
Yes=Allows SQL text to be processed on the Application Server. This is provided for backward-compatibility with LabVantage 6.0.2 and earlier.
Action Command Determines the scope of Action processing supported when POSTing and GETing URL requests:
Property Name Description
POST Action Processing Determines the scope of Action processing supported when POSTing the URL request

rc?command=action&actionid=[actionid] URL request

Full=Provides unrestricted access to all Actions defined through the LabVantage System Action Public Interfaces.
Restricted=Allows only the Actions specified by "Permitted Actions" (below) to be called and processed. This is the default.
GET Action Processing Determines the scope of Action processing supported when GETing the URL request

rc?command=action&actionid=[actionid] URL request

Full=Provides unrestricted access to all Actions defined through the LabVantage System Action Public Interfaces.
None=Prevents all Action processing. This is the default.
Restricted=Allows only the Actions specified by "Permitted Actions" (below) to be called and processed.
Permitted ActionsActions that can be called and processed if "POST Action Processing" or "GET Action Processing" (above) is "Restricted":
Property Name Description
ActionAction that can be called and processed.
Allow Action Class ProcessingDetermines whether or not (Yes/No) Action classes can be used in Action or Action Block processing calls. The default is No.
Web Requests Determines the scope of Action processing supported by the ProcessAction request:
Property Name Description
Action ProcessingDetermines the scope of Action processing supported by the ProcessAction Ajax request:
Full=Provides unrestricted access to all Actions defined through the LabVantage System Action Public Interfaces.
None=Prevents all Action processing. This is the default.
Restricted=Allows only the Actions specified by "Permitted Actions" (below) to be called and processed.
Permitted ActionsActions that can be called and processed if "Action Processing" (above) is "Restricted":
Property Name Description
ActionAction that can be called and processed.
POST OnlyDetermines whether or not (Yes/No) Ajax calls must use the POST request method. The default is Yes.
Allow Action Class ProcessingDetermines whether or not (Yes/No) Action classes can be used in Action or Action Block processing calls. The default is No.
Allow Unregistered SQLDetermines the type of query arguments that can be processed:
No=Does not allow SQL text to be processed on the Application Server when received from Ajax requests. This allows only a sqlcode (integer), which equates to the SQL text in the SQL register. This is the default.
Yes=Allows SQL text to be processed on the Application Server. This is provided for backward-compatibility with LabVantage 6.0.2 and earlier.
Remote Java API Determines the scope of Action processing supported by remote Java API calls from sapphire.accessor classes constructed using a RAK file (Remote Access Key):
Property Name Description
Action Processing Determines the scope of Action processing supported by remote Java API calls from sapphire.accessor classes constructed using a RAK file (Remote Access Key):
Full=Provides unrestricted access to all Actions defined through the LabVantage System Action Public Interfaces. This is the default.
None=Prevents all Action processing.
Restricted=Allows only the Actions specified by "Permitted Actions" (below) to be called and processed.
Permitted ActionsActions that can be called and processed if "Action Processing" (above) is "Restricted":
Property Name Description
ActionAction that can be called and processed.
Allow Action Class ProcessingDetermines whether or not (Yes/No) Action classes can be used in Action or Action Block processing calls. The default is Yes.
Allow Unregistered SQLDetermines the type of query arguments that can be processed:
No=Does not allow SQL text to be processed on the Application Server when received from a remote Java Public API call. This allows only a sqlcode (integer), which equates to the SQL text in the SQL register. This is the default.
Yes=Allows SQL text to be processed on the Application Server. This is provided for backward-compatibility with LabVantage 6.0.2 and earlier.
Session Management Determines session security:
NOTE: Only "Session Binding", "Encrypt ConnectionId", "Allow ConnectionId In Request", and "Dedicated ConnectionId In Request" can be used with REST Services.
Property Name Description
Session Binding Determines if a browser connection is bound to a specific entity:
None=Connection is not bound. This is the default.
IP Address=All browser requests must originate from the same IP address as the original connection. This restricts transfer of a ConnectionId from one host to another.
Host Name=All browser requests must originate from the same hostname as the original connection. This restricts transfer of a ConnectionId from one host to another. Be advised that hostnames may not always be resolvable or resolved (as per servlet specification) and will revert to IP address.
Encrypt ConnectionIdDetermines whether or not (Yes/No) the ConnectionId is encrypted. The default is No.
Allow ConnectionId In RequestDetermines if the ConnectionId (specified in the cookie) can be submitted to the server through the URL (using GET) or a form (using POST):
No=Prevents the ConnectionId to be submitted to the server using a GET or POST by disabling functionality that derives the ConnectionId from the request object. This is the default.
Yes=Allows the ConnectionId to be submitted to the server using a GET or POST. This is provided for backward-compatibility with LabVantage 6.0.2 and earlier.
Match ConnectionId In SessionEnsures that the ConnectionId submitted to the server matches the one stored in the User's session object on the Application Server:
No=Prevents the ConnectionId from being submitted to the server by setting the connectionid cookie on the client browser. This matches the ConnectionId in the cookie with the ConnectionId in the server session object.
Yes=Allows the ConnectionId to be submitted to the server by setting the connectionid cookie on the client browser. This is provided for backward-compatibility with LabVantage 6.0.2 and earlier. This is the default.
Match User Agent In SessionDetermines how security is implemented for the UserAgent string:
No=Prevents the browser UserAgent details sent with the original connection to be matched to the browser UserAgent details in the server session object. This is the default.
Yes=Matches the browser UserAgent details sent with the original connection to the browser UserAgent details in the server session object. This is provided for backward-compatibility with LabVantage 6.0.2 and earlier.

Note that this is only a deterrent. Even with a value of "No", two browsers can have the same UserAgent string (especially Chrome).

Dedicated ConnectionId Ensures that a ConnectionId obtained through a User logon cannot be used in REST or Axis/Jax Web Service requests, and a ConnectionId obtained through a REST or Axis/JAX Web Service cannot be used to access LabVantage through a User logon in the browser:
No=Allows a ConnectionId obtained through a User logon from being used in REST or Axis/JAX Web Service requests. Allows a ConnectionId obtained through a REST or Axis/JAX Web Service from being used to access LabVantage through a User logon in the browser.
Yes=Prevents a ConnectionId obtained through a User logon from being used in REST or Axis/JAX Web Service requests. Prevents a ConnectionId obtained through a REST or Axis/JAX Web Service from being used to access LabVantage through a User logon in the browser. This is the default.
Show Page Name in URL Determines whether or not the LabVantage page name is displayed in the Request Controller command displayed in the URL on the browser address bar:
No=Prevents the LabVantage page name from being displayed in the URL. This is the default.
Yes=Allows the LabVantage page name to be displayed in the URL.
Share History EntriesDetermines if Users can access other Users' history entries:
No=Checks the history entry against the current User. If the history entry was created by a different User, history retrieval is blocked for the current User. This prevents Users from accessing other Users' history entries and accessing pages by copying the URL and state identifiers and sending them to another User. This is the default.
Yes=Does not block history retrieval.
NOTE: The ConnectionId is random and is not generated in any defined sequence.
Request Filter Determines how the request is filtered:
Property Name Description
EnableDetermines whether or not (Yes/No) any of the request filter options should be enforced. This assumes that the filter has been correctly configured and not disabled elsewhere. The default is Yes.
Sanitize Request Determines whether or not (Yes/No) the request should be sanitized if violations are detected. Sanitizing simply modifies the violation to make it harmless. The default is Yes.
Do Not Filter Query Strings Determines how query strings are filtered:
Property Name Description
Query String Defines a set of query strings (request parameters) that should not be filtered. If the query string is found in the request, it will be ignored and passed on to the request controller for normal processing.

Query strings accept wild cards to define generic requests. For example, "*nodemaintenance*" will ignore all requests with the word nodemaintenance in the query string.

Do Not Filter Parameters Determines how request parameters are filtered:
Property Name Description
ParameterDefines a set of request parameters that should not be filtered.
These parameters will be ignored when checking parameters for security violations. However, other parameters in the request will still be checked.
JS Injections Defines a set of JavaScript injections and associated replacements:
Property Name Description
JS InjectionDefines a set of JavaScript injections (or script parts) that may be expected in a request. This is the minimum script required to identify a security violation. All parameter values are checked for JS injections.
JS ReplacementIf "Sanitize Request" is enabled, this is the equivalent text modified to render the security violation harmless.
Check for JS Parameters Defined parameters checked for JS injections:
Property Name Description
ParameterSet of parameters that are checked for JS injections (in addition to the value).
Blocked GET Parameters Defined parameters blocked by a GET:
Property Name Description
ParameterSet of parameters that cannot be submitted using the GET method. They must be part of a POST request.
Protect from CSRF Attack "Yes" enables protection against Cross-Site Request Forgery (CSRF). This is implemented by generating a User session-specific csrf token. All form submissions have the csrf token as a parameter that is added on page load when forms are proxied. The value is checked on the server-side to match the token stored in the User's session.

An exception to this protection occurs when a page renders a form and submits it immediately before the page finishes loading. In this case, you must take either of the following actions:

Either

Change your code to include the csrf token by calling sapphire.page.addCSRFToken( oForm ).

or

Add the URL to the "URLs to Exclude from CSRF Protection" property below.

As an example of how this works, consider the following page:

<html>

<body onload='document.CSRF.submit()'>

<form action='http://hostname:8443/labvantage/rc?command=page&page=UserList' method='POST' name='CSRF'>

<input type='hidden' name='keyid1' value='admin'>

<input type='hidden' name='sdcid' value='User'>

</form>

</body>

</html>

Without CSRF protection, calling this page from the local machine when a User has already logged on will show the User List page. With CSRF protection, the violation is logged or an error is returned stating that the csrf token invalid, depending on whether the Violation Handling property (below) is set to "Ignore" or "Error".

URLs to Exclude from CSRF ProtectionAs noted above, if a page renders a form and submits it immediately before the page finishes loading, your code must either include the csrf token, or you must add the URLs to exclude from protection here.
NOTE: A hardcoded filter blocks certain patterns in the Request Controller command=file request. For example, a User cannot access the XML configuration files in the application deployment descriptors.
NOTE: To avoid clickjacking attacks, the Add Headers filter in the OOB LabVantage application deployment descriptor (web.xml) includes the X-Frame-Options HTTP response header. This header is set to SAMEORIGIN, which allows only the current site to render a page in a <frame> or an <iframe>. All other sites are blocked from framing the content in the browser. For more information, see https://www.owasp.org/index.php/Clickjacking_Defense_Cheat_Sheet.
Server Side File Browser Determines what Users can see and access in the LabVantage server-side file browser dialog. This creates a filter that blocks certain patterns in the Request Controller command=parameter pair (such as a WAR deployment descriptor).
Property Name Description
Show Full Path Determines the file path visible to the User:
Yes=Shows the file path.
No=Hides the file path and displays only the file location set in the File Location Policy. This is the default.
Allow Root Path Determines if the file path is passed into the file browser:
Yes=Passes the file path into the file browser.
No=Stops the path from being passed into the file browser. It then defaults to the file location set in the File Location Policy. This is the default.
Navigation Lock Determines how the User is allowed to navigate through the file browser file tree:
None=No navigation restrictions.
Lock Up=Prevents navigation up the tree. This is the default.
Full Lock=Prevents navigation up and down the tree.
File Locations=Allows navigation to only the file locations specified in the File Location Policy.
Groovy Script Filter Provides a mechanism to prevent Java packages, classes, and methods from being called from within Groovy scripts. At runtime, all class and method calls are checked against a "White List" (allowed calls) and "Black List" (disallowed calls). A call is allowed only if it is included in the White List and not included in the Black List. A security error is generated if a call is made on a Black List item. Security violations are rendered in the page when available. An error is generated in the log file based on the configuration of the "Violation Handling" collection (below).

After a Groovy script passes the security filter check for the first time, the unintercepted script is cached and used for subsequent run time script evaluation to avoid a runtime performance penalty.

Property Name Description
EnableEnables/disables the Groovy Script Filter.
White List Java package, class, or method that is allowed to be called in addition to these, which are always allowed: java.lang, java.util, java.math, sapphire, com.labvantage.sapphire, and all expression namespaces in the LV_Expression SDC.
Property Name Description
Allowed Java package, class, or methodThis can be a Java package name, fully-qualified Java class name, or a specific class method separating class and method with a hash character (#). Examples are java.io, java.io.File, and java.io.File#length.
Black List Java package, class, or method that is not allowed to be called in addition to these, which are never allowed: java.lang.System#exit, java.lang.Runtime, java.lang.Thread.
Property Name Description
Not allowed Java package, class, or methodThis can be a Java package name, fully-qualified Java class name, or a specific class method separating class and method with a hash character (#). Examples are java.io, java.io.File, and java.io.File#delete.
Query Where Filter "Query Where Filter" lets you define a "Black List" of SQL functions and database syntaxes and a "White List" of specific query where clauses. Query where clauses submitted from the browser client that contain any items from the "Black List" (which typically can be used in Boolean-based SQL injection to retrieve any column value using a hacking tool such as sqlmap) will result in the request being rejected for violation of security. To avoid falsely-rejected query where clauses, specifically allowed query where clauses can be configured in the "White List".
Property Name Description
EnableDetermines if query where clauses submitted by the client are checked against the "White List" and "Black List":
Yes= All query where clauses submitted by the client are checked to determine if any contain items defined in the "White List" and "Black List" (below). If any items in the "Black List" are found, the query where clauses are blocked. Specific query where clauses in the "White List" are not blocked.

In order to enable this feature and filter only client-side formed query where clauses, the "SQL Obfuscation" property in System Admin → System Configuration → Miscellaneous Options → RSet and SQL Control must be set to "Yes".

No=Query where clauses submitted by the client are neither checked nor blocked.
White List Specific query where clauses allowed in the request:
Property Name Description
Allowed Query Where ClauseQuery where clause allowed when submitted by the client.
Black List Items that are blocked:
Property Name Description
Not Allowed SQL Function or SyntaxSQL function or syntax to be blocked if it exists in query where clauses submitted by the client.
Violation Handling Determines what happens when a security violation occurs:
Property Name Description
NotificationDetermines if you want to receive security violation notificaitons via email.
Property Name Description
EmailDetermines if violations are sent by email:
Property Name Description
EnableYes = violations are sent by email. The default is No.
EmailToDestination email address.
EmailFromSource email address.
NOTE: Security violations are written to the security log for review. Processing is rejected and an appropriate error is returned to the client (depending on the source of the violation).
Java Based Attachments
Property Name Description
Java Attachments Role Select a Role. Any user who has been granted this role will be permitted to add JAR files to Attachment Handlers and/or Reports if enabled. If no role is specified, all users have this permission assuming this is enabled below.
Enable On Attachment Handlers A component of the SDMS Module, Attachment Handlers can use Java or Talend code to process Data Captures. If "No", any JAR files on an Attachment Handler will be ignored.
Enable on Reports Reports can use Java or Talend code to generate output. If "No", any JAR files on a Reports Library will be ignored.