Enportal/5.5/admin/system administration/security/xss rules - Revision history

imported>Jason.nicholls: moved enportal/5.5/admin/user administration/security/xss rules to enportal/5.5/admin/system administration/security/xss rules

2014-10-03T09:47:41Z

moved enportal/5.5/admin/user administration/security/xss rules to enportal/5.5/admin/system administration/security/xss rules

← Older revision	Revision as of 09:47, 3 October 2014
(No difference)

imported>Jason.nicholls: /* CRS Proxied Web Applications */

2014-09-25T08:35:53Z

CRS Proxied Web Applications

← Older revision		Revision as of 08:35, 25 September 2014
Line 10:		Line 10:
	=== CRS Proxied Web Applications ===		=== CRS Proxied Web Applications ===

	enPortal ships with a default CRS handler to deal with generic XSS issues of proxied applications. However, since these generic rules may cause issues with the proxied web applications they are ''disabled by default''. Please note that in some cases the PIMs provided by Edge may have specific rules or the default XSS handler enabled - refer to the individual PIM documentation for more information.		enPortal ships with a default CRS handler to deal with generic XSS issues in proxied web applications. However, since these generic rules may cause issues with the proxied web applications they are ''disabled by default''. Please note that in some cases the PIMs provided by Edge may have specific rules or the default XSS handler enabled - refer to the individual PIM documentation for more information.

	The handler is shipped with enPortal in the following location: <tt>[INSTALL_HOME]/server/webapps/enportal/WEB-INF/xmlroot/server/crs/runtimehandlers/handleXSS.xml</tt>		The handler is shipped with enPortal in the following location: <tt>[INSTALL_HOME]/server/webapps/enportal/WEB-INF/xmlroot/server/crs/runtimehandlers/handleXSS.xml</tt>

imported>Jason.nicholls: /* CRS Proxied Web Applications */

2014-09-25T08:35:04Z

CRS Proxied Web Applications

← Older revision		Revision as of 08:35, 25 September 2014
Line 9:		Line 9:

	=== CRS Proxied Web Applications ===		=== CRS Proxied Web Applications ===

			enPortal ships with a default CRS handler to deal with generic XSS issues of proxied applications. However, since these generic rules may cause issues with the proxied web applications they are ''disabled by default''. Please note that in some cases the PIMs provided by Edge may have specific rules or the default XSS handler enabled - refer to the individual PIM documentation for more information.

			The handler is shipped with enPortal in the following location: <tt>[INSTALL_HOME]/server/webapps/enportal/WEB-INF/xmlroot/server/crs/runtimehandlers/handleXSS.xml</tt>

			This handler can be assigned to a specific channel, proxy classes (for all channels that use these classes), or enabled system-wide. To enable system-wide move the handler from <tt>runtimehandlers/</tt> to <tt>defaulthandlers/</tt> but as mentioned above this may have negative consequences.

	=== Core Product ===		=== Core Product ===

imported>Jason.nicholls: Created page with 'Category:enPortal 5.5 {{DISPLAYTITLE:enPortal Security}} == Overview == enPortal includes two types of XSS protection: # CRS proxied web applications # Core product === CR...'

2014-09-25T08:26:47Z

Created page with 'Category:enPortal 5.5 {{DISPLAYTITLE:enPortal Security}} == Overview == enPortal includes two types of XSS protection: # CRS proxied web applications # Core product === CR...'

New page

[[Category:enPortal 5.5]]
{{DISPLAYTITLE:enPortal Security}}
== Overview ==

enPortal includes two types of XSS protection:

# CRS proxied web applications
# Core product

=== CRS Proxied Web Applications ===

=== Core Product ===

enPortal core features are designed to perform their own input validation, however due to the type of some accepted inputs, and due to the extensible nature of the product, it's not possible to provide specific protection in all cases. As a result there is an additional layer of protection applied to all inputs received from clients. ''Input'' here is defined as the complete HTTP request from the client which is the query, headers, and body.

This protection is applied in the form of rule sets defined in <tt>[INSTALL_HOME]/server/webapps/enportal/WEC-INF/config/config.properties</tt> with logging to <tt>[INSTALL_HOME]/server/logs/jspsystem.log</tt>. The following rules are defined:

# '''Rule 77''': allows all input when the referrer is enPortal.
# '''Rule 99''': examines the input for matches - this is the default rule to discover injection of unwanted content.

Generally the default rules are sufficient. Note that if intrusion testing is performed on enPortal then these tools can forge the referrer, bypassing the extra XSS protection, which may lead to some scan failures. Even in this situation enPortal components feature input validation which should still ensure an XSS safe environment.

However, it is possible to disable ''Rule 77'' and force checking of all input, but this may result in reduced functionality if submitted input matches ''Rule 99''. The following areas may be affected (mostly admin functionality):

* enPortal user passwords
* setting SSO token for passwords
* using XMLImport with matching filename
* setting proxied channel parameters
* using the Regex Evaluator
* using the Expression Evaluator
* setting Display name for folders and channels

Other than enabling/disabling ''Rule 77'' it is ''not recommended'' to change the rules without assistance from Edge.