[Esapi-php] Logger status

[Mike Boberski]

Whoa, nice. I'll review in detail. Let's put the items/questions below into
a Google Code issue so we don't loose track of them, and now continue on to
intrusion. Great work!!

Mike


On Sun, Feb 14, 2010 at 3:25 PM, jah <jah at jahboite.co.uk> wrote:

> Hi folks
>
> I've done about as much as I can to Logger for the moment.  The
> interface specifies that Logger should implement the following:
>
> 1) DONE - logging level
> 2) DONE - encode dangerous HTML characters
> 3) DONE - encode any CRLF characters
> 4) HOLD - log a generated logging session ID, or a hashed value of the
> session ID
> 5) record the following information with each event:
>  a) HOLD - identity of the user that caused the event and user's source IP
>  b) DONE - a description of the event (supplied by the caller)
>  c) DONE - whether the event succeeded or failed (indicated by the caller)
>  d) DONE - severity level of the event (indicated by the caller)
>  e) DONE - that this is a security relevant event (indicated by the
> caller)
>  f)  HOLD - hostname or IP where the event occurred
>  g) DONE - a time stamp
>
> Those items marked HOLD have been implemented, but depend on
> unimplemented methods to work.  I'm not exactly sure of the methods that
> will be needed to get these bits of info, but have roughly followed the
> Java version. so:
> Local hostname/IP and port number involves a call to
> ESAPI::getHttpUtilities()->getCurrentRequest() to get a request object
> and then calling its getLocalAddr() and getLocalPort() methods.
> Similarly, username and remote host might require getRemoteUser() and
> getRemoteHost() from the request object.
> A generated session id (for tracking a user in the logs without exposing
> actual session info) might require a request object and its getSession()
> method to get the session and then using a getter/setter to get/set an
> attribute such as 'ESAPI_SESSION'.
> The need for a small amount of refactoring in the future depends on
> whether or how these are implemented.
>
> Some points of note:
>
> Log4PHP does not support TRACE level log entries, but to comply with the
> Java version, TRACE has been implemented as an alias of ALL.  This might
> be a bit confusing for developers who call a trace() and expect to see
> TRACE in the log - what they'll see instead is ALL.
> Log4PHP doesn't seem to log Exceptions.  I've implemented this
> functionality in DefaultLogger by using an Exception's __toString magic
> method, substituting newlines with a pipe symbol and tagging it on to
> the end of the log message.  You'll notice these when running AllTests.
>
> DEBUG level events are currently prevented from being logged to file.  I
> put this filter in place because of the CodecDebug output which can add
> a substantial amount to log files.
> CRLF are not stripped from the log entries at the moment because that
> would render CodecDebug output unreadable.
> Log entries are being logged to both STDOUT (which means to the browser
> too) and to the logfile.
> These three items are temporary behaviours; I envisaged them being
> corrected before a release though it may already be time to do so.
> Thoughts?
>
> Test coverage is complete (unless I've forgotten something).  Each
> combination of level, event type and success/failure is tested.  All
> SECURITY type events are tested with and without supplying an
> exception.  CRLF and HTML encoding is tested.  Each of the
> aforementioned tests logs a unique string in the message, then reads the
> logfile into a string and attempts to preg_match with a pattern that
> models the expected log entry as strictly as possible.  The helper
> method that constructs this pattern for each test will need modifying
> any time the format of log entries is modified, as noted in the phpdoc
> block.
> Once all of the required information is present in log entries (IPs,
> username, session etc.) these tests will pass; at the moment they all
> fail.  The CRLF test is currently failing because CRLF removal is not
> being done.  The HTML encoding test will pass if the LogEncodingRequired
> property in ESAPI.xml is set to true.
> These tests also address Issue 4 which I've closed.
>
> I think that covers everything ;)
>
> jah
> _______________________________________________
> Esapi-php mailing list
> Esapi-php at lists.owasp.org
> https://lists.owasp.org/mailman/listinfo/esapi-php
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.owasp.org/pipermail/esapi-php/attachments/20100214/273ff4a4/attachment.html