Web Application Security with OWASP Stinger
This section provides information on implementing web application security with OWASP Stinger.
Overview of OWASP Stinger
Developers consistently implement sporadic, ad-hoc input validation mechanisms for web applications. However, lack of a centralized and well-defined input validation mechanism exposes the application to a variety of attacks, including SQL Injection, Cross Site Scripting (XSS), and Command Injection. To improve security and protect the information assets, many organizations implement OWASP Stinger into their software development life cycle.
OWASP Stinger aims to develop a centralized input validation component which can be easily applied to existing or developmental applications. Using a declarative security model, OWASP Stinger has the ability to validate all HTTP requests coming into an application.
The basic idea of OWASP Stinger is to define validation rules for the cookies and parameters of an HTTP request. These rules are specified in simple XML files using the Security Validation Definition Language. Furthermore, Stinger 2 is implemented as a J2EE filter so that all HTTP traffic is validated before it is ever processed by the web application.
OWASP Stinger is integrated with PPM as a filter (ValidationFilter). It is highly configurable and easy to plug and unplug.
Define validation rules
OWASP Stinger uses regular expressions for parameter validations.
It uses an allow list and a deny list to define validation rules.
| Option | Details |
|---|---|
| Allow list |
Identifies the cookies and parameters that can be passed to the web application. Usually, the allow list defines the predefined parameters. For example:
|
| Deny list |
Blocks general JS/HTML/SQL injection. It is used for custom fields, especially in multibyte language. For example:
|
To define the validations rules, open the Stinger.xml file in the <PPM HOME>/conf/ directory to edit the allow and deny lists.
Reconfigure validation rules
Ideally, all true positive Cross Site Scripting (XSS) can be captured and blocked by this means, because every payload should have either <script … (or its alternative, such as %3cSCRIPT…) or some inbuilt function such as “alert” in it, which can be identified by the Stinger deny list.
Sometimes, however, false positive XSS may also be captured and blocked. To bypass false positive XSS, check the rule for a specific URL or parameter and reconfigure the validation rules. Moreover, you should continuously update the deny list as the XSS attacking technology evolves.
Troubleshooting
Problem: When updating a request page, the page gets blocked and the following error message is displayed on the page and recorded in the server log:
parameter P_43HV with value 116.116.<div id="igriddiv" width="298" height="38"><iframe src="/demo/demo.html" height="38"></iframe></div>.<div id="i griddiv" width="298" height="38"><iframe src="/demo/demo.html" height="38"></iframe></div> from 10.123.211.74 has been encoded
The P_43HV parameter is malformed
Resolution:
-
Check the Stinger.xml file to find the rule for the request URL. The rule is as follows:
<name>RequestUpdate.jsp</name> <path>/.*/web/knta/crt/RequestUpdate.jsp.*</path>
-
Check if the predefined regex pattern accepts the input:
<regex><![CDATA[(?s)(?i)((?!<script)(?![^a-z]+alert[ ]*\()(?!onerror).)*]]></regex>
In this case, the regex pattern accepts the input.
-
Check the general rule that applies to all URLs. The rule is as follows:
<name>general rule for anti-XSS</name>
<path>/.*</path>
-
You find that
iframeis blocked by the following rule:regex><![CDATA[(?s)(?i)((?!%3Cscript)(?!<script)(?!(alert|prompt|confirm)[\s]*\()(?!onerror)(?!onchange[^a-z]{1})(?!on(db|aux){0,1}click)(?!onload)(?!onmouse)(?!javascript[\s]*:)(?!<iframe)(?!cmd\|).)*]]></regex> -
To allow
iframe, removeiframefrom the rule:regex><![CDATA[(?s)(?i)((?!%3Cscript)(?!<script)(?!(alert|prompt|confirm)[\s]*\()(?!onerror)(?!onchange[^a-z]{1})(?!on(db|aux){0,1}click)(?!onload)(?!onmouse)(?!javascript[\s]*:)(?!cmd\|).)*]]></regex>

