Security Considerations

Genesys makes the following recommendations to improve security in our web-based applications. We recommend you implement these methods of securing your system.

Cross-Frame Scripting or clickjacking

Cross-Frame Scripting (XFS) vulnerability can allow an attacker to load the vulnerable application inside an HTML iframe tag on a malicious page. Clickjacking is an attack that occurs when an attacker uses a transparent iframe in a window to trick a user into clicking on a Call to Action (CTA), such as a button or link, to another server in which they have an identical looking window. The attacker in a sense hijacks the clicks meant for the original server and sends them to the other server. This is an attack on both the visitor themselves and on the server.

To prevent cross-frame scripting or clickjacking, set the X-Frame-Options value to one of the following in your web server configuration file:

• DENY: Deny all attempts to frame the page.

• SAMEORIGIN: The page can be framed by another page only if it belongs to the same origin as the page being framed.

• ALLOW-FROM origin: Developers can specify a list of trusted origins in the origin attribute. Only pages on origin are permitted to load this page inside an iframe.

Note: The server parameter X-Frame-Options can specify the value of the X-Frame-Options header for ICWS responses. You can use the expected values of DENY or SAMEORIGIN or set to NONE to indicate that the header value should not exist at all.

See the instructions and examples for IIS, Apache, and Nginx.

Prevent directory scan

Directories that are restricted to certain users can be discovered during a directory scan. Risks associated with an attacker discovering a directory on your application server depend on the type of directory and the types of files it contains. The primary threat, other than accessing files containing sensitive information, is that an attacker can use the information to perform other types of attacks. Restrict access to important directories or files by adopting a "need to know" requirements before granting access for both the document and the server root. Turn off features such as Automatic Directory Listing that can be used by an attacker in formulating or conducting an attack.

Note: In addition to the recommended configuration changes, you should also assign the appropriate ACLs (Access Control Lists) to the directories on the web server used by your organization.

• For IIS, to prevent an attacker from executing a Directory Enumeration scan, set directoryBrowse to false in your web server configuration file. For instructions, see disable directory listing.

• For Nginx, set autoindex to off. You can apply the rule to all directories or specify the directory names you do not want listed. For instructions, see block all or some directories from directory scanning.

• For Apache, set DirectoryMatch Options to FollowSymLinks and create a .htaccess file in the related application directory. For instructions, see disable directory scanning.

File Uploads

Interaction Connect users are blocked from including the following types of executable files (exe, .sh, and .js) when creating Personal Responses or using Response Management in an email interaction.  For more information, see Create Personal Responses in the Interaction Connect help.

Interaction Connect does not examine email interactions or file attachments for malicious intent. It is your responsibility to configure your email server to block attacks.

• Adopt a strict file upload policy that prevents malicious material from being uploaded via sanitization and filtering. Limit the types of files that can be uploaded.

• Restrict web users from accessing the server directory.  

Enable Strict Transport Security

HTTP Strict Transport Security (HSTS) is a policy mechanism that helps to protect websites against man-in-the-middle attacks such as protocol downgrade attacks and cookie hijacking. It allows web servers to declare that web browsers should automatically interact with web servers only through HTTPS connections, which provide Transport Layer Security (TLS/SSL), unlike the insecure HTTP used alone.

The HSTS Policy is communicated by the server to the user agent via an HTTP response header field named "Strict-Transport-Security". HSTS Policy specifies a period during which the user agent should only access the server in a secure fashion. Websites using HSTS often do not accept clear text HTTP, either by rejecting connections over HTTP or systematically redirecting users to HTTPS.

To add the HSTS header in all the responses, the following header details need to be configured in webserver. This will enable 'HSTS' to all responses that the server sends.

'Strict-Transport-Security': 'max-age=31536000; includeSubDomains; preload;'  

Configuring HSTS header in IIS / NGINX / Apache

• To configure HSTS header in IIS, open HTTP response header and add the following custom header in web.config file.

<system.webServer>

    ...

<httpProtocol>

 <customHeaders>

<add name="Strict-Transport-Security" value="max-age=31536000; includeSubDomains; preload"/>

</customHeaders>

</httpProtocol>

   ...

</system.webServer>

 

•  To set the HSTS header in NGINX, include an 'add_header line' in your server block:

• To add the HSTS header in Apache, include the Header given below to the appropriate VirtualHost section: