Support for custom logging in CSRF Protector Library and more

Here are a few updates to CSRF Protector Library. Let’s call it version 1.0.1

Major features

  1. Support for custom logger
    So with insufficient logging and monitoring in OWASP Top 10 2017, logging and monitoring is more serious concern than ever, now. So far, CSRF Protector had support for file based logging only, and it was required by the library to have logging path (absolute or relative) mentioned in the config file. It’s a problem for developers who try to integrate it with an existing application which has it’s own logger implemented or if there are organisational policies in place which enforces certain kind of logging.
    Only way to deal with this was modifying the logger method coupled with the library. In latest change I have decoupled the logger object with the library and developer can initialize the library to use custom logger.The csrfProtector::init method now accepts an additional optional parameter $logger

    public static function init($length = null, $action = null, $logger = null) {

    This is supposed to be an object of a class that implements the LoggerInterface interface.

    interface LoggerInterface {
        public function log($message, $context = array());
    }

    In case the parameter is not provided – the default file based logger – csrfpDefaultLogger is used;

    Here’s an example of a custom logger which let’s say send data to http end point

    class CustomLogger implements LoggerInterface {
        public function log($message, $context = array()) {
            //// send the message to http endpoint
            $context['message'] = $message;
            $encodedMessage = json_encode($context);
            //// send ($encodedMessage)
        }
    }
    
    //// Initialize the library with this logger
    csrfProtector::init(null, null, new CustomLogger());
  2. X-CSRF-Protection removed from response header. This can make applications vulnerable to known vulnerabilities in libraries. This was reported by a developer.
  3. Options added to make CSRF Token in cookie https only and it’s expiry time configurable.
  4. Log path in configuration file (logDirectory) can be absolute or relative.
  5. jsUrl path in the configuration file can be set to false if developers want to include it themselves in HTML output. Last three changes (including this) were done by Brad Stoney, thanks to him!

There are a couple of more changes in pipeline, lot of them are reported here;

Also, here’s link to latest release: https://github.com/mebjas/CSRF-Protector-PHP/releases

Leave a Reply

Your email address will not be published. Required fields are marked *