[Esapi-php] Logger status
mike.boberski at gmail.com
Sun Feb 14 16:10:28 EST 2010
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!!
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
> 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.
> 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
> 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 ;)
> Esapi-php mailing list
> Esapi-php at lists.owasp.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Esapi-php