Edge Documentation

Latest revision as of 11:07, 2 February 2015

Overview

The security of our products, and the security features provided by the products, is of great importance to Edge Technologies. Our commitment is realized through the adoption of best practice development processes, staying abreast of known vulnerabilities in components used in the products, and addressing or enhancing the product security features based on feedback from customers.

Our software is deployed in many different scenarios such as Internet facing portals, internal corporate usage, and secure environments with multi-factor authentication. One key reason for this is the ability of enPortal to harden proxied web applications such as restricting who and what someone can access - something the proxied web application may not be able to provide itself. enPortal has even been used to address known vulnerabilities in proxied web applications such as Cross-site scripting (XSS) if the vendor of that application is not able to address it.

AppBoard provides limited views into various data sources, allowing for tailored information to be shown based on the role of a user. This may not be possible if users would have direct access to the data, or the native application to access this data doesn't provide any kind of restriction mechanism.

Contacting Edge

To report security concerns or issues regarding Edge products, please contact Technical Support.

Security Patches

If Edge becomes aware of a vulnerability in a component used by our products, or within the product itself, depending on the severity we will either produce a patch for existing deployments or address the issue in the subsequent product release.

Passwords & Secrets

enPortal and AppBoard need to store passwords or secrets for a number of different purposes where the passwords need to be reused:

Single-Sign-On (SSO) tokens for proxied web applications (if not using auth pass-through)
access credentials if using an external configuration database
access credentials for LDAP repositories
access credentials for AppBoard Data Sources
AppBoard session variables set encrypted

In the above situations passwords and secrets are stored encrypted using AES (approved by NIST). By default 128-bit keys are used however 192-bit and 256-bit keys are supported if using OpenJDK or the Unlimited Strength Java Cryptography Extension (JCE) is installed for Oracle Java. Best practices are to create a new encryption key after installing the product.

Also, for users that authenticate directly with the product versus an external authentication provider then a salted one-way hash is used to store the password. From enPortal 5.5.2 the hashing algorithm used is SHA-256 (designed and published by NIST), previous versions used SHA-1.

Features & Recommendations

Edge Technologies enPortal and AppBoard have a common code base and the following set of features and recommendations apply to both unless otherwise indicated. Although we endeavour to provide a secure configuration out-of-the-box, due to interoperability and some items relying on specific configuration, it is recommended to be familiar with all the security related features and determine what suits your organization best.

Run as non-root on Linux/UNIX systems. This is the default configuration. Running as root is possible, for instance to bind to port < 1024, however in this case it's recommended to use JSVC which can be used to bind to the port and give up privileges, or some external mechanism to act as the end point such as a load balancer which talks to the server on a port > 1024.
enable SSL/TLS (HTTPS). The products ship with a self-signed certificate to enable for easy testing, however this certificate should be replaced as soon as possible.
Ensure the latest supported version of Java is used on the server.
Implement system-wide or domain-specific password policies to ensure end-users have secure passwords.
Use multi-factor authentication. For example, we have customers using CAC that makes use of HTTPS client authentication. Other options are possible via our extensible authentication handlers.
Change the default encryption key as mentioned in the Passwords & Secrets section above. Refer to the KeyCreate option in the Portal Commands documentation.
If upgrading from a version prior to 5.5.2 then existing local user passwords would have been hashed using SHA-1. These cannot be automatically upgraded and it is recommended to change / force-change all local user passwords which will then be stored using SHA-256. This is not necessary for user accounts authenticated using external authentication providers such as Active Directory or any LDAP based provider as these passwords are not stored locally.
Disable the default accounts. Administrator privileges can be assigned to other users as needed (/portalAdministration role)
Customize the login page. This can be used to disable form pre-fill or to provide/remove content as deemed necessary.
Restrict access to the host. Clients only require access to the single listening port of the server - and this should be the only port open to the clients. The server itself will need access to the proxied web applications (enPortal) and any data sources (AppBoard).
Concurrent user sessions. By default a user can be logged in multiple times, however this can be changed so that only one session can exist for a given user. This really depends on your organizations usage and security policies.
use the enPortal CRS to virtually harden proxied web applications. This may be to completely restrict the content that's exposed to users or even to require authentication when the web application doesn't support it.
By default user and domain credentials are echoed in HTTP responses (but not the password). Some security analysis tools will identify this as a security vulnerability, and users can disable this functionality by editing/adding [INSTALL_HOME]/server/webapps/enportal/WEB-INF/config/custom.properties and adding the line jsp.usercookies=false.
Cross-site scripting (XSS) and Vulnerability Tool Hardening:
- enPortal core components are protected by performing input validation and a configurable set of rules checks all client requests (query, headers, body) for malicious matches.
- The CRS can be used to provide protection to proxied web applications. Some default handlers are included with enPortal but disabled by default.
- Refer to the Managing XSS Rules page for more information.
SSL Browser Caching
- By default, Appboard now marks all content (excpet for images, CSS, or Javascript) as non-cacheable, which is a suggestion to browsers not to retain such content for efficiency purposes. There is a property (request.ssl.cache, specified in WEB-INF/config/config.properties) which can be toggled to "true" and will cause XML, HTML, and SWF content to be cached, as well. Setting this to "true" may slightly increase client performance with the increased risk of possibly sensitive content being retained by browsers.

@@ Line 1: / Line 1: @@
 [[Category:enPortal 5.5]]
-{{DISPLAYTITLE:enPortal Security}}
+{{DISPLAYTITLE:Product Security}}
+== Overview ==
-=== Input validation ===
+The security of our products, and the security features provided by the products, is of great importance to Edge Technologies. Our commitment is realized through the adoption of best practice development processes, staying abreast of known vulnerabilities in components used in the products, and addressing or enhancing the product security features based on feedback from customers.
-Part of Edge enPortal’s cross-site scripting protection involves checking request parameters for validity against a list of patterns and it will reject requests with disallowed characters in a URL (or decoded form of the URL).
+Our software is deployed in many different scenarios such as Internet facing portals, internal corporate usage, and secure environments with multi-factor authentication. One key reason for this is the ability of enPortal to harden proxied web applications such as restricting who and what someone can access - something the proxied web application may not be able to provide itself. enPortal has even been used to address known vulnerabilities in proxied web applications such as Cross-site scripting (XSS) if the vendor of that application is not able to address it.
-This approach can produce occasional  false positives since there are applications that actually expect characters that do not comply with the RFC.  All aspects of the HTTP request are tested, including request, headers, and body. Captures will cause display of HTTP 500 responses. Updates to the output encoding scheme are also implemented to improve system efficiency and to eliminate XSS attacks. All attacks are logged in <tt>PORTAL_HOME/logs/jspsystem.log</tt>. The default behavior is to deny requests that contain malicious characters if the page that initiated the request is not from the portal server. The settings for XSS request validations are in the <tt>PORTAL_HOME/config/config.properties</tt> file.
-In instances where the application requires/expects these special characters, the portal administrator/integrator is required to place an override for the matching URL, header, referrer, query field pattern.  Otherwise, the portal simply denies the request and logs the failure.
+AppBoard provides limited views into various data sources, allowing for tailored information to be shown based on the role of a user. This may not be possible if users would have direct access to the data, or the native application to access this data doesn't provide any kind of restriction mechanism.
-The following documents some of the validation rule syntax:
-<i>Global Input Validation Rules
+== Contacting Edge ==
-These Rules define an ordered set of request validators that search for<br>
+To report security concerns or issues regarding Edge products, please contact [[support/technical_support|Technical Support]].
-cross-site scripting attacks within input characters.  The ordering <br>
-establishes a priority for evaluation, allowing general validation rules<br>
-to be skipped by defining rules that are evaluated before the general case.<br>
-Specific Usage: These rules are processed in order, based on the alphanumeric<br>
+== Security Patches ==
-ordering of the $INSTANCEKEY value.  To override the general validation rule,<br>
-define an earlier validator rule that matches the requests whose input<br>
-validation is to be bypassed.</i> <br>
-<pre>
-Syntax: for request.validator property namespace:
-.log_attacks:  Global flag for logging attacks which result in terminated
+If Edge becomes aware of a vulnerability in a component used by our products, or within the product itself, depending on the severity we will either produce a patch for existing deployments or address the issue in the subsequent product release.
-          requests.  Default is on.
-.log_info:     Global flag for info logging of the request.validator
-          Note: This is very noisy and will fill up the jsp-system.log
-.$INSTANCEKEY: defines an individual rule, using the following subfields:
- .if.request.matches:   A precondition that matches against the request string
-                type: regular expression
- .if.referer.indicates:   A precondition for the HTTP Referer Header of requests.
-                Qualifies are comparison of the host between the request's
-                URL and the request's referer header URL.
-                type: options are [ SELF ], whereSELF is default
-                SELF indicates that the HTTP page that initiated
-                this request was originally loaded from this
-                server.
-.if.header.$NAME.matches  A precondition tied to an HTTP Request's header
-                type: regular expression
-                $NAME: indicates the name of the HTTP Request
-                header that will be tested for matches
-.then:      Selects the behavior that this rule proceeds with when all of
+== Passwords & Secrets ==
-          the conditionals evaluate positively
-          type: options are [ ALLOW, TESTFIELDS ], where ALLOW is default
-          - ALLOW : skips remaining evaluation rules, allowing the request
-          - TESTFIELDS : activates full examination of request fields
-          using the expression declared in this rules field.matches
-.field.matches:  A XSS attack search expression evaluated on a request's fields
+enPortal and AppBoard need to store passwords or secrets for a number of different purposes where the passwords need to be reused:
-         type: regular expression
-         All fields of a request are tested against this expression
-         in order to identify characters indicating an XSS attack
-.field.onMatch:  Selects the behavior for cases where the evaluation of the
-         field.matches expression finds a match.
-         type: options are [ DENY ], where DENY is the default
-         DENY indicates that the http request will not be processed
-</pre>
-=== Credentials for SSO ===
+* Single-Sign-On (SSO) tokens for proxied web applications (if not using auth pass-through)
+* access credentials if using an external configuration database
+* access credentials for LDAP repositories
+* access credentials for AppBoard Data Sources
+* AppBoard session variables set ''encrypted''
-The enPortal proxied content requires Single Sign-On (SSO) to back-end applications to be provisioned.  When the enPortal password can be used for back-end applicaiton login, it will be stored in memory for the session only and used.  For many cases when a different password must be sent to the back-end application, enPortal handles SSO password storage by using a crypto package for these passwords.  enPortal requires an interface that allows it to extract the unencrypted form of the password to submit on the request to the back-end web application.
+In the above situations passwords and secrets are stored encrypted using AES (approved by [http://www.nist.gov/ NIST]). By default 128-bit keys are used however 192-bit and 256-bit keys are supported if using OpenJDK or the ''Unlimited Strength'' Java Cryptography Extension (JCE) is installed for [http://www.oracle.com/technetwork/java/javase/downloads/index.html Oracle Java]. Best practices are to create a new encryption key after installing the product.
-Additionally, the enPortal distribution includes a default encryption key that is used for securely storing authentication passwords in the database and XML files. The customer may choose to add a level of security to the system by using included tools to create a custom key for encrypting passwords.  External application passwords used for Single Sign-On are encrypted by enPortal using strong encryption (the NIST sponsored AES algorithm). Creating a custom key will enhance security by creating a custom private key applicable to only the individual system.
+Also, for users that authenticate directly with the product versus an external authentication provider then a salted one-way hash is used to store the password. From enPortal 5.5.2 the hashing algorithm used is SHA-256 (designed and published by [http://www.nist.gov/ NIST]), previous versions used SHA-1.
+== Features & Recommendations ==
-=== Secure configuration ===
+Edge Technologies enPortal and AppBoard have a common code base and the following set of features and recommendations apply to both unless otherwise indicated. Although we endeavour to provide a secure configuration out-of-the-box, due to interoperability and some items relying on specific configuration, it is recommended to be familiar with all the security related features and determine what suits your organization best.
-Edge enPortal supports a number of configurations to aid in hardening the system. For instance, on UNIX, enPortal uses a secondary account (portal:portal) which is used to run the processes.  Only when a privileged port is required does the customer require running the application as root.  enPortal downgrades to the portal account when starting up the portal, jsp, and web worker processes.  Only the initial web startup request is run as root.
+# Run as non-root on Linux/UNIX systems. This is the default configuration. Running as root is possible, for instance to bind to port < 1024, however in this case it's recommended to use JSVC which can be used to bind to the port and give up privileges, or some external mechanism to act as the end point such as a load balancer which talks to the server on a port > 1024.
+# enable SSL/TLS (HTTPS). The products ship with a self-signed certificate to enable for easy testing, however this certificate should be replaced as soon as possible.
-The following additional details allow the enPortal administrator to further lock down the system:<br><br>
+# Ensure the latest supported version of Java is used on the server.
-#Ability to setup and configure password policy, including a number of security options including forcing account locks after consecutive failures.<br><br>
+# Implement system-wide or domain-specific password policies to ensure end-users have secure passwords.
-#Ability to only allow a single concurrent session per user; to prevent users from logging in at the same time from multiple places.<br><br>
+# Use multi-factor authentication. For example, we have customers using CAC that makes use of HTTPS client authentication. Other options are possible via our extensible authentication handlers.
-#Disabling domain and user cookies used to pre-fill login windows.<br><br>
+# Change the default encryption key as mentioned in the ''Passwords & Secrets'' section above. Refer to the <tt>KeyCreate</tt> option in the [[enportal/5.5/admin/system_administration/CLI_utilities#Portal_Commands|Portal Commands]] documentation.
-#Updating custom login pages and disabling default login pages which remember user, domain, and password information from remembering selections.<br><br>
+# If upgrading from a version prior to 5.5.2 then existing local user passwords would have been hashed using SHA-1. These cannot be automatically upgraded and it is recommended to change / force-change all local user passwords which will then be stored using SHA-256. This is ''not'' necessary for user accounts authenticated using external authentication providers such as Active Directory or any LDAP based provider as these passwords are not stored locally.
-#Disabling default accounts, creating custom administration accounts, or configuring specific resources with /portalAdministration rights (role assignment).<br><br>
+# Disable the default accounts. Administrator privileges can be assigned to other users as needed (<tt>/portalAdministration</tt> role)
-#Reviewing any applications integrated in the portal which do not provide security based on authorization, and adding appropriate CRS access control rules.<br><br>
+# Customize the login page. This can be used to disable form pre-fill or to provide/remove content as deemed necessary.
-#Determine all the ports needed to be open; lock down all not listed here:<br>
+# Restrict access to the host. Clients only require access to the single listening port of the server - and this should be the only port open to the clients. The server itself will need access to the proxied web applications (enPortal) and any data sources (AppBoard).
-#*Between the web clients and the portal server: port 443 (Apache),
+# Concurrent user sessions. By default a user can be logged in multiple times, however this can be changed so that only one session can exist for a given user. This really depends on your organizations usage and security policies.
-#*Between the portal jsp server and the backend applications.  Typically need access over http to the server and port the backend application is running on.
+# use the enPortal CRS to virtually harden proxied web applications. This may be to completely restrict the content that's exposed to users or even to require authentication when the web application doesn't support it.
-#*Between the portal serverapp process and the database.   The server and port the database is running on.<br><br>
+# By default user and domain credentials are echoed in HTTP responses (but not the password). Some security analysis tools will identify this as a security vulnerability, and users can disable this functionality by editing/adding <tt>[INSTALL_HOME]/server/webapps/enportal/WEB-INF/config/custom.properties</tt> and adding the line <tt>jsp.usercookies=false</tt>.
-#Internal Portal Ports needed to be locked down to prevent access from outside: 8200 (between apache and tomcat), 8300 (between tomcat and portal server), along with the port between database and portal server.<br><br>
+# Cross-site scripting (XSS) and Vulnerability Tool Hardening:
-#Tomcat is secured because it does not communicate with outside world (it is a not standalone web server).<br><br>
+#* enPortal core components are protected by performing input validation and a configurable set of rules checks all client requests (query, headers, body) for malicious matches.
-#Apache is secured with latest apache, openssl, mod_jk build, plus following update to portal’s custom-httpd.conf:<br>
+#* The CRS can be used to provide protection to proxied web applications. Some default handlers are included with enPortal but disabled by default.
-#*KeepAliveTimeout set to 15
+#* Refer to the [[enportal/5.5/admin/system_administration/security/xss_rules|Managing XSS Rules]] page for more information.
-#*LimitRequestBody 512000
-#*ServerTokens Prod
-#*apache conf directory permission check: to be performed as part of the OS lockdown
-#*apache bin directory permission check: to be performed as part of the OS lockdown
-#*apache log directory permission check: to be performed as part of the OS lockdown
-#*remove manual from apache install: to be performed as part of the OS lockdown<br><br>
-# XSS and Vulnerability Tool Hardening:
-#* By default, some trust is associated with HTTP requests whose Referer tags indicate local origination. This is conifgurable via <i>Rule 77</i> in <nowiki>webapps/enportal/WEB-INF/config/config.properties</nowiki> which is enabled by default. However, while browsers do not allow changing the Referer dynamically without the user intentionally setting a new value, the Referer in the HTTP request is spoofed by most security attack tools and would yield failed test results if local origin Referers are trusted. Although all XSS issues (that are known) have been dealt with on the response side and thus should not pose a security risk, if there is a need to employ multiple layers of security against XSS attacks, it may be required to comment this rule, which will cause all requests (regardless of Referer) to be checked for XSS attacks via <i>Rule 99 below</i>. Disabling <i>Rule 77</i> may result in some minimal loss of functionality, including:
-#** RegEx Evaluator channel (/system/proxy/Regex Evaluator) will not be able to handle grouping characters (). The input, pattern, and replace fields will not be able to handle any entered text that is matched by the regex pattern. <nowiki>[\'\"].*[;]|[<>\(\)]</nowiki>
-#** Channel creation wizard will not be able to create Parameters that is matched by the regex pattern. <nowiki>[\'\"].*[;]|[<>\(\)]</nowiki>
-#** The following configuration items could conceivably be affected if the user input happens to  match the regex pattern <nowiki>([\'\"].*[;]|[<>\(\)])</nowiki>
-#*** SSO token for passwords
-#*** Portal user passwords
-#*** XMLImport file name
-#*** Proxied channel parameters
-#*** Regex Evaluator
-#*** Expression Evaluator
-#*** Display name for menu (folder) and channels
-#* By default user and domain credentials are echoed in HTTP responses (but not the password). Some security analysis tools will identify this as a security vulnerability, and users can disable this functionality by editing <nowiki>webapps/enportal/WEB-INF/config/config.properties</nowiki> and setting <nowiki>jsp.usercookies=false</nowiki>.
-#* CRS XSS Rules: handleXSS.xml is created and placed in WEB-INF/xmlroot/server/crs/runtimehandlers directory. This file can be assigned to a channel or to the Proxy class of pim packages for specific integration need. Or it can be moved to WEB-INF/xmlroot/server/crs/defaulthandlers directory for system wide checking.
 # SSL Browser Caching
 #* By default, Appboard now marks all content (excpet for images, CSS, or Javascript) as non-cacheable, which is a suggestion to browsers not to retain such content for efficiency purposes. There is a property (<i>request.ssl.cache</i>, specified in WEB-INF/config/config.properties) which can be toggled to "true" and will cause XML, HTML, and SWF content to be cached, as well. Setting this to "true" may slightly increase client performance with the increased risk of possibly sensitive content being retained by browsers.
-=== Patching ===
-Edge Technologies Inc. provides security patches for custom web component based on the latest Apache baseline. Patches are also provided as needed for Tomcat, the base portal product, and Product Integration Modules (PIMs).

Edge Documentation

Enportal/5.5/admin/system administration/security: Difference between revisions

Latest revision as of 11:07, 2 February 2015

Page Contents

Overview

Contacting Edge

Security Patches

Passwords & Secrets

Features & Recommendations

Search

Personal tools

Tools