Cross-site scripting, also known as XSS protection, is implemented as an IValueFormatter for values coming from external sources. It implements basic HTML escaping as described on the OWASP website using a normalization and targeted replace technique.
Web application - data from inputs are formatted in the controllers before being processed;
Development plugin - modifying the profile from the development plugin will use formatted values as well;
Web services - both REST and SOAP services are protected against XSS by the formatter;
The Request Parameters plugin.
Canonicalization
All input is transformed into a canonical form before validation. Canonicalization involves URL- and HTML-decoding the input.
JAVA Runtime: We use ESAPI to canonicalize the input string to improve the detection. We allow mixed and multiple encodings before we validate if no malicious pattern is found. You can disallow multiple and mixed encoding by specifying your own ESAPI.properties. You can specify the location of this file by passing the environment setting org.owasp.esapi.resources. When ESAPI throws an IntrusionException an empty string will be used.
.NET Runtime: By default, ASP.NET framework does not canonicalize strings, but it protects web application from requests that might contain dangerous content. From MSDN : Request validation is a feature in ASP.NET that examines an HTTP request and determines whether it contains potentially dangerous content. In this context, potentially dangerous content is any HTML markup or JavaScript code in the body, header, query string, or cookies of the request. ASP.NET performs this check because markup or code in the URL query string, cookies, or posted form values might have been added for malicious purposes. Enabling or disabling canonicalization is not applicable anymore, since the feature that protected the .NET Runtime against dangerous content is part of the main Request Validation feature, which we recommend against disabling. More information about Request Validation done by ASP.NET and how it can be disabled can be found here: https://msdn.microsoft.com/en-us/library/hh882339(v=vs.110).aspx .
The above properties enable/disable cross site scripting protection as a whole. If needed, custom rules can be applied, as described below. Cross site scripting protection has the following components :
For the header there are no additional parameters.
2 Request Body Validation
This property refers to validation for POST requests that contain an application/json request body. When this type of validation is enabled, the request is blocked if dangerous input is detected in the request body.
3 Request Parameter Validation
This property refers to validation for request parameters. When this type of validation is enabled, the request is blocked if dangerous input is detected in the request parameters.
4 Request URL Validation
This property refers to validation for request URL. When this type of validation is enabled, the request is blocked if dangerous input is detected in the request URL.
5 Multipart Request Validation
This property refers to validation for multipart requests. Body parts that have content-type "application/json" are validated the same way as for the Request Body Validation. When this type of validation is enabled, the request is blocked if dangerous input is detected in the JSON request parts.
Note: for all of the properties above , dangerous input is determined by the blacklist and whitelist configuration.
6 Whitelist Customization
(White list validation is appropriate for all input fields provided by the user. White list validation involves defining exactly what IS authorized, and by definition, everything else is not authorized.) By default, when the XSS Whitelist protection is activated, all tags and attributes are blocked.
allows specifying for a specific tag what attributes are URI attributes and the protocols allowed will be the ones globally defined(first property in this table)
Note: If an attribute is marked as an URI attribute, then the attribute value must be a URI, otherwise it will not pass the validation and it will be removed
Note: If an attribute is marked as an URI attribute, then the attribute value must be a URI, otherwise it will not pass the validation and itwill be removed
XML Tag
Attribute
Description
allowed-protocols
-
Children of this section define a collection containing the allowed URI protocols
allowed-protocol
name
A string representing the name of the allowed URI protocol
allowed-tags
-
Children of this section define a collection containing the allowed HTML tags
allowed-tag
name
A string representing the name of the allowed HTML tag
allowed-attributes
-
Children of this section define a collection containing the allowed attributes on the before defined tags
allowed-attribute
name
A string representing the name of the allowed attribute
isUriAttribute
A Boolean that marks the specified attribute as being a URI attribute. The protocols that are allowed are the ones specified the allowed-protocols.
If an attribute is not marked as URI, but does contain a URI value, it will pass the Whitelist validation. Make sure to set this marker for all attributes that might have an URI value.
If an attribute is marked as URI , but does not contain a URI value, it will be passed through a URL sanitization, and special characters will be URL-encoded.
If an attribute is not marked as URI, but does contain a URI value, it will pass the Whitelist validation. Make sure to set this marker for all attributes that might have an URI value. If an attribute is marked as URI, but does not contain a URI value, it will be passed through a URL sanitization, and special characters will be URL-encoded. ASP.NET framework provides a certain degree of protection against XSS attacks. In order to allow certain HTML elements that are added through configuration as described above, the following additional setting has to be present in Web.config: See httpRuntime element, the requestValidationType attribute :
The example is just a simple example for understanding how whitelist properties work. This is not meant for production use! Please define your own whitelist properties tailored for your project needs.
blueriq.security.xss-protection.whitelist.enabled=true
# define what protocols are allowed on uri attributes
blueriq.security.xss-protection.whitelist.allowed-protocols=http,https
# define what tags are allowed
blueriq.security.xss-protection.whitelist.allowed-tags=b,i,u,q,img
# define what attributes are allowed on all the allowed tags
blueriq.security.xss-protection.whitelist.allowed-global-attributes=class,tabindex,title
# define what attribute are allowed on each tag
blueriq.security.xss-protection.whitelist.allowed-attributes.q=cite
blueriq.security.xss-protection.whitelist.allowed-attributes.img=src,alt
# define which attributes of which tags can contain URIs and are subject to the allowed-protocols restrictions
blueriq.security.xss-protection.whitelist.uri-attributes.a=href
blueriq.security.xss-protection.whitelist.uri-attributes.img=src
The HTTP X-XSS-Protection response header is a feature of Internet Explorer, Chrome and Safari that stops pages from loading when they detect reflected cross-site scripting attacks. Although these protections are largely unnecessary in modern browsers when sites implement a strong Content-Security-Policy that disables the use of inline JavaScript ('unsafe-inline'), they can still provide protections for users of older web browsers that don't yet support CSP. The response header that will be sent:
X-XSS-Protection: 1; mode=block
Enables XSS filtering. Rather than sanitizing the page, the browser will prevent rendering of the page if an attack is detected.
In case the default blacklist and/or whitelist implementations are not sufficient, it is possible to register custom blacklist and/or whitelist implementations.
Create your own blacklist implementation:
import com.aquima.interactions.project.impl.xss;
public class SampleXssBlacklist implements IXssBlacklist {
public String sanitize(String input) {
// custom input sanitization
}
public boolean isValid(String input) {
// custom input validation
}
}
Create your own whitelist implementation:
import com.aquima.interactions.project.impl.xss;
public class SampleXssWhitelist implements IXssWhitelist {
public String sanitize(String input) {
// custom input sanitization
}
public boolean isValid(String input) {
// custom input validation
}
}
Expose your custom blacklist and/or whitelist implementations as Spring beans:
@Configuration
public class SampleXssConfiguration {
@Bean
public IXssBlacklist xssBlacklist() {
return new SampleXssBlacklist();
}
@Bean
public IXssWhitelist xssWhitelist() {
return new SampleXssWhitelist();
}
}
The Java Runtime will automatically detect your custom implementations and register them instead of the default implementations.
Create your own blacklist implementation:
using com.aquima.interactions.project.impl.xss;
public class SampleXssBlacklist : IXssBlacklist {
public string sanitize(string input) {
// custom input sanitization
}
public bool isValid(string input) {
// custom input validation
}
}
Create your own whitelist implementation:
using com.aquima.interactions.project.impl.xss;
public class SampleXssWhitelist : IXssWhitelist {
public string sanitize(string input) {
// custom input sanitization
}
public bool isValid(string input) {
// custom input validation
}
}
Register your custom blacklist and/or whitelist implementations in any initialization code:
In its current form, the formatter does not provide 100% protection against cross-site scripting. Other countermeasures (such as a web application firewall) are recommended. See the OWASP website for more information on XSS attacks.
It is not possible to disallow XML/HTML content in the profile values because there are valid use cases which require this. Therefore the decision to protect only the entry points mentioned above has been made. It is the responsibility of the developer using extension points to make sure the values inserted into the profile are validated against XSS.
The .NET whitelist considers input such as "a<b" as invalid, as "<b" is interpreted as an unclosed tag. This is a known limitation in the .NET Runtime. We recommend using a space after the less than sign which is considered a valid input (eg. "a < b" instead of "a<b"). The consequences of this limitation are:
Requests with parameters of this form a. will be blocked
Values entered in fields (profile) or comments will be sanitized by removing everything after the greater than sign (eg. "a<b" will be sanitized to "a")
The .NET whitelist considers URI values such as "http://www.example.com" as invalid. A valid URI must have a path component (eg. "http://www.example.com/" - notice the slash at the end). The consequences of this limitation are:
Requests with parameters containing tags with URI attributes of the form "http://www.example.com" (i.e. without a trailing slash) will be blocked
WSDL files provide detailed information about the services ports and bindings available to web server. An attacker can try to submit special characters or malicious content to the Web service and potentially cause a denial of service condition or unauthorised access to database records. In addition, the attacker may try to guess other 'private' (unexposed) methods by using the information provided in the WSDL files.
For example the following web service description was discovered:
Recommendation: The access to WSDL file should be limited as much as possible (for example the entry point should go thourgh nginx [https://nginx.org/en/] or something similar). If services are provided only to a limited number of entities, it may be better to provide WSDL privately to each of these entities than to publish WSDL publicly.