Sunday, June 28, 2009

ESAPI Logging

The OWASP ESAPI Logging interface is a security-centric but thin abstraction on top of traditional high-performance logging API's. There are both Log4j and native Java Logging default ESAPI logging implementations. The Log4j  implementation is especially mature.

The logging interface of the OWASP ESAPI library pre-defines 4 types of log files entries specific to the glory of security monitoring.

public static final EventType ....
EVENT_SUCCESS = new EventType( "EVENT SUCCESS", true);
EVENT_FAILURE = new EventType( "EVENT FAILURE", false);

Attributing every log entry with a security type is fundamental to ESAPI. Your implementation of ESAPI can extend or change this list if desired. 

ESAPI also supports a hierarchy of logging levels which can be configured at runtime to determine the severity of events that are logged, so that those log entries below the current threshold that are discarded. This is a common logging API feature and includes the following severity levels (fatal, error, warning, info, debug, trace). 

The ESAPI team considered simply adding a security severity level to Log4J, but decided that was not enough. We wanted to force a programmer to tag every log entry as a security event (or not), regardless of severity level. We did not add yet another logging abstraction to your life lightly.

The reference implementations also includes the following protections:
  • encodes any CRLF characters included in log data in order to prevent log injection attacks
  • optionally encodes HTML characters into the HTML entity to protect web based log viewing software
  • provides a mechanism to log session ids referentially so that sessions can be tracked in log files without exposing real session identifiers that could be used to hijack active sessions
  • provides a mechanism to automatically log HTTP post/get variables while allowing for masking of passwords and other security-critical information that should not be logged
Much of this is configurable in 

Specify your application name if you wish to log it. 
# If you use an HTML log viewer that does not properly HTML escape 
# log data, you can set LogEncodingRequired to true
# LogFileName, the name of the logging file. Provide a full directory path (e.g., C:\\ESAPI\\ESAPI_logging_file) if you
# want to place it in a specific directory.
# MaxLogFileSize, the max size (in bytes) of a single log file before it cuts over to a new one (default is 10,000,000)

So now you want to (securely) log. Right on. Simply specify a logger in each class that requires logging:

private final Logger logger = ESAPI.getLogger(SimpleESAPIFilter.class.getName());

And log away!

logger.error(Logger.SECURITY_FAILURE,  "session has expired, log out user");

Here is an example of a log entry from one of my projects at Aspect. I'm not deploying on a cluster, yet, so I supressed the server IP, port and appName via

2009-06-29 05:48:25,281 WARN  IntrusionDetector SECURITY FAILURE Anonymous:0@unknown:unknown Incorrect password provided for dave
org.owasp.esapi.errors.ValidationException: Login failed
at com.aspectsecurity.arms.web.SimpleESAPIFilter.doFilter(
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(
at org.apache.catalina.core.ApplicationFilterChain.doFilter(
at org.apache.catalina.core.StandardWrapperValve.invoke(
at org.apache.catalina.core.StandardContextValve.invoke(
at org.apache.catalina.core.StandardHostValve.invoke(
at org.apache.catalina.valves.ErrorReportValve.invoke(
at org.apache.catalina.core.StandardEngineValve.invoke(
at org.apache.catalina.connector.CoyoteAdapter.service(
at org.apache.coyote.http11.Http11Processor.process(
at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(
at org.apache.tomcat.util.threads.ThreadPool$
2009-06-29 05:48:25,281 ERROR com.aspectsecurity.arms.web.actions.ARMSBaseAction EVENT SUCCESS Anonymous:0@unknown:270186 ENTRY POINT FOR ALL ACTIONS: 1246268905281
2009-06-29 05:48:25,281 ERROR com.aspectsecurity.arms.service.HibernateAccessController SECURITY SUCCESS Anonymous:0@unknown:270186 START assertAuthorizedForAction : action=com.aspectsecurity.arms.web.actions.user.LoginSubmitAction
2009-06-29 05:48:25,281 ERROR com.aspectsecurity.arms.service.HibernateAccessController SECURITY SUCCESS Anonymous:0@unknown:270186 ACCESS GRANTED assertAuthorizedForAction completeActionName=com.aspectsecurity.arms.web.actions.user.LoginSubmitAction IS NOT MANAGED, SO ALLOW GLOBAL ACCESS

Thursday, June 25, 2009

One file to secure them all

Can you imagine having a WebAppSec program for your company that standardized on a open source secure code library, which was vetted by many smart people, and had several supporting tools available that could be used to ensure its use? I can....

Jeff is getting close to releasing ESAPI 2.0. I was checking out the new ESAPI default configuration file, checking in a little bit of cleanup, and was very taken aback by all of the rich appsec defense categories that it covers.

# Properties file for OWASP Enterprise Security API (ESAPI)
# You can find more information about ESAPI
# WARNING: Operating system protection should be used to lock down the .esapi
# resources directory and all the files inside.  Note that if you are using file-based
# implementations that some files may need to be read-write as they get
# updated dynamically.
# Before using, be sure to update the MasterKey and MasterSalt as described below.
# ESAPI Configuration
# ESAPI is designed to be easily extensible. You can use the reference implementation
# or implement your own providers to take advantage of your enterprise's security
# infrastructure. The functions in ESAPI are referenced using the ESAPI locator, like:
#      ESAPI.encryptor().encrypt( "Secret message" );
# Below you can specify the classname for the provider that you wish to use in your
# application. The only requirement is that it implement the appropriate ESAPI interface.
# This allows you to switch security implementations in the future without rewriting the
# entire application.
# DefaultAccessController requires ESAPI-AccessControlPolicy.xml in .esapi directory
# FileBasedAuthenticator requires users.txt file in .esapi directory
# Log4JFactory Requires log4j.xml or in classpath -

# ESAPI Authenticator
# RememberTokenDuration (in days)
# Session Timeouts (in minutes)

# ESAPI Encryption
# The ESAPI Encryptor provides basic cryptographic functions with a simplified API.
# To get started, generate a new key using java -classpath esapi.jar org.owasp.esapi.reference.JavaEncryptor
# There is not currently any support for key rotation, so be careful when changing your key and salt as it
# will invalidate all signed, encrypted, and hashed data.
# WARNING: Not all combinations of algorithms and key lengths are supported.
# If you choose to use a key length greater than 128 (and you should), you must download the
# unlimited strength policy files and install in the lib directory of your JRE/JDK.
# See for more information.

# AES is the most widely used and strongest encryption algorithm

# Do not use DES except in a legacy situation

# TripleDES is considered strong enough for most purposes


# ESAPI HttpUtilties
# The HttpUtilities provide basic protections to HTTP requests and responses. Primarily these methods 
# protect against malicious data from attackers, such as unprintable characters, escaped characters,
# and other simple attacks. The HttpUtilities also provides utility methods for dealing with cookies,
# headers, and CSRF tokens.
# Default file upload location (remember to escape backslashes with \\)
# Force HTTP only on all cookies in ESAPI SafeRequest
# File upload configuration,.pdf,.doc,.docx,.ppt,.pptx,.tar,.gz,.tgz,.rar,.war,.jar,.ear,.xls,.rtf,.properties,.java,.class,.txt,.xml,.jsp,.jsf,.exe,.dll
# Using UTF-8 throughout your stack is highly recommended. That includes your database driver,
# container, and any other technologies you may be using. Failure to do this may expose you
# to Unicode transcoding injection attacks. Use of UTF-8 does not hinder internationalization.
HttpUtilities.ResponseContentType=text/html; charset=UTF-8

# ESAPI Executor

# ESAPI Logging
# Set the application name if these logs are combined with other applications
# If you use an HTML log viewer that does not properly HTML escape log data, you can set LogEncodingRequired to true
# LogFileName, the name of the logging file. Provide a full directory path (e.g., C:\\ESAPI\\ESAPI_logging_file) if you
# want to place it in a specific directory.
# MaxLogFileSize, the max size (in bytes) of a single log file before it cuts over to a new one (default is 10,000,000)

# ESAPI Intrusion Detection
# Each event has a base to which .count, .interval, and .action are added
# The IntrusionException will fire if we receive "count" events within "interval" seconds
# The IntrusionDetector is configurable to take the following actions: log, logout, and disable
#  (multiple actions separated by commas are allowed e.g. event.test.actions=log,disable
# Custom Events
# Names must start with "event." as the base
# Use IntrusionDetector.addEvent( "test" ) in your code to trigger "event.test" here

# Exception Events
# All EnterpriseSecurityExceptions are registered automatically
# Call IntrusionDetector.getInstance().addException(e) for Exceptions that do not extend EnterpriseSecurityException
# Use the fully qualified classname of the exception as the base

# any intrusion is an attack,disable,logout

# for test purposes,disable,logout

# rapid validation errors indicate scans or attacks in progress
# org.owasp.esapi.errors.ValidationException.count=10
# org.owasp.esapi.errors.ValidationException.interval=10
# org.owasp.esapi.errors.ValidationException.actions=log,logout

# sessions jumping between hosts indicates session hijacking,logout

# ESAPI Validation
# The ESAPI validator does many security checks on input, such as canonicalization
# and whitelist validation. Note that all of these validation rules are applied *after*
# canonicalization. Double-encoded characters (even with different encodings involved,
# are never allowed.
# To use:
# First set up a pattern below. You can choose any name you want, prefixed by the word
# "Validation." For example:
#   Validation.Email=^[A-Za-z0-9._%-]+@[A-Za-z0-9.-]+\\.[a-zA-Z]{2,4}$
# Then you can validate in your code against the pattern like this:
#   Validator.getInstance().getValidDataFromBrowser( "Email", input );
#   Validator.getInstance().isValidDataFromBrowser( "Email", input );
Validator.CreditCard=^(\\d{4}[- ]?){3}\\d{4}$
Validator.SSN=^(?!000)([0-6]\\d{2}|7([0-6]\\d|7[012]))([ -]?)(?!00)\\d\\d\\3(?!0000)\\d{4}$

# Validators used by ESAPI

# Global HTTP Validation Rules
# Values with Base64 encoded data (e.g. encrypted state) will need at least [a-zA-Z0-9\/+=]
Validator.HTTPParameterValue=^[a-zA-Z0-9.\\-\\/+=_ ]*$
Validator.HTTPCookieValue=^[a-zA-Z0-9\\-\\/+=_ ]*$
Validator.HTTPHeaderValue=^[a-zA-Z0-9()\\-=\\*\\.\\?;,+\\/:&_ ]*$
Validator.HTTPQueryString=^[a-zA-Z0-9()\\-=\\*\\.\\?;,+\\/:&_ ](1,50)$
Validator.HTTPURI=^[a-zA-Z0-9()\\-=\\*\\.\\?;,+\\/:&_ ]*$

# Validation of file related input
Validator.FileName=^[a-zA-Z0-9!@#$%^&{}\\[\\]()_+\\-=,.~'` ]{0,255}$
Validator.DirectoryName=^[a-zA-Z0-9:\\\\!@#$%^&{}\\[\\]()_+\\-=,.~'` ]{0,255}$

Wednesday, June 17, 2009

OWASP Podcast #26 - April News part 2

I just pushed OWASP Podcast #26 live. We had Tom Brennan (White Hat Security), Alex Smolen (Foundstone), Jeff Williams (Aspect) and Andre Gironda (The "House" of AppSec) on the show - a very mixed group with different perspectives.

Download options and show notes are here or just grab the mp3

PS : We discussed the following articles:
4/16 Gary McGraw uses statistics to show that Software (Application) Security has come of age
Michael Sutton discusses history of XSS from Defcon 10 (2002) to the present day (Twitter worm)
Jeremiah uses McDonalds and Mortons as comparatives for black-box vs. white-box security testing
OWASP Catalyst announced
Paco lists 5 reasons for software certifications
Rohit Sethi of SecurityCompass posts a blog post on a new Security Compass Labs blog about "Security Analysis of Core Java Enterprise Patterns"
mario heiderich posts some results of browser fuzzing on extraneous characters in tags
The Plynt blog asks the question, "How frequently shoud Applications be Tested?"
Wendel Guglielmetti Henrique from Trustwave and Sandro Gauchi of EnableSecurity spoke at TROOPERS09 in Munch about "The Truth of Web Application Firewalls: what the vendors do NOT want you to know"
Ryan Barnett gives guidance on how best to make VA+WAF work together
Ed Bellis and Trey Ford start a PCI effort to ensure their activities uniformly meet PCI requirements, and for those getting started - to aid in building a website security strategy that also ensures sustainable PCI compliance.

Friday, June 12, 2009

OWASP Podcast #24 - April News part 1

OWASP Podcast #24 - Part 1 of the OWASP Newscast for April 2009 - is now live!

OWASP Podcast #24 features Alex Smolen, Andre Gironda and Jeff Williams. Andre did all of the extensive copy editor work. We cover a variety of Web App Sec articles found here. The show lasts about 40 minutes.

To listen to OWASP Podcast #24 you can download the mp3 file directly, subscribe to the RSS feed, subscribe directly to iTunes!

Monday, June 8, 2009

Has WHS jumped the shark?

Does the "WhiteHat Website Security Certification Program" demonstrate that WHS has jumped the proverbial shark?

25% or more of WHS's customers demanded a logo program of this nature, says Jeremiah Grossman, CTO of WHS. Customer demand is not something to ignore lightly.

By the same token, website logo programs of this nature have a dubious past, at best.

Take McAfee's "Hack Safe" program as an obvious example. The level of negative press that the "Hacker Safe" program has generated to date is outstanding.

McAfee 'Hacker Safe' cert sheds more cred. Rubber stamp factory exposed

More bad news for McAfee, HackerSafe certification

Hackersafe? Not so much.

Russ McGee had a very interesting blog post that was favorable to WHS's new website cert program. In the comment section, Jeremiah states:

I think it's also fair to say that what we're offering is more of a "Trust mark" than "Security mark." We do not want lay claim as to the implied security of a website, or the lack thereof. Doing so is a very slippery slope. If our mark does that it is not our intent and we are open to ideas on how best to clarify its true meaning.

To answer your question, only Sentinel customers may display our mark -- which does not come cheaply as compared to others. Organizations who use the Sentinel Service are those who really care about security and the mark should represent that.

and states:

The “website security by WhiteHat Security” mark allows Sentinel subscribers to assure their site visitors that the WhiteHat Sentinel Services is being actively deployed to safeguard confidential data from security breaches and hacker attacks

Jeremiah was faced with a rather difficult choice : upset his customer, or upset some in the security community.

But I must call this a "security fail" for for time being.

a) This cert is not claiming that the website is secure
b) This cert claims that Whitehat Security is the web security service provider, only
c) This cert is consumer based; it's meant for the consumer not the security pro
d) A security-ignorant consumer (the masses) will incorrectly conclude that the website IS secure based on seeing the WHS certification logo, even thou WHS is not making that claim

We need more in-depth verification and more process, not less. Projects like the OWASP Application Security Verification Standard meets that challenge head-on.

PS: So in a few years, when we have a "Aspect Assured" logo, please give me a hard time. :)

OWASP ASVS Release Version published

Release quality OWASP projects are the level of quality of professional tools and documents.

Application Security Verification Standards are specifications produced by OWASP in cooperation with secure applications developers and verifiers worldwide for the purpose of accelerating the deployment of secure Web applications. First published in 2008 as a result of an OWASP Summer of Code grant and meetings with a small group of early adopters, the ASVS documents have become widely referenced and implemented. Further development of ASVS occurs through mailing list discussions and occasional workshops, and suggestions for improvement are welcome. You can download it here (

For more information, please contact us. Mike Boberski, Jeff Williams, and Dave Wichers are the primary authors.