[Esapi-user] WAF 2.0? alpha on repository

Calderon, Juan Carlos (GE, Corporate, consultant) juan.calderon at ge.com
Fri Apr 1 22:42:55 EDT 2011

I will do it :) 

Also new end user documentation is needed, today only the WAF policy is documented, but an installation procedure should be created, maybe on the wiki

Juan C Calderon
T +52 (449) 910-7858 
Softtek GDC Aguascalientes

-----Original Message-----
From: Christian Heinrich [mailto:christian.heinrich at owasp.org] 
Sent: Friday, April 01, 2011 8:38 PM
To: Calderon, Juan Carlos (GE, Corporate, consultant); Jim Manico
Cc: ESAPI Devs; ESAPI Users
Subject: Re: [Esapi-user] WAF 2.0? alpha on repository

Juan and Jim,

Since I appear to be left out of the discussion https://lists.owasp.org/pipermail/global-projects-committee/2011-March/002032.html

I would like to recommend as an initial pass:
1. Add the issues documented below to
2. Refreshing the javadoc

Please let me know your thoughts on what my involvement will be?

On Fri, Mar 25, 2011 at 2:27 AM, Calderon, Juan Carlos (GE, Corporate,
consultant) <juan.calderon at ge.com> wrote:
> The new version of ESAPI WAF is committed to the Google code 
> repository owasp-java-waf
> It am still testing it, but so far it has been working fine for me, I 
> am modifying the junit class path configuration in order to have all 
> the test cases running since they depend on ESAPI and that is no 
> longer part of the codebase.
> Here are the improvements of this version:
> Link to ESAPI API is removed and a separated eclipse project setup 
> Maven enabled for eclipse project, POM includes references to 
> bsh-core, commons-fileupload, log4j and xom. ESAPI API was added but 
> only for junit tests A dedicated thread poll refreshes WAF policy file 
> as per configured polling time Use of Log4J instead of ESAPI logger or 
> embedded logging (present on initial version) ESAPI WAF now takes 
> default log4J configuration if no logger configuration attribute is 
> specified in the WAF policy (good for integration with other systems) 
> Added new attributes "action", "target", "block-code" to rules, they 
> override global default action settings, this allows flexibility to do 
> an specific action on a per rule basis instead of just redirecting or 
> blocking on any error. E.g. redirect a user to login page in case of 
> an authentication error Bean shell rules are parsed during policy load 
> time and errors are send to logger Last broken rule is stored in a 
> session variable for later use on error page SimpleRule and 
> VirtualPatchRule both can now contain messages and thus those messages 
> can be displayed on error page as well All Rules log timestamp of 
> event to the log output (can be done with log4j configuration, but for 
> compatibility with main application, I'd rather enforce that info on 
> the log and make sure it is always stored) Virtual Patch Rules enforce 
> "Required" fields now as well
> BugFix: If global "mode" is misspelled or set to an unknown value, WAF 
> defaults to LOG mode, but also logs a warning to the logger.
> BugFix: When in Block mode, BlockCode value is validated to be an 
> integer, if validation fails WAF falls back to default BlockCode and a 
> warning is logged.
> BugFix: Redirect rule forces to provide a URL, a null URL caused the 
> WAF to send unknown HTTP codes to Browser
> BugFix: at MustMatch rule When using session object for rules, 
> variable name was trunked to length-1 causing session objects not to 
> be recognized
> BugFix: MustMatch Rule validates input variable exists before 
> validating it's content Known Bugs: Modifications to Bean Shells are 
> not automatically loaded, policy needs to be refreshed by modifying 
> the policy file and saving it
> Proposed Additional Changes
> Change Redirect to Forward on error, we will save browser and server 
> processing, broken rules can be send on a per request-basis to error 
> page and error page will be shown to user "transparently" (no URL 
> change).
> Automatically add Error page as an exception to Authentication rules, 
> since currently an infinite loop can happen (Example. Error page 
> requires authentication but user is not authenticated to see it) Block 
> code should be validated for a list of valid HTTP codes, not only to 
> be an integer.
> A Poll for all the bean shell rules should be setup to reflect changes 
> to the rule the moment they occur Implement "Learning" or "Request 
> Monitoring" mode, a derivative of LOG mode that records all the 
> requests data (headers, URL,  params, etc) that can be later used to 
> better tune rules or to define the initial set of rules per path
> Potential Design Change
> Current schema uses exception paths, we should think on allowing to 
> define paths first and then rules for that path, that will allow 
> positive validation on number of parameters, for example if a page 
> only can contain 3 parameters, we could enforce only those 3 are 
> present for that path.
> Please give it a check, have fun, and let me know on any issue you 
> face Juan Carlos Calderon 
> _______________________________________________
> Esapi-user mailing list
> Esapi-user at lists.owasp.org
> https://lists.owasp.org/mailman/listinfo/esapi-user

Christian Heinrich

More information about the Esapi-user mailing list