Original address: Http://java.dzone.com/articles/xss-filter-java-ee-web-apps
Cross Site Scripting, or XSS, was a fairly common vector used to attack Web sites. It involves user generated code being redisplayed by a website with all the privileges and security rights that a browser Assigns to code originating from the current host. If The user code is something like <script>doevil (); </script> and then you have a problem.
OWASP is an organisation that provides guidance on web security, and they has a page that provides a suggested method for Avoiding XSS in Java EE web App. You can read this document Athttps://www.owasp.org/index.php/how_to_add_validation_logic_to_httpservletrequest.
The library being demonstrated here's based off the ideas presented in so article, but fleshed out to being more flexible and easy to deploy. We Call this library the (unimaginatively named) Parameter Validation Filter, or PVF.
PVF is implemented as a Servlet filter this intercepts requests to Web pages, runs submitted parameters through a Configur Able sequence of validation rules, and either sanitises the parameters before they is sent through to the Web application , or returns a HTTP error code if validation errors were detected.
We have made the following assumptions if developing this library:
- Client side validation would prevent legitimate users from submitting invalid data.
- The PVF library should prevent further processing if invalid data is submitted in the majority of cases.
- Occasionally it might is appropriate to sanitise submitted data, but any sanitisation should is trivial (like the removal of whitespace).
To make use of the PVF library, you'll need to add it to your project. This artifact are currently in the Sonatype staging repo, so you'll need to add that repo to your Maven config. See http://stackoverflow.com/questions/13945757/how-do-you-import-a-maven-dependency-from-sonatype-org for Details.
View Source print?
1.
<
dependency
>
2.
<
groupId
>com.matthewcasperson</
groupId
>
3.
<
artifactId
>parameter_validation_filter</
artifactId
>
4.
<
version
>LATEST</
version
>
5.
</
dependency
>
The filter then needs to is added to the Web. xml file with the following settings. You could want to configure the Url-pattern to match the pages of the actually want to protect.
View Source print?
01.
<
filter
>
02.
<
filter-name
>ParameterValidationFilter</
filter-name
>
03.
<
filter-class
>com.matthewcasperson.validation.filter.ParameterValidationFilter</
filter-class
>
04.
<
init-param
>
05.
<
param-name
>configFile</
param-name
>
06.
<
param-value
>/WEB-INF/xml/pvf.xml</
param-value
>
07.
</
init-param
>
08.
</
filter
>
09.
<
filter-mapping
>
10.
<
filter-name
>ParameterValidationFilter</
filter-name
>
11.
<
url-pattern
>*.jsp</
url-pattern
>
12.
</
filter-mapping
>
Finally you need to create a file called Web-inf/xml/pvf.xml. This file defines the custom validation rules applied to the parameters being sent to your Web applications.
View Source print?
01.
<?
xml
version
=
"1.0"
encoding
=
"UTF-8"
standalone
=
"yes"
?>
02.
<!-- ParameterValidationChainDatabase is always the document element -->
03.
<
ParameterValidationChainDatabase
>
04.
<!--
05.
Enforcing mode needs to be set to true to return a HTTP error code if validation fails.
06.
If set to false, validation errors are logged but ignored.
07.
-->
08.
<
EnforcingMode
>true</
EnforcingMode
>
09.
10.
<!-- We always have a single ParameterValidationChains element under the parent -->
11.
12.
<
ParameterValidationChains
>
13.
14.
<!-- Each chain of validation rules is contained in a ParameterValidationDefinition element -->
15.
<!--
16.
This chain apply some global validation rules. If anyone supplies encoded or params with HTML
17.
characters, it will fail.
18.
-->
19.
<
ParameterValidationDefinition
>
20.
<!-- This is the list of validation classes that should be applied to matching parameters -->
21.
<
ParameterValidationRuleList
>
22.
<
ParameterValidationRule
>
23.
<!-- This is the fully qualified name of the class used to apply the validation rule -->
24.
<!-- All input fields are to be trimmed of excess whitespace -->
25.
<
validationRuleName
>com.matthewcasperson.validation.ruleimpl.TrimTextValidationRule</
validationRuleName
>
26.
</
ParameterValidationRule
>
27.
<
ParameterValidationRule
>
28.
<!-- No parameters are expected to already be encoded -->
29.
<
validationRuleName
>com.matthewcasperson.validation.ruleimpl.FailIfNotCanonicalizedValidationRule</
validationRuleName
>
30.
</
ParameterValidationRule
>
31.
<
ParameterValidationRule
>
32.
<!-- No parameters are expected to contain html -->
33.
<
validationRuleName
>com.matthewcasperson.validation.ruleimpl.FailIfContainsHTMLValidationRule</
validationRuleName
>
34.
</
ParameterValidationRule
>
35.
</
ParameterValidationRuleList
>
36.
<!-- This is a regex that defines which parameteres will be validated by the classes above -->
37.
<
paramNamePatternString
>.*</
paramNamePatternString
>
38.
<!-- This is a regex that defines which URLs will be validated by the classes above -->
39.
<
requestURIPatternString
>.*</
requestURIPatternString
>
40.
<!--
41.
Setting this to false means the paramNamePatternString has to match the param name.
42.
Setting it to true would mean that paramNamePatternString would have to *not* match the param name.
43.
-->
44.
<
paramNamePatternNegated
>false</
paramNamePatternNegated
>
45.
<!--
46.
Setting this to false means the requestURIPatternString has to match the uri.
47.
Setting it to true would mean that requestURIPatternString would have to *not* match the uri name.
48.
-->
49.
<
requestURIPatternNegated
>false</
requestURIPatternNegated
>
50.
</
ParameterValidationDefinition
>
51.
</
ParameterValidationChains
>
52.
</
ParameterValidationChainDatabase
>
The XML has been commented to make it easier to understand, but there is a few interesting elements:
- Paramnamepatternstring, which have been configured to enable the validation chain to match all parameters
- Requesturipatternstring, which have been configured to enable the chain to match all URIs
- The three elements called Validationrulename, which reference the full class name of the validation rules that would be app Lied to all parameter passed into our web application
Although this was a simple example, the three validation rules, which has been implemented (Trimtextvalidationrule, FAILIFNO Tcanonicalizedvalidationrule and Failifcontainshtmlvalidationrule) is quite effective at preventing a malicious user fro M submitting parameters that contain XSS code.
The first rule, trimtextvalidationrule, simply strips away any whitespace on either side of the parameter. This uses the trim () function of any developer should is familiar with.
The second rule, failifnotcanonicalizedvalidationrule, would prevent further processing if the supplied parameter has Alrea DY been encoded. No legitimate user'll has a need to supply text like%3cscript%3edoevil ()%3b%3c%2fscript%3e, so any time encoded text I s found we simply return with a HTTP error code. This rule makes use of the ESAPI library supplied by OWASP.
Like the second rule, the third rule would prevent further processing if the supplied parameter have any special HTML Charac Ters. If you would like your customers to being able to pass through characters as &, this rule is too broad. However, it's almost always valid to block special HTML characters.
If you want to see how effective this simple validation chain are, check out of the live demo at Http://pvftest-matthewcaspers on.rhcloud.com/. Want to take a look athttps://www.owasp.org/index.php/xss_filter_evasion_cheat_sheet to find some XSS patterns tha T is often used to bypass XSS filters.
Moving forward we'll be looking to implement more targeted validation rules, especially those so can ' t be easily imple Mented as regex matches (like making sure a date if after today, or the a number is between the values etc).
If you had any suggestions, or find any bugs, feel free to fork the code from our GitHub repo. We do hope to get some public feedback in order to make this library as robust as it can.
A XSS Filter for Java EE Web apps--Reprint