Enportal/5.4/admin/user administration/security - Revision history

imported>Jay.barr: /* Secure configuration */

2014-04-03T02:48:53Z

Secure configuration

← Older revision		Revision as of 02:48, 3 April 2014
Line 96:		Line 96:
	#*remove manual from apache install: to be performed as part of the OS lockdown<br><br>		#*remove manual from apache install: to be performed as part of the OS lockdown<br><br>
	# XSS and Vulnerability Tool Hardening:		# 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, 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:		#* 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>		#** 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>		#** Channel creation wizard will not be able to create Parameters that is matched by the regex pattern. <nowiki>[\'\"].*[;]\|[<>\(\)]</nowiki>

imported>Jay.barr at 02:45, 3 April 2014

2014-04-03T02:45:35Z

← Older revision		Revision as of 02:45, 3 April 2014
Line 96:		Line 96:
	#*remove manual from apache install: to be performed as part of the OS lockdown<br><br>		#*remove manual from apache install: to be performed as part of the OS lockdown<br><br>
	# XSS and Vulnerability Tool Hardening:		# 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, the Referer in the HTTP request ~~can be~~ spoofed~~, and some~~ security attack tools ~~do use this tactic to identify XSS vulnerabilities (though it~~ would ~~be difficult for a typical client to effect)~~. 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:		#* 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, 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>		#** 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>		#** Channel creation wizard will not be able to create Parameters that is matched by the regex pattern. <nowiki>[\'\"].*[;]\|[<>\(\)]</nowiki>

imported>Andy.hopper: /* Secure configuration */

2014-03-27T19:09:02Z

Secure configuration

← Older revision		Revision as of 19:09, 27 March 2014
Line 110:		Line 110:
	#* 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.		#* 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		# 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.		#* 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 ===		=== 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 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).

imported>Andy.hopper: /* Secure configuration */

2014-03-27T19:08:20Z

Secure configuration

← Older revision		Revision as of 19:08, 27 March 2014
Line 109:		Line 109:
	#* 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>.		#* 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.		#* 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.		# 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 ===		=== 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 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).

imported>Andy.hopper: /* Secure configuration */

2014-03-27T19:07:50Z

Secure configuration

← Older revision		Revision as of 19:07, 27 March 2014
Line 109:		Line 109:
	#* 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>.		#* 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.		#* 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 ===		=== 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 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).

imported>David.moore: /* Secure configuration */

2014-01-21T19:06:54Z

Secure configuration

← Older revision		Revision as of 19:06, 21 January 2014
Line 96:		Line 96:
	#*remove manual from apache install: to be performed as part of the OS lockdown<br><br>		#*remove manual from apache install: to be performed as part of the OS lockdown<br><br>
	# XSS and Vulnerability Tool Hardening:		# 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, the Referer in the HTTP request can be spoofed, and some security attack tools do use this tactic to identify XSS vulnerabilities (though it would be difficult for a typical client to effect). Although all XSS issues (that are known) have been dealt with on the response side and thus should not pose a security ~~rist~~, 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:		#* 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, the Referer in the HTTP request can be spoofed, and some security attack tools do use this tactic to identify XSS vulnerabilities (though it would be difficult for a typical client to effect). 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>		#** 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>		#** Channel creation wizard will not be able to create Parameters that is matched by the regex pattern. <nowiki>[\'\"].*[;]\|[<>\(\)]</nowiki>

imported>David.moore: /* Secure configuration */

2014-01-21T19:01:33Z

Secure configuration

← Older revision		Revision as of 19:01, 21 January 2014
Line 77:		Line 77:
	#Ability to setup and configure password policy, including a number of security options including forcing account locks after consecutive failures.<br><br>		#Ability to setup and configure password policy, including a number of security options including forcing account locks after consecutive failures.<br><br>
	#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>		#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>
	#Disabling domain and user cookies used to pre-fill login windows.		#Disabling domain and user cookies used to pre-fill login windows.<br><br>
	#Updating custom login pages and disabling default login pages which remember user, domain, and password information from remembering selections.<br><br>		#Updating custom login pages and disabling default login pages which remember user, domain, and password information from remembering selections.<br><br>
	#Disabling default accounts, creating custom administration accounts, or configuring specific resources with /portalAdministration rights (role assignment).<br><br>		#Disabling default accounts, creating custom administration accounts, or configuring specific resources with /portalAdministration rights (role assignment).<br><br>
Line 94:		Line 94:
	#*apache bin 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		#*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		#*remove manual from apache install: to be performed as part of the OS lockdown<br><br>
	# XSS and Vulnerability Tool Hardening:		# 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, the Referer in the HTTP request can be spoofed, and some security attack tools do use this tactic to identify XSS vulnerabilities (though it would be difficult for a typical client to effect). Although all XSS issues (that are known) have been dealt with on the response side and thus should not pose a security rist, 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:		#* 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, the Referer in the HTTP request can be spoofed, and some security attack tools do use this tactic to identify XSS vulnerabilities (though it would be difficult for a typical client to effect). Although all XSS issues (that are known) have been dealt with on the response side and thus should not pose a security rist, 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:

imported>Andy.hopper: /* Secure configuration */

2014-01-07T15:01:36Z

Secure configuration

← Older revision		Revision as of 15:01, 7 January 2014
Line 97:		Line 97:
	# XSS and Vulnerability Tool Hardening:		# 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, the Referer in the HTTP request can be spoofed, and some security attack tools do use this tactic to identify XSS vulnerabilities (though it would be difficult for a typical client to effect). Although all XSS issues (that are known) have been dealt with on the response side and thus should not pose a security rist, 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:		#* 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, the Referer in the HTTP request can be spoofed, and some security attack tools do use this tactic to identify XSS vulnerabilities (though it would be difficult for a typical client to effect). Although all XSS issues (that are known) have been dealt with on the response side and thus should not pose a security rist, 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. [\'\"].*[;]\|[<>\(\)]		#** 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. [\'\"].*[;]\|[<>\(\)]		#** 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>.		#* 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.		#* 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.

imported>Nick.chang: /* Secure configuration */

2014-01-03T20:53:15Z

Secure configuration

← Older revision		Revision as of 20:53, 3 January 2014
Line 100:		Line 100:
	#** Channel creation wizard will not be able to create Parameters that is matched by the regex pattern. [\'\"].*[;]\|[<>\(\)]		#** Channel creation wizard will not be able to create Parameters that is matched by the regex pattern. [\'\"].*[;]\|[<>\(\)]
	#* 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>.		#* 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: ~~please fill this~~ in		#* 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.

	=== Patching ===		=== 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 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).

imported>Nick.chang: /* Secure configuration */

2014-01-03T20:51:47Z

Secure configuration

← Older revision		Revision as of 20:51, 3 January 2014
Line 97:		Line 97:
	# XSS and Vulnerability Tool Hardening:		# 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, the Referer in the HTTP request can be spoofed, and some security attack tools do use this tactic to identify XSS vulnerabilities (though it would be difficult for a typical client to effect). Although all XSS issues (that are known) have been dealt with on the response side and thus should not pose a security rist, 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:		#* 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, the Referer in the HTTP request can be spoofed, and some security attack tools do use this tactic to identify XSS vulnerabilities (though it would be difficult for a typical client to effect). Although all XSS issues (that are known) have been dealt with on the response side and thus should not pose a security rist, 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 ~~input~~ that is matched by the regex pattern. [\'\"].*[;]\|[<>\(\)]		#** 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. [\'\"].*[;]\|[<>\(\)]
	#** Channel creation wizard will not be able to create Parameters that is matched by the regex pattern. [\'\"].*[;]\|[<>\(\)]		#** Channel creation wizard will not be able to create Parameters that is matched by the regex pattern. [\'\"].*[;]\|[<>\(\)]
	#* 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>.		#* 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>.