[Esapi-user] WAF 2.0? alpha on repository

Calderon, Juan Carlos (GE, Corporate, consultant) juan.calderon at ge.com
Thu Mar 24 11:27:09 EDT 2011

The new version of ESAPI WAF is committed to the Google code repository

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
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
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
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

More information about the Esapi-user mailing list