The Security Policy determines the level of security to which the system is
configured.
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 | Type | Determines whether the "IP Address"
or "Host Name" is used to conduct host checking. | IP or Host Name | IP 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 Actions | As 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 Actions | Actions that can be called and processed if "Action
Processing" (above) is "Restricted":
Property Name |
Description | Action | Action that can be called and processed. |
| Allow Action Class Processing | Determines whether or not (Yes/No) Action classes
can be used in Action or Action Block processing calls. The default
is No. | Allow Unregistered SQL | Determines 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 Actions | Actions that can be called and processed if "POST
Action Processing" or "GET Action Processing" (above)
is "Restricted":
Property Name |
Description | Action | Action that can be called and processed. |
| Allow Action Class Processing | Determines 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 Processing | Determines 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 Actions | Actions that can be called and processed if "Action
Processing" (above) is "Restricted":
Property Name |
Description | Action | Action that can be called and processed. |
| POST Only | Determines whether or not (Yes/No) Ajax calls must
use the POST request method. The default is Yes. | Allow Action Class Processing | Determines whether or not (Yes/No) Action classes
can be used in Action or Action Block processing calls. The default
is No. | Allow Unregistered SQL | Determines 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 Actions | Actions that can be called and processed if "Action
Processing" (above) is "Restricted":
Property Name |
Description | Action | Action that can be called and processed. |
| Allow Action Class Processing | Determines whether or not (Yes/No) Action classes
can be used in Action or Action Block processing calls. The default
is Yes. | Allow Unregistered SQL | Determines 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 ConnectionId | Determines whether or not (Yes/No) the ConnectionId
is encrypted. The default is No. | Allow ConnectionId In Request | Determines 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 Session | Ensures 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 Session | Determines 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 Entries | Determines 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 | Enable | Determines 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 | Parameter | Defines 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 Injection | Defines 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 Replacement | If "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 | Parameter | Set 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 | Parameter | Set 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 Protection | As 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 | Enable | Enables/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 method | This 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 method | This 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 | Enable | Determines 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 Clause | Query where clause allowed when submitted by
the client. |
| Black List | Items that are blocked:
Property Name |
Description | Not Allowed SQL Function or Syntax | SQL 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 | Notification | Determines if you want to receive security violation notificaitons via email.
Property Name |
Description | Email | Determines if violations are sent by email:
Property Name |
Description | Enable | Yes = violations are sent by email. The
default is No. | EmailTo | Destination email address. | EmailFrom | Source 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. |
|