[Esapi-user] WAF 2.0? alpha on repository

Christian Heinrich christian.heinrich at owasp.org
Fri Apr 1 22:37:33 EDT 2011

Juan and Jim,

Since I appear to be left out of the discussion

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