OWASP - User contributions [en]

Talk:Session Fixation

2010-03-30T06:55:28Z

Wimp: Disagreement of where to invalidate a session; Question to Weblogic an session fixation

Session Fixation
Session Fixation is a security vulnerability prevelant in Authentication framework available in most of the Web Servers (WebLogic Server 10.3, Tomcat 6.0.20, ASP.NET).
Session Fixation works as follows:
1) Alice (attacker) access a unprotected resource (http://vulnerableApp/unprotected.jsp). In most of the web servers a new session is created now, even if you are not logged in. A session cookie is set and sent with the response.
2) Alice notes down the session cookie sent by the web server. She can do that using some HTTP monitoring tool like LiveHttpHeader for FireFox. copy that cookie string to a different computer. Alice change the browser page to something else (www.google.com). Keep the browser window open. Leaves the computer.
3) Bob (victim) uses the computer to access a protected resource from the same web application (http://vulnerableApp/protected.jsp). He uses the same browser windows (which is kept open). He loges in using his username/password. WebServer now uses the same session cookie for logged in session. Bob continue using the application for next 30 minutes.
4) Alice access the protected resource from the application (http://vulnerableApp/protected.jsp) using the saved cookie from another machine. He can use some Java client to do so. Now she is able to access the protected resource with Bob's credentials. Alice will be able to access all protected resources until Bob logs out. If Bob leaves the computer by closing the browser (without explicit logout), then alice will be able to use the resource forever (or untill next server re-start).

This vulnerability is there if you are using most of the Web Servers (WebLogic, Tomcat not tested any other server heard ASP.NET is also having session fixation bug. )

Solution:
If you are using Form based authentication, call session.invalidate() in the login page. This will create new session cookie. See the sample login page below:

<%
session.invalidate();
%>

<form action="j_security_check" method="POST" name="login">

<input type="input" name="j_username" />

<input type="password" name="j_password" />

<input type="submit" name="submit" value="Log in" />

</form>

If you are BASIC authentication, you are at risk unless the web server handles it correctly (most web servers don't handle it). Ideally authentication framework in the web server should have called session.invalidate() before authentication.
Don't use BASIC authentication in your application.

Sample application to demonstrate the vulnerability
1) Download the SimpleWebApp1 ( [http://rejeev.googlepages.com/SimpleWebApp1.war]http://rejeev.googlepages.com/SimpleWebApp1.war )
2) Configure a WebLogic or Tomcat server
3) Create a user called "user1" in weblogic
4) Create a user called "user1" and role called "user1" in Tomcat
5) Deploy the application in WebLogic or tomcat
6) Access test2.jsp (http://localhost:7001/SimpleWebApp1/test2.jsp)
7) Note the cookie (use LiveHttpHeaders with firefox)
8) Access test1.jsp (http://localhost:7001/SimpleWebApp1/test1.jsp). You will be asked to log in, log in.
9) Now try access the test1.jsp using the TestSessionFixation.java provide inside the war. Usage: java rejeev.sessionfixation.TestSessionFixation <url> <cookie>. You will be able to see test1.jsp without login.

Session fixation is supposed to be fixed in WebLogic Server 10.3. However I have observed that it is present in latest version of WebLogic (Weblogic Server 10.3). I think they have fixed vulnerability WebLogic console only. WebLogic console being a web application it also vulnerable. However fundamental defect is in the authentication framework. That is not yet fixed.
Please see the following blog entry for details
[http://rejeev.blogspot.com/2009/09/session-fixation_08.html]http://rejeev.blogspot.com/2009/09/session-fixation_08.html

---

1) Do server side session invalidation

I don't agree with the solution above, to invalidate the session in the JSP. It is still possible, to do the login from a fake page, e.g. from a XSSed page from the same server where the session still is valid.
The session has to be renewed during the login request, right before the authentication. This way the response will have a "Set-Cookie" with a fresh and authenticated session. See: [https://www.bsi.bund.de/cae/servlet/contentblob/476464/publicationFile/30642/WebSec_pdf.pdf Sicherheit von Webanwendungen] (from the German BSI, page 40).

2) Weblogic and session fixation

In the [http://download.oracle.com/docs/cd/E12839_01/web.1111/e13852/toc.htm weblogic changelog 10.3.1] I don't see the bugfix of session fixation in weglogic, as you stated in your blog. Has anyone a source? What exactly changed?

--[[User:Wimp|Wimp]] 06:55, 30 March 2010 (UTC)

OWASP Java Table of Contents

2008-08-29T08:09:34Z

Wimp: Added the Framework JSecurity to the list

Key:
* xx%: Progress status of the paragraph
* Review: The paragraph needs a review
* TD: Paragraph to be assigned

==[[J2EE Security for Architects]]==
Discuss the security implications of common J2EE architectures. This could be discussed in terms of: Authentication, Authorisation, Data Validation, Cross Site Scripting protection. Other architecture concerns such as scalability, performance and maintainability can also be mentioned, but the focus on security should not be lost.

Any other security concerns that should be addressed during the design phase should also be mentioned here.
===Design considerations===
* Architectural considerations (0%, TD)
** EJB Middle tier (0%, TD)
** Web Services Middle tier (0%, TD)
** Spring Middle tier (0%, TD)

==[[J2EE Security for Developers]]==
=== Noteworthy Frameworks ===
Discuss important and relevant Java security frameworks that would be useful to architects. The information should be at a suitably high level, for example, by discussing the advantages and features as well as the associated costs (direct and indirect) of using the frameworks.

(0%, Seeking Volunteers)
* [[Struts]] (0% Jon Forck)
* Turbine
* [[Java Server Faces]] (Sam Reghenzi - 90%, Finalising content)
* Tapestry
* Webwork
* Cocoon
* Tiles
* SiteMesh
* Spring (0%, Adrian San Juan, TD)
* [[Wicket]]
* JSecurity

===[[Java Security Basics]]===
Provide an introduction into the basic security services provided by the Java language and environment. Remember to keep this relevant for web developers for the initial release - there may be a potential to expand this to thick clients in subsequent releases.
* Class Loading (0%, Philippe Clairet)
* Bytecode verifier (0%, Philippe Clairet)
* The Security Manager and security.policy file (0%, John Wilander, Philippe Clairet)

===Input Validation Overview ===
Input validation is perhaps the most important category of application security. Any data entering a software system must be verified to contain safe data that is not mounting a SQL Injection, XSS, CSRF or other form of attack. This is done primarily through the use of regular expressions. It's crucial not to hard-code input validation routines. Regular expressions should contained within a configuration file that can easily updated by an InfoSec professional and not require a programmers intervention or deployment of new application code. Application security needs change over time as new attack vectors are discovered. Application administers need to be able to react to these changes as quickly as possible.

===Input Validation ===
* Dangerous calls (BufferedReader.readLine(), ServletRequest.getParameter(), etc...) (0%, TD)
* [[How to add validation logic to HttpServletRequest]] (100%, Jeff Williams, Complete)
* [[How to perform HTML entity encoding in Java]] (100%, Jeff Williams, Complete)

==== [[Preventing SQL Injection in Java]] ====
* Overview
* Prevention (60%, Stephen de Vries, Review)
** White Listing
** Prepared Statements
** Stored Procedures
** Hibernate
** Ibatis (60%, Rohyt Belani, Review)
** Spring JDBC
** EJB 3.0
** JDO

==== [[Preventing LDAP Injection in Java]] ====
* Overview (100%, Stephen de Vries, Complete)
* Prevention (100%, Stephen de Vries, Complete)

==== [[XPATH Injection]] ====
As with the other Injection sections, only provide cursory information on the general case. Should contain practical real-world advise and code examples for preventing XPATH injection.
* Overview (0%, TD)
* Prevention (0%, TD)

==== [[Miscellaneous Injection Attacks]] ====
* HTTP Response splitting (0%, TD)
* Command injection - Runtime.getRuntime().exec() (0%, TD)
* Regular Expression (regex) Injections (20%)

''' Status '''
In progress

=== Authentication===
* [[Storing credentials]] - (20%, Adrian San Juan, Review)
* [[Hashing Java|Hashing]] - (100%, Michel Prunet, Review)
* [[SSL Best Practices]] - (20%, Philippe Curmin, Review)
* [[Using JCaptcha]] - (100%, Dave Ferguson, Review)
* Container-managed authentication with Realms
** [[Declarative Access Control in Java]] - (100%, Dave Ferguson, Completed)
* [[JAAS Timed Login Module]] - (100%, Stephen de Vries, Review)
* [[JAAS Tomcat Login Module]] - (100%, Stephen de Vries, Review)
* [[Password length & complexity]] - (100%, Adrian San Juan, Review)

===Session Management ===
The generic problems and solutions for session management are covered in the Guide. This section should focus on Java specific examples.
* Logout (0%, TD)
* Session Timeout (0%, TD)
* Absolute Timeout (0%, TD)
* [[Session Fixation in Java]] (100%, Rohyt Belani, Review)
* Terminating sessions (0%, TD)
** Terminating sessions when the browser window is closed

===Authorization===
* [[Declarative v/s Programmatic]] (10%, TD)
* EJB Authorization (0%, TD)
* Acegi (0%, TD)
* JACC (0%, TD)
* Check horizontal privilege (0%, TD)

=== Encryption===
* [http://www.owasp.org/index.php/Using_the_Java_Cryptographic_Extensions JCE] (100%, Joe Prasanna Kumar - To be reviewed)
* Storing db secrets (0%, TD)
* Encrypting JDBC connections (0%, TD)
* [http://www.owasp.org/index.php/Using_the_Java_Secure_Socket_Extensions JSSE] (100%, Joe Prasanna Kumar - To be reviewed)
* [http://www.owasp.org/index.php/Digital_Signature_Implementation_in_Java Digital Signatures in Java (100%, Joe Prasanna Kumar - To be reviewed)

=== Error Handling & Logging===
* Logging - why log? what to log? log4j, etc. (0%, TD)
* Exception handling techniques (0%, TD)
** fail-open/fail-closed
** resource cleanup
** finally block
** swallowing exceptions
* Exception handling frameworks (50%, TD)
** Servlet spec - web.xml [[Securing tomcat]] (100%, Darren Edmonds, Completed)
** JSP errorPage (0%, TD)
* Web application forensics (0%, TD)

=== Web Services Security ===
* SAML (0%, TD)
* (X)WS-Security (0%, TD)
* SunJWSDP (0%, TD)
* WSS4J (0%, Eelco Klaver)
* XML Signature (JSR 105) (0%, TD)
* XML Encryption (JSR 106) (0%, TD)

=== Code Analysis Tools ===
The introduction should cover the advantages and short comings of code analysis tools. An overview of the current state of the art and the available tools would go well here. As a start, only open source tools are listed, but if vendors of commercial tools adhere to the [[Tutorial]] guidelines, these submissions will be gladly received.
* Introduction (0%, TD)
* [[:Category:OWASP LAPSE Project]] (100%, Review)
* FindBugs (0%, TD)
** Creating custom rules
* PMD (0%, TD)
** Creating custom rules
* JLint (0%, TD)
* Jmetrics (0%, TD)

== [[J2EE Security For Deployers]] ==
Practical step-by-step guides to securing various J2EE servers. Examples of secure configurations can also be provided for download. If configurations are provided, they should be properly commented so that the rationale for configuration settings is clearly explained. Users of the configurations should be provided with enough information to make their own risk decisions.
=== Securing Popular J2EE Servers ===
* [[Securing tomcat|Securing Tomcat]] - (100%, Darren Edmonds, Completed)
* Securing JBoss (0%, TD)
* Securing WebLogic (0%, TD)
* Securing WebSphere (0%, TD)
* Others...

=== Defining a Java Security Policy ===
Practical information on creating a Java security policies for J2EE servers.
* PolicyTool - JChains already provides this functionality, one policy tool is enough.
* jChains (www.jchains.org) - (0%, TD)

=== Protecting Binaries ===
* Bytecode manipulation tools and techniques (0%, TD)
* [[Bytecode obfuscation]] (100%, Pierre Parrend, Released)
* Convert bytecode to native machine code (0%, TD)
* [[Protecting code archives with digital signatures]] (100%, Pierre Parrend, Released)
* [[Signing jar files with jarsigner]] (100%, Pierre Parrend, Released)

==[[J2EE Security for Security Analysts and Testers]]==
* Using Eclipse to verify Java applications (0%, TD)
* Using [[:Category:OWASP WebScarab Project|WebScarab]] to find vulnerabilities in J2EE applications - (0%, TD)
* Decompiling Java bytecode (0%, TD)

== [[Java Security Resources]] (ongoing)==

[[Category:OWASP Java Project]]

Talk:Password length & complexity

2008-05-05T07:58:37Z

Wimp: New section: How to avoid similar passwords?

The overall content is correct, but I have the following remarks :

1. I corrected some syntactical errors in the text. For example, "is" was missing in the sentence "it is the most common form", in the introduction.

2. The introduction could insist on the idea that passwords are basically a means of authenticating users of a Web application, among other means, and that the choice of passwords or a stronger means like two-factors authentication really depends on the security needs of an application, based on risk evaluation and security specifications in the conception phase.

3. In the introduction about the "Pros" and "Cons" of passwords, I would add in the "Cons" that we all suffer from having to manage and remember too many passwords. For a new Web application, one should consider the possibility of relying on a more global identity management system (such as some sort of "single sign on" or "reduced sign on" set for all or at least many applications in the corporation), instead of trying to generate yet another password.

4. I think the details of password length, password complexity and password history should not be fixed too precisely, because it really depends on the security policies of each organization. The main point in general is that in security policies, there must be rules for password length (a minimum length should be defined), password complexity (the minimum complexity of passwords should be described) and password history (the minimum number of old passwords to check should be defined).

5. I would not present managing the history of passwords as a "nice to have" feature, but rather as a mandatory feature.

Philippe Curmin

== How to avoid similar passwords? ==

In order to hinder users from using similar passwords or passwords with simple counters ("test1" -> "test2") it would be nice to implement the [http://en.wikipedia.org/wiki/Levenshtein_distance Levenshtein Distance] for the change of passwords and only allow those with at least a minimum distance.

The problem with the distance function is that I need to know the old password, which I shouldn't. If I save passwords as hashes the function doesn't work anymore.

Is there already an algorithm to compare passwords without saving them as plain text? I can imagine something like a function that saves the structure of the phrase, i.e. "test1" consists of 4 alphabetical lowercase signs and one number - the same as in "test2". But also in "ak9Me". So it needs to be a bit more sophisticated.

Any ideas?

OWASP Stinger Manual

2008-01-18T10:12:01Z

Wimp: Resolved download link to Stinger Release 2

=Overview=

The purpose of the OWASP Stinger manual is to provide users a comprehensive guide to developing upon and deploying the OWASP J2EE Stinger filter. If you have any comments or suggestions concerning the Stinger manual, please to not hesitate to email me at [mailto:eric.sheridan@owasp.org eric.sheridan@owasp.org].

=Development=

=Deployment=

==Fetch the Latest Files==

The latest Stinger release can be downloaded [http://www.owasp.org/index.php/OWASP_Stinger_Version_2 here]. The user implementing Stinger should download the jar file into a directory accessible by the Java container. For example, deploying Stinger in Tomcat would require downloading the files in the WEB-INF/lib/ directory.

==Configure Deployment Descriptor==

There are two major pieces of information necessary to deploy Stinger in your J2EE environment. First, the Java container must be told to implement the Stinger J2EE filter. This is specified in the web.xml file via the following:

<filter>
<filter-name>StingerFilter</filter-name>
<filter-class>org.owasp.stinger.StingerFilter</filter-class>
<init-param>
<param-name>config</param-name>
<param-value>stinger.xml</param-value>
</init-param>
<init-param>
<param-name>error-page</param-name>
<param-value>fatal-error.html</param-value>
</init-param>
<init-param>
<param-name>reload</param-name>
<param-value>false</param-value>
</init-param>
</filter>

Stinger 2.x accepts three filter parameters: ''config'', ''error-page'', and ''reload''. The ''config'' parameter tells the Stinger filter the location of the SVDL file. The ''error-page'' parameter is actually the result of a new feature in Stinger 2.x. All exceptions that are thrown from the web application are now caught in Stinger. This prevents sending exceptions to the client and potentially revealing sensitive information (think database exceptions). Instead of leaking sensitive information, Stinger simply redirects the client to a specified page upon catching an exception. The third parameter, ''reload'', tells Stinger whether to dynamically load the SVDL file for each incoming HTTP request. As a rule of thumb, set ''reload'' to true in testing environments and false for production environments.

The second major piece of information dictates which requests should pass the Stinger J2EE filter. This is specified in the web.xml file via the following:

<filter-mapping>
<filter-name>StingerFilter</filter-name>
<url-pattern>/*</url-pattern>
</filter-mapping>

This entry tells the J2EE container that every request handled by the container should pass through the Stinger filter.

==Configure Your SVDL File==

A template SVDL file for the latest Stinger release can be found [http://www.owasp.org/releases/Stinger/Examples/stinger_template.xml here]. The SVDL file is broken down into three sections.

:*The Regular Expression Section
:*The Cookie Rule Section
:*The Parameter Rule Section

===The Regular Expression Section===

All regular expressions to be used in Stinger are defined in this section. Essentially, a regular expression entry is comprised of a name, a regular expression, and a description. The description element is for user readability and is not used within Stinger. The regular expressions equiped with Stinger were taken from the [http://www.owasp.org/index.php/OWASP_Validation_Regex_Repository OWASP RegEx Repository]. If you have custom regular expressions and would like to donate them to the Stinger project, please email me at [mailto:eric.sheridan@owasp.org eric.sheridan@owasp.org].

The following is a sample entry in the regular expression section:

<regex>
<name>JSESSIONID</name>
<pattern>^[A-F0-9]{32}$</pattern>
<description>JSESSIONID character and length enforcement</description>
</regex>

===The Cookie Rule Section===

This section contains definitions for all of the cookies for which we are assigning a rule. A cookie rule is comprised of a name, a regular expression, the URI in which it is created, the URI's which it is enforced, and the actions taken if the cookie is missing or malformed. For most web applications, we wish to create and enforce a cookie for a particular URI. In this case, we have an entry similar to the one found below. In this case the following rule applies: ''if a cookie is missing from the request sent to the created/enforced URI, then no violation occurs. However, if a cookies is malformed in the request sent to the created/enforced URI, then a violation occurs.''

The missing and malformed sections simply specify the severity of the violation as well as the actions to be executed. There exists three possible severities: ''FATAL'', ''CONTINUE'', and ''IGNORE''.

:*If a severity is ''FATAL'', then Stinger stops processing the packet and immediately executes the associated actions.
:*If a severity is ''CONTINUE'', then Stinger appends the violation a list and continues to process the packet.
:*If a severity is ''IGNORE'', no violation is appended to the list of violation and Stinger continues its request validation.

Several actions accept parameters which are designated by the <parameter> tag.

The following is a sample entry in the cookie rule section:

<cookie>
<name>JSESSIONID</name>
<regex>JSESSIONID</regex>
<created>/Stinger-2.2.*</created>
<enforce>/Stinger-2.2.*</enforce>
<missing>
<severity>FATAL</severity>
<action class="org.owasp.stinger.actions.Log">
<parameter>
<name>log</name>
<value>default.log</value>
</parameter>
<parameter>
<name>level</name>
<value>SEVERE</value>
</parameter>
<parameter>
<name>message</name>
<value>
The required JSESSIONID cookie is missing
</value>
</parameter>
</action>
<action class="org.owasp.stinger.actions.Invalidate" />
<action class="org.owasp.stinger.actions.Redirect">
<parameter>
<name>page</name>
<value>error.html</value>
</parameter>
</action>
</missing>
<malformed>
<severity>FATAL</severity>
<action class="org.owasp.stinger.actions.Log">
<parameter>
<name>log</name>
<value>default.log</value>
</parameter>
<parameter>
<name>level</name>
<value>SEVERE</value>
</parameter>
<parameter>
<name>message</name>
<value>The JSESSIONID cookie is malformed</value>
</parameter>
</action>
<action class="org.owasp.stinger.actions.Invalidate" />
<action class="org.owasp.stinger.actions.Redirect">
<parameter>
<name>page</name>
<value>error.html</value>
</parameter>
</action>
</malformed>
</cookie>

===The Parameter Section===

The parameter section describes the parameter rules associated with a particular URI. A URI and its associated rules constitute a ''rule set''. Every SVDL implementation must contain a default rule set similar to the following:

<ruleset>
<name>STINGER_DEFAULT</name>
<path>STINGER_DEFAULT</path>
<rule>
<name>STINGER_ALL</name>
<regex>safetext</regex>

<missing>
<severity>ignore</severity>
</missing>
<malformed>
<severity>continue</severity>
<action class="org.owasp.stinger.actions.Log">
<parameter>
<name>log</name>
<value>default.log</value>
</parameter>
<parameter>
<name>level</name>
<value>info</value>
</parameter>
<parameter>
<name>message</name>
<value>
parameter %name with value %encoded_value from %ip has been encoded
</value>
</parameter>
</action>
<action class="org.owasp.stinger.actions.Encode" />
</malformed>
</rule>
</ruleset>

A default Stinger rule set must have the path (the URI) set to STINGER_DEFAULT and the rule name set to STINGER_ALL. When a request to a URI without an associated rule set is submitted, the default rule set is utilized. When a parameter without an associated rule is sent to the application, then the default rules are utilized.

The following is a sample rule set entry for a fictitious web application:

<ruleset>
<name>Main</name>
<path>/Stinger-2.2.*</path>

<rule>
<name>username</name>
<regex>safetext</regex>

<missing>
<severity>continue</severity>
</missing>
<malformed>
<severity>continue</severity>
<action class="org.owasp.stinger.actions.Log">
<parameter>
<name>log</name>
<value>default.log</value>
</parameter>
<parameter>
<name>level</name>
<value>info</value>
</parameter>
<parameter>
<name>message</name>
<value>
The username parameter from %ip is malformed
</value>
</parameter>
</action>
<action class="org.owasp.stinger.actions.Encode" />
</malformed>
</rule>
<rule>
<name>hidden1</name>
<regex>safetext</regex>

<missing>
<severity>fatal</severity>
<action class="org.owasp.stinger.actions.Log">
<parameter>
<name>log</name>
<value>default.log</value>
</parameter>
<parameter>
<name>level</name>
<value>info</value>
</parameter>
<parameter>
<name>message</name>
<value>The hidden1 parameter is missing</value>
</parameter>
</action>
<action class="org.owasp.stinger.actions.Invalidate" />
<action class="org.owasp.stinger.actions.Redirect">
<parameter>
<name>page</name>
<value>error.html</value>
</parameter>
</action>
</missing>
<malformed>
<severity>fatal</severity>
<action class="org.owasp.stinger.actions.Log">
<parameter>
<name>log</name>
<value>default.log</value>
</parameter>
<parameter>
<name>level</name>
<value>SEVERE</value>
</parameter>
<parameter>
<name>message</name>
<value>
hidden1 parameter from %ip is malformed
</value>
</parameter>
</action>
<action class="org.owasp.stinger.actions.Invalidate" />
<action class="org.owasp.stinger.actions.Redirect">
<parameter>
<name>page</name>
<value>error.html</value>
</parameter>
</action>
</malformed>
</rule>
</ruleset>

Although this entry is quite large, there are only a few new entries which must be noted. As we see, this rule set utilizes a regular expression which is intended to cover the following URIs:

:* /Stinger-2.4
:* /Stinger-2.4/
:* /Stinger-2.4/index.jsp.

For this rule set, we have specified two rules, each describing a parameter accepted by the web application. These two parameters, username and hidden1, have very similar entries to that of the cookie rules. Each parameter has an associated regular expression, a missing section, and a malformed section.

=== Important SVDL Rules/Guidelines ===

When creating your own SVDL file, please remember the
following rules/guidelines:

'''Defaults:'''
# Stinger assumes there will always exist a default rule set
# Requested URI's without a rule set will use the default rule set
# Parameters without an associated rule will use the default rule

'''Cookies:'''
# You must specify a created page for a cookie rule
# If a cookie is missing on the created page, then no violation
# If a cookie is malformed on the created page, then violation
# You must specify at least one enforced uri per cookie rule
# You can specify more than one enforced uri per cookie rule

'''Rule Sets:'''
# There must exist at least one path per rule set.
# There can exist multiple paths for a single rule set.

'''Actions:'''
# Order actions carefully and appropriately. Ex. You cannot drop a packet and then display a message.
# Several actions accept parameters. They must be defined
== SVDL Learner Filter ==

A project is underway to create a J2EE filter which generates an SVDL file based on captured HTTP traffic. The learner filter will behave similar to that of the SVDL Generator filter whereby parameters without an associated rule will be colored red. The learner filter will then look for a user-submitted value for that parameter and build an appropriate rule with default ''missing'' and ''malformed'' actions. When the user is finished crawling the site, the J2EE container is shut down and the Learner filter writes the rules to disk. The learner filter is considered developmental, yet it is included in the Stinger 2.x releases.

==Deployment Checklist==

* Download the latest Stinger jar files into the appropriate container directory
* Configure your web.xml file to:
: Load Stinger with the appropriate parameters:
:: ''config'' - the location of the SVDL file under WEB-INF
:: ''error-page'' - the error page displayed if any exception is caught
:: ''reload'' - specifies whether the SVDL should be dynamically loaded at runtime
: Apply Stinger to a URI Pattern
* Configure the SVDL for your application

=Actions=

Stinger is an action based input validation engine. The user can specify actions to be taken place upon violations found in an HTTP request. The following section describes how the actions are implemented as well as the parameters they accept. One major goal of this section is to illustrate the simplicity of creating Stinger actions. If you have created a custom action and are interested in submitting it to the Stinger project, please email me at [mailto:eric.sheridan@owasp.org eric.sheridan@owasp.org].

==AbstractAction==

===Description===

Developing your own action is relatively straight forward within Stinger. To implement a custom class, simply extend the ''AbstractAction'' class and implement the abstract ''doAction'' method. For more information related to building custom actions, please refer to the development section.

===Source Code===

public abstract class AbstractAction {

public final static int DROP = -1;

public final static int CONTINUE = 0;

public final static int PROCESS = 1;

private HashMap<String, String> parameters = new HashMap<String, String>();

public String getParameter(String name) {
return parameters.get(name);
}

public void setParameter(String name, String value) {
parameters.remove(name);
parameters.put(name, value);
}

public abstract void init(ServletContext context);

public abstract int doAction(Violation violation, MutableHttpRequest request, HttpServletResponse response);
}

==Drop==

===Description===

The ''Drop'' action simply DROP when called. This effectively prevents the HTTP request from ever reaching the web application.

===Parameters===

The ''Drop'' action currently accepts zero parameters:

===Source Code===

public class Drop extends AbstractAction {

public void init(ServletContext context) {

}

public int doAction(Violation violation, MutableHttpRequest request, HttpServletResponse response) {
return DROP;
}
}

==Invalidate==

===Description===

If the session object exists, then it will be invalidated by this action. This action is considered more severe and should be deployed only when an obvious attack occurs. For example, cookie values are rarely tampered with by the client side code (i.e. javascript). Therefore, we can (safely?) assume that any cookie modification is considered a deliberate attack.

===Parameters===

The ''Invalidate'' action currently accepts no parameters.

===Source Code===

public class Invalidate extends AbstractAction {

public void init(ServletContext context) {

}

public int doAction(Violation violation, MutableHttpRequest request, HttpServletResponse response) {
HttpSession session = request.getSession(false);

if(session != null) { session.invalidate(); }

Cookie cookie = new Cookie("JSESSIONID", "");
cookie.setMaxAge(0);
response.addCookie(cookie);

return CONTINUE;
}
}

==Log==

===Description===

As the name implies, we can log any and every request sent to the web application. The ''Log'' action is an essential action and should be heavily implemented in Stinger deployment.

===Parameters===

The ''Log'' action currently accepts 3 parameters:

'''log''' - the log file where the message should be recorded

'''level''' - the level of the log message (i.e. INFO, SEVERE, etc.)

'''message''' - the message which shall be logged. The message parameter itself accepts 3 format parameters.
These include the offender's ip address, the offender's remote port, the parameter/cookie name,
the parameter/cookie value, an entity encoded version of the parameter/cookie value, and the JSESSIONID.
The format strings are %ip, %port, %name, %value, %encoded_value, and %js respectively.
'''limit''' - the limit of the log file size
'''count''' - the maximum number of log files to use
'''append''' - specifies append mode (true/false)

===Source Code===

public class Log extends AbstractAction {

private static Logger logger = Logger.getLogger("org.owasp.stinger.actions.Log");

private static FileHandler handler = null;

private ServletContext context = null;

public Log() {

}

public void init(ServletContext context) {
this.context = context;
}

public int doAction(Violation violation, MutableHttpRequest request, HttpServletResponse response) {
String log = getParameter("log");
String level = getParameter("level");
String message = getParameter("message");
String limit = getParameter("limit");
String count = getParameter("count");
String append = getParameter("append");

if(handler == null) {
getHandler(log, limit, count, append);
}

/** Offender's IP **/
message = message.replace("%ip", request.getRemoteAddr());

/** Offender's Port **/
message = message.replace("%port", String.valueOf(request.getRemotePort()));

/** Offending parameter name **/
if(violation.getName() != null) {
message = message.replace("%name", violation.getName());
} else {
message = message.replace("%name", "NULL");
}

/** Offending parameter value **/
if(violation.getValue() != null) {
message = message.replace("%value", violation.getValue());
} else {
message = message.replace("%value", "NULL");
}

/** Offending parameter value HTML Encoded **/
if(violation.getValue() != null) {
message = message.replace("%encoded_value", violation.getValue());
} else {
message = message.replace("%encoded_value", "NULL");
}

/** Offender's JSESSIONID (HASHED) **/
if(request.getCookie("JSESSIONID") != null) {
String s = request.getCookie("JSESSIONID").getValue();
byte[] b = null;

try {
b = CryptoUtil.doWeakHash(s.getBytes());
} catch (CryptoException e) {
context.log("[Stinger-Filter] caught crypto exception in doAction", e);
}

message = message.replace("%js", Encoder.BASE64Encode(b));
} else {
message = message.replace("%js", "NULL");
}

logger.log(new LogRecord(Level.parse(level.toUpperCase()), message));

return CONTINUE;
}

private synchronized void getHandler(String log, String limit, String count, String append) {
int l = -1;
int c = -1;
boolean a = false;

try {
l = Integer.parseInt(limit);
} catch (NumberFormatException e) {
context.log("[Stinger-Filter] getHandler: " + l + " is not a valid int, defaulting to " + (1024*1024));

l = 1024*1024;
}

try {
c = Integer.parseInt(count);
} catch (NumberFormatException e) {
context.log("[Stinger-Filter] getHandler: " + count + " is not a valid int, defaulting to 1");

c = 1;
}

a = Boolean.parseBoolean(append);

getHandler(log, l, c, a);
}

private synchronized void getHandler(String log, int limit, int count, boolean append) {

try {
if(handler == null) {
handler = new FileHandler(log, limit, count, append);
}
} catch (IOException ioe) {
context.log("[Stinger-Filter] exception in getHandler", ioe);
}
}
}

==Redirect==

===Description===

The ''Redirect'' action redirects a user to a specific page. This action is often used to send a user to an error message upon finding a violation.

===Parameters===

The ''Redirect'' action currently accepts 1 parameter:

'''page''' - the page to redirect the user to

===Source Code===

public class Redirect extends AbstractAction {

private ServletContext context = null;

public void init(ServletContext context) {
this.context = context;
}

public int doAction(Violation violation, MutableHttpRequest request, HttpServletResponse response) {
String page = getParameter("page");

try {
response.sendRedirect(page);
} catch (IOException ioe) {
context.log("[Stinger-Filter] caught exception during redirect", ioe);
}

return PROCESS;
}
}

==Forward==

===Description===

The ''Forward'' action Forwards users request to a specific page for processing.

===Parameters===

The ''Forward'' action currently accepts 1 parameter:

'''page''' - the page to forward the user to

===Source Code===

public class Forward extends AbstractAction {

private ServletContext context = null;

public void init(ServletContext context) {
this.context = context;
}

public int doAction(Violation violation, MutableHttpRequest request, HttpServletResponse response) {
String page = getParameter("page");

try {
request.getRequestDispatcher(page).forward(request, response);
} catch (IOException ioe) {
context.log("[Stinger-Filter] exception in doAction", ioe);
} catch (ServletException se) {
context.log("[Stinger-Filter] exception in doAction", se);
}

return PROCESS;
}
}

== Encode ==

=== Description ===

The ''encode'' action will HTML Entity Encode the violating value. This effectively prevents cross site scripting from the violating input value.

=== Source Code ===

public class Encode extends AbstractAction {

private void entityEncode(MutableHttpRequest request, String name, String value) {
String result = null;

if(value != null) {
result = Encoder.HTMLEntityEncode(value);

request.addParameter(name, result);
}
}

public void init(ServletContext context) {

}

public int doAction(Violation violation, MutableHttpRequest request, HttpServletResponse response) {
String name = null;
String value = null;

name = violation.getName();
value = request.getParameter(name);

entityEncode(request, name, value);

return CONTINUE;
}
}

=Example SVDL Configuration Files=

The following are example SVDL configuration files. With the introduction of the global rules concept, configuring Stinger becomes significantly less cumbersome for even the most complex apps.

== Template SVDL File ==

This configuration should be used as a template for creating your own SVDL files. It contains a basic regular expression section, a basic cookie section, and no parameter rules.

[http://www.owasp.org/releases/Stinger/Examples/stinger_template.xml Click here] to download this template SVDL file.

== Encode all Input ==

This SVDL configuration encodes all parameters in the HTTP request. By entity encoding all parameter-based user input, we significantly reduce the likelihood of certain forms of Cross Site Scripting and SQL Injection attacks.

[http://www.owasp.org/releases/Stinger/Examples/stinger_encode_all.xml Click here] to download this sample SVDL file.

== Encode all Input and Log All Violations ==

This SVDL configuration encodes all parameters in the HTTP request and logs all violations that may occur. As a result, we significantly reduce the likelihood of certain input validation attacks and we have a logging mechanism to detect and verifies these attacks.

[http://www.owasp.org/releases/Stinger/Examples/stinger_encode_log_all.xml Click here] to download this sample SVDL file.

== Encode all Input for a Particular URI ==

This SVDL configuration encodes all parameters in the HTTP request that are sent to a specific set of URI's. If a malformed parameter is sent to another URI not listed in our rule, then the global rule handles the packet. Since the global rule does nothing, the malformed data will be accepted.

[http://www.owasp.org/releases/Stinger/Examples/stinger_encode_specific_uri.xml Click here] to download this sample SVDL file.

=Feedback and Participation =

We hope you find Stinger useful. Please contribute back to the project by sending your comments, questions, and suggestions to the Stinger mailing list. Thanks!

To join the OWASP Stinger mailing list or view the archives, please visit the [http://lists.owasp.org/mailman/listinfo/owasp-stinger subscription page].

=Project Sponsors=

The Stinger project is sponsored by [http://www.aspectsecurity.com http://www.owasp.org/images/d/d1/Aspect_logo.gif].

[[Category:OWASP Stinger Project]]