0

System Configuration Security Settings

  • updated 2 yrs ago

Description

The table below identifies the settings found on the Security tab in the System Configuration package. Changing these settings arbitrarily can have important ramifications on the running of your application, so we recommend that you do not make changes before you discuss them with LogicNets Support.

Parameter Options Details
Logicnet visibility
(default: internal)
  • public
  • internal
  • private
This determines the default visibility of all new logicnets created in the system, and you can make any specific logicnet more or less visible by going to the logicnet Details tab.
  • public: This allows direct external access by the browser (e.g. via openlnet call).
  • internal: This allows access by any logicnet call node.
  • private: This allows access only from call nodes in the same project/package/framework.
Web-security level
(default: safe)
  • default (safe)
  • strict
  • safe
  • develop
  • none
The web-security level dictates the treatment of web functions, print functions, and logging, specified in the table below:



In LogicNets releases prior to 7.4 the default web-security level is "develop".
Entropy (default 16) Integer This is the number of random bytes the system should use for the session ID and session file name.

When the entropy is low the session id and session pin id are less unique, and are easier to compromise. Entropy that is too high slows down the system, since generating such ids is time consuming.
Enforce HTTPS
(default: yes)
  • Default
  • No
  • Yes
LogicNets recommends that you enforce HTTPS. If enabled, the system redirects an incoming HTTP request to an HTTPS request.

This should only be disabled if HTTP is required specifically.
Disable session pinning (default: Yes)
  • Default
  • No
  • Yes
To avoid sessions being stolen or taken over, the LogicNets runtime engine uses session pinning.

Note: Session pinning only works with HTTPS.
Security cookies 'samesite' attribute (default: Lax)
  • Default
  • None
  • Lax
LogicNets uses cookies to work properly. With the samesite cookie setting, a web server tells the browser when a cookie will be sent to the server and when it will not be sent. Until 2020, most browsers used 'lax' as default when no samesite attribute was set. Since 2020, this has been changed to 'strict'. Most LogicNets applications will work properly with the default ('lax').

If an application is embedded in an iframe that runs in a different domain, set the option to 'None'.

For more general information, see https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Set-Cookie/SameSite.
X-Frame-Options (default: Same origin)
  • Default
  • Same origin
  • Deny
  • Allow all
Use the X-Frame-Options HTTP response header to indicate whether or not a browser should be allowed to render a page/application from this instance in a <frame>, <iframe>, <embed> or <object>. This allows you to avoid click hijacking attacks by ensuring that your content is not embedded into other sites.

For more information, see
Access-Control-Allow-Origin   The Access-Control-Allow-Origin header is included in the response from one website to a request originating from another website, and it identifies the permitted origin of the request. A web browser compares the Access-Control-Allow-Origin with the requesting website's origin and permits access to the response if they match. This tells the browser whether it is allowed to access resources in your applications, such JS, web APIs, and images, from other websites.

For more information, see
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Access-Control-Allow-Origin

Defaults to: *
Access-Control-Allow-Headers   The Access-Control-Allow-Headers response header is used in response to a preflight request, which includes the Access-Control-Request-Headers to indicate which HTTP headers can be used during the actual request. This information can be used by the client or browser to know which headers can be consumed safely. Passing data via other headers may result in exposing to the server sensitive information that is not processed correctly or safely. This could be inadvertently logged or stored in an insecure location.

For more information see: Defaults to: content-type, authorization, x-requested-with, ln-auc-contract-number, ln-auc-contract-consumer
Content Security Policy (CSP)   CSP helps to avoid malicious code or content being inserted in the LogicNets application.

See also https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP.

Defaults to: default-src 'self'; script-src 'self' www.googletagmanager.com www.google-analytics.com www.googleadservices.com http://localhost:41666 'unsafe-inline' 'unsafe-eval'; style-src 'self' 'unsafe-inline'; img-src 'self' 'unsafe-inline' secure.gravatar.com api.atlassian.com i2.wp.com; connect-src 'self' www.googletagmanager.com http://localhost:41666 ws://localhost:41666
Non-approved redirect-uris mode (default: log)
  • Default
  • Block
  • Log only
  • "log only": When you use a URL that is not whitelisted and the user follows the redirect, the system logs the error "Illegal redirect uri specified" but continues with the redirect.
  • "block" (recommended): When you use an external URL that is not approved and the user follows the redirect, the system logs an error and shows the user an error message, such as "the specified redirect_uri is not whitelisted". The system will not follow the redirect.

Future releases will likely set block as the default setting.

Approved redirect-uris
  • Redirect URI
  • Description
  • Created by
This mode specifies that all URIs listed here are whitelisted, and the Redirect URL column can contain the following: You can use wild cards in the host name; for example, to whitelist all sub-domains you can use the following URI: https://*.mydomain.com. For security reasons it is better to use full URLs as much as possible.

The description and created by fields are not mandatory and you can use them for your own information.
Whitelisted directories One directory per input box This option lists the folder and files that parts in your application can access on your server. For additional information, see Whitelisting Directories.
Use OS Certificate Store
(default: 1)
  • Default
  • Yes (1)
  • No (0)
Outbound web API calls can use HTTPS. HTTPS itself encrypts the connection, and it can also verify the hostname.

To do this properly the remote certificate needs to be checked against a root CA certificate. These root certificates can be installed manually, but you can also use the Windows Certificate store. For more information, see Certificate Verification.
Reply Oldest first
  • Oldest first
  • Newest first
  • Active threads
  • Popular
Like Follow
  • 2 yrs agoLast active
  • 70Views
  • 3 Following

Home