[Esapi-user] Validation help

Jeff Williams jeff.williams at aspectsecurity.com
Wed Jan 30 18:21:30 UTC 2013


Hi Luke,

It’s a great question.  A logging services has a few requirements around security – the principal one being to ensure the integrity of the data being logged!  We should also be careful about injection into the log directly, and also downstream injection – including if the events get stored in a database or viewed in an HTML viewer.  A great logging service should also make it easy to handle handle sensitive information that is part of events to be logged (perhaps by using **** or other obfuscation).

So, I don’t think validating data to be logged is a great idea. It’s preferable to make the data safe to log and safe for downstream consumers of the log data.  Should you canonicalize?  While I generally prefer to deal with canonicalized data, here I’m leaning towards logging the original data.  That way you know exactly what people are sending you and you’ll have the full evidence when you’re in there doing forensics.

I think a two part strategy on sensitive data makes sense.  First to make it easy for developers to indicate which data is sensitive. For example, maybe the API (like ESAPI) allows you to log a request or other collection of data, and enables you to specify which parts of that collection are sensitive.  The second piece is to monitor for attempts to log sensitive data in particular formats, such as credit card and social security numbers.

You need to do something to make sure that events can’t corrupt your log format.  Often this means detecting and handling CR/LF and other characters (TAB?) that your log might use for formatting.  You also want to make sure that there is no SQL injection if the data is going into a database – primarily through the use of parameterized queries.

Finally, you want to prevent injection in downstream systems that will be rendering the logs, such as the HTML viewer you mentioned.  Should you escape the data in the logs?  I typically recommend against this, and put the requirement on the log viewer to properly handle “untrusted” data.  But if this isn’t possible, and you know the downstream systems in question, you can escape at the time of logging – at the cost of a little log event integrity.

ESAPI has support for a lot of this in the Logger – would be interesting to hear how it goes exposing this as a service.

--Jeff

From: esapi-user-bounces at lists.owasp.org [mailto:esapi-user-bounces at lists.owasp.org] On Behalf Of Luke Biddell
Sent: Wednesday, January 30, 2013 5:25 AM
To: esapi-user at lists.owasp.org
Subject: [Esapi-user] Validation help

Chaps,

I'm hoping to canvas your opinion around some input validation/canonicalization we're looking to do.

The scenario is that we're building a form of event logger. The API to the event logger is internal only at the moment, but we will open it up as an authenticated REST API at some point in the future.

The event itself is pretty standard in most respects, it has a title, tags and so forth. Validating these is pretty easy using the ESAPI validator and I'm comfortable we've got that part correct.

The part I'm uncomfortable with is validating the body of the event.

The intention is that we might store some xml (etc of a failed soap call) or some json or maybe even HTML. It's going to be pretty free form.and we don't want to restrict it too much. However, the events will surface in an HTML event viewer application.

So I'm fishing for advice on how to validate the event body. We could do some black-listing  but that always feels like the path to the dark side. But, white-listing something that's so free format is also proving hard to envision.

Do you chaps have any experience around this pattern? Do we need to narrow our scope around the format?

Extremely grateful of any help you can provide.

Luke
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.owasp.org/pipermail/esapi-user/attachments/20130130/f2f7284a/attachment.html>


More information about the Esapi-user mailing list