23 Jan

WordPress Plugin Security Review: Crayon Syntax Highlighter

For our third security review of a plugin based on the voting of our customers, we reviewed the plugin Crayon Syntax Highlighter.

If you are not yet a customer of the service you can currently try it free for your first month and then start suggesting and voting on plugins to get security reviews after your first payment for the service. For those already using the service that haven’t already suggested and voted for plugins you can start doing that here.

The review was done on version 2.8.4 of Crayon Syntax Highlighter. We checked for the following issues:

  • Insecure file upload handling (this is the cause of the most exploited type of vulnerability, arbitrary file upload)
  • Deserialization of untrusted data
  • Security issues with functions accessible through WordPress’ AJAX functionality (those are a common source of disclosed vulnerabilities these days)
  • Persistent cross-site scripting (XSS) vulnerabilities in publicly accessible portions of the plugin
  • Cross-site request forgery (CSRF) vulnerabilities in the admin portion of plugins
  • SQL injection vulnerabilities (the code that handles requests to the database)
  • Reflected cross-site scripting (XSS) vulnerabilities
  • Lack of protection against unintended direct access of PHP files

Results

We found two issues, neither of them likely to lead to a website being exploited.

The plugin hasn’t been updated for 9 months and listed as only being compatible up to WordPress 4.2.0, so we didn’t try to notify the developer of the issues ahead of the release of the results of the review (if they were more serious then we likely would have), but we will open a new issue on the GitHub project for the plugin mentioning them.

Lack of CSRF Protection in AJAX Accessible Functions

The plugin makes a series of function accessible to those that can manage_options capability, which would normally be only Administrator-level users:

if (current_user_can('manage_options')) {
    add_action('wp_ajax_crayon-ajax', 'CrayonWP::ajax');
    add_action('wp_ajax_crayon-theme-editor', 'CrayonThemeEditorWP::content');
    add_action('wp_ajax_crayon-theme-editor-save', 'CrayonThemeEditorWP::save');
    add_action('wp_ajax_crayon-theme-editor-delete', 'CrayonThemeEditorWP::delete');
    add_action('wp_ajax_crayon-theme-editor-duplicate', 'CrayonThemeEditorWP::duplicate');
    add_action('wp_ajax_crayon-theme-editor-submit', 'CrayonThemeEditorWP::submit');
    add_action('wp_ajax_crayon-show-posts', 'CrayonSettingsWP::show_posts');
    add_action('wp_ajax_crayon-show-langs', 'CrayonSettingsWP::show_langs');
    add_action('wp_ajax_crayon-show-preview', 'CrayonSettingsWP::show_preview');
}

Those functions lack protection against cross-site request forgery (CSRF), which prevents an attacker from being able to cause someone else to take an action they did not intend to if they can get them to access a URL they control.

The functions there that look to have potential for security issues involve the plugin’s theme editor. In looking over the functions we couldn’t find directly exploitable issues, but it is possible through that to place arbitrary PHP code in a file on the website. The file will have a .css extension, so it can’t be executed directly, but if combined with a local file inclusion (LFI) vulnerability, it could be executed. That combination of events is very unlikely to occur.

Lack of Protection Against Direct Access to Files

Numerous .php files that look like they are not intended to be accessed directly are lacking code at the beginning of the file to restrict direct access to the files. In the files we looked over we didn’t see anything that could be exploited due to that.

Leave a Reply

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