Assets Server security features overview

This article describes the security features for Assets Server. Use it as a quick reference to find out if any of the issues affect your Assets Server environment.

Important: The default configuration settings of Assets Server are aimed to keep the system as secure as possible. Change these settings with care and at your own risk.

Security configuration overview

The following is an overview of the security configuration of Assets Server.

Data changing APIs only accept POST requests

Because of improved security measures in the REST API of Assets Server, all data changing APIs only accept POST requests, not GET requests. Also, the POST request needs to include a cross-site request forgery (csrf) token.

The csrf token is a unique code which, by including it in the request, also makes the POST request unique and therefore much more secure.

The csrf token is obtained by first logging in to Assets Server through a POST request. The response that is received will include the csrf token which can then be used in subsequent POST requests as a http header:

"X-CSRF-TOKEN: <some_csrf_token>"

For more information including examples and a list of affected APIs, see Assets Server REST API - Performing a POST request with a csrf token.

Cross-origin protection

AJAX calls to Assets Server are blocked by Web browsers if the Web page that is making the call is not on one of the configured domains. By default, only the server domain is allowed.

Example: If Assets Server is running on http://assets-server.yourdomain.com and you want to perform a cross-domain REST search from a Web page hosted on http://www.yourdomain.com, the Web browser will not perform the request.

Note: The same origin policy prevents a document or script loaded from one origin from getting or setting properties of a document from a different origin. (See mozilla.org: Same-origin policy.)

For more information, see Assets Server API - cross origin.

Anti-clickjacking headers

Anti-clickjacking headers limit how the Web client is allowed to be loaded in iframes or other frames.

By default, the Web client is only allowed to be loaded in a frame originating from the same domain as the server.

It is however also possible to load the Web client from another domain than the server.

To do this, configure the following options in the cluster-config.properties.txt file:

• X-Frame-Options. The X-Frame-Options HTTP response header can be used to indicate whether or not a Web browser should be allowed to render a page in a <frame>, <iframe> or <object>. Sites can use this to avoid clickjacking attacks by ensuring that their content is not embedded into other sites. It is mainly used for older Web browsers.

security.antiClickjackHeadersXFrameOptions=SAMEORIGIN

Notes:

• Default value: SAMEORIGIN
• Only one domain can be specified
• For this to work, set security.antiClickjackHeaders=true.

Specify a domain as follows: ALLOW FROM http://example.com

For more information, see Mozilla Developers Network - X-Frame-Options.

• ContentSecurityPolicy. Allows the specified domain to have the server to be shown in an iframe. It is mainly used by modern Web browsers.

security.antiClickjackHeadersContentSecurityPolicy=self

Notes:

• Default value: self
• Multiple domains can be specified
• For this to work, set security.antiClickjackHeaders=true.

Specify a domain as follows: http://example.com http://domain.com

Each domain should be separated with a space.

For more information, see Mozilla Developers Network - Content Security Policy (CSP).

HTML previews

Previews of Web pages (files in .html format) that are stored in Assets Server are disabled by default. They can be enabled with limited functionality or with full functionality, as described in the following sections.

Preventing HTML previews from injecting malicious code

The option named 'security.sandboxPreviews' serves all asset/preview files with a Content-Security-Policy header to prevent malicious code from being injected on the page through the file in browsers.

security.sandboxPreviews=true

For more information see the Content Security Policy.

Enabling previews of HTML files

Previews of Web pages (files in .html format) that are stored in Assets Server are disabled by default.

Note: Previews of Microsoft Office documents are still shown despite being in HTML format.

Previews for these files can be enabled by setting the option named 'security.enableHtmlPreviews' to 'true'.

security.enableHtmlPreviews=true

This option works together with the option 'security.sandboxPreviews' (see above): if 'security.enableHtmlPreviews' is enabled, the HTML previews are still secured if 'security.sandboxPreviews' is also enabled. However, not all Web browsers support this.

Log-in blocking

The number of times that a user can attempt to log in is limited.

When incorrect credentials are entered a few times, logging in through the user’s IP address will be blocked for a short period of time.

Various options for this feature can be configured, see the 'log-in throttling' options below.

Security options that may affect your Assets Server setup

The following lists some of the security issues that may affect your Assets Server environment.

Limited functionality for HTML pages loaded outside the Web client

HTML pages that are stored in Assets Server will have limited functionality when they are loaded outside the Web client for use in banners, forms or other objects that depend on JavaScript or external sources. This is because of the Content Security Policy headers which limit what the object is allowed to do. (See HTML previews above.)

Web client prevented from loading in a frame or iframe

If your Assets Server installation is used in combination with a solution that loads the Web client in a frame or iframe, the anti-clickjacking headers will prevent the Web client from being loaded, thereby breaking the integration. (See HTML previews above.)

No preview for Word files and Web pages when Web client is served from a different domain than Assets Server

If your Web client is served from a different domain than Assets Server, the anti-clickjacking headers will prevent previews for Word files (in .doc format) and Web pages (in .html format). (See Anti-clickjacking headers above.)

Additional security settings

The following sections describe additional security settings.

Clickjacking: Prevent clickjacking when viewing Web pages

The loading of Web pages in iframes is blocked or only allowed when the page is from the same domain. All requests will get an X-Frame-Options header added to them to combat clickjacking.

This is controlled through the following option:

security.antiClickjackHeaders=true

The security.antiClickjackHeaders option also adds the 'frame-ancestors' directive to the Content-Security-Policy header, next to the X-Frame-Options header, to all requests.

Domains: Controlling which domains can make calls to Assets Server

As a way of securing on-premise installations, the default value of the 'AccessControlAllowOrigin' option does not allow any domain to make calls to Assets Server.

security.accessControlAllowOrigin=

To have a domain connect to Assets Server, add any origin address to the security.accessControlAllowOrigin property.

For more information, see Assets Server API - cross origin.

Log-in throttling based on IP addresses

Log-in throttling (temporarily blocking a user log-in after a defined number of failed attempts) now also works purely on IP addresses and not just on combinations of user name and IP address.

Log-in throttling: Defining where to retrieve the address of a request from

By default, Assets Server uses the remote address of a request.

When Assets Server is running behind a load balancer, the IP address of the remote host of a request may be retrieved from the request header X-Forwarded-For by setting the option named 'security.runningBehindLoadBalancer' to 'true'.

security.runningBehindLoadBalancer=true

Caution: Beware that enabling this option when Assets Server is not running behind a load balancer makes it possible for an attacker to circumvent the IP-based log-in throttling by "faking" his IP using the header. (See the option 'security.loginThrottle.maxFailedIpAttempts' below.)

Log-in throttling: Setting the number of log-in attempts before log-in throttling should take place

The number of log-in attempts for a combination of IP address and user name that are allowed before log-in throttling takes place can be set through the option named 'security.loginThrottle.maxFailedUsernameAttempts'.

This is separate from IP-based blocks and is generally set lower than the option 'maxFailedIpAttempts' to make sure that when users share the same IP address, the failed attempt of one user does not affect all other users.

security.loginThrottle.maxFailedUsernameAttempts=3

Log-in throttling: Setting the number of failed attempts for a single IP address

The number of failed log-in attempts for a single IP address before log-in throttling for that IP address takes place can be set through the option named 'security.loginThrottle.maxFailedIpAttempts'.

security.loginThrottle.maxFailedIpAttempts=20

Log-in throttling: Defining the minimum time a user is blocked

When the log-in attempts of a user have failed (defined through the options named 'maxFailedUsernameAttempts' or 'maxFailedIpAttempts'), the minimum time that a user has to wait (in seconds) is set through the option named 'security.loginThrottle.minWaitTimeSeconds'.

The blocked time increases when more failed attempts occur, up to the maximum number of seconds set through the option named 'security.loginThrottle.maxWaitTimeSeconds'.

security.loginThrottle.minWaitTimeSeconds=1

Log-in throttling: Defining the maximum time a user is blocked

When the log-in attempts of a user have failed (defined through the options named 'maxFailedUsernameAttempts' or 'maxFailedIpAttempts'), the maximum time that a user has to wait (in seconds) is set through the option named 'security.loginThrottle.maxWaitTimeSeconds'.

security.loginThrottle.maxWaitTimeSeconds=600

Log-in throttling: Excluding IP-addresses

When log-in throttling is enabled through the option named 'security.loginThrottle.maxFailedIpAttempts', any trusted IP addresses that should never be blocked can be white-listed by using the option named 'security.loginThrottle.ipWhiteList'.

Use this for example to exclude the Studio Server IP address where many different user requests come from the same source.

security.loginThrottle.ipWhiteList=0:0:0:0:0:0:0:1

Note: Separate users on this IP may still be blocked when the option 'security.loginThrottle.maxFailedUsernameAttempts' is exceeded.

Logging-in is temporarily blocked after 3 failed attempts

When a user tries to log in 3 times and fails on each attempt, further log-in attempts are temporarily blocked.

Session cookies: Issuing HTTPS-only session cookies

Assets Server can be configured to issue HTTPS-only session cookies by adding the 'Secure' directive to these cookies.

Cookies with the 'Secure' directive are only sent by Web browsers when they connect to the server over HTTPS. This prevents the session cookie from being exposed over an unencrypted channel when for example a user's Web browser is (un)intentionally directed to HTTP instead of HTTPS.

session.cookie.secure=auto

Possible values:

• enabled
• disabled
• auto. Default setting. Is enabled if HTTP is disabled through the 'httpEnabled' setting, else it is disabled.

Note: When a HTTPS terminating proxy or load balancer is used in front of Assets Server and the connection between them is HTTP, set the option to 'enabled'.

Session cookies: preventing cookies from being sent with cross-origin requests

To provide some protection against cross-site request forgery attacks (CSRF), the cookie can be prevented from being sent with cross-origin requests.

session.cookie.sameSite

Possible values:

• strict. Cookies will only be sent in a first-party context and not be sent along with requests initiated by third-party websites. The browser sends the cookie only for same-site requests (meaning: requests originating from the same site that set the cookie). If the request originated from a different URL than the current one, no cookies with the SameSite=Strict attribute are sent.

• lax. Cookies are allowed to be sent with top-level navigation and will be sent along with GET requests initiated by a third party website.

• none. The browser sends the cookie with both cross-site and same-site requests.

Note: For the changed value to take effect, the user needs to log out and log in again.