Category Archives: security

Blogposts on blog.futtta.be about IT- and more specifically web application security (e.g. about some dangers in PHP, xss, …)

Autoptimize < 2.7.7 security vulnerabilities debrief

screenshot of the arbitrary file upload fix on github. quite happy with my work thereWith Autoptimize 2.7.7 released on August the 23rd and having been pushed to all sites that were still on 2.7.0-2.7.6 by the WordPress plugins team on Aug. 30th and 31th, resulting in just under one million downloads in 8 days time, it is now the moment for a small debrief of the security issues that were fixed in this version.

2.7.7 fixed two vulnerabilities, one authenticated cross-site scripting and one arbitrary file upload.

  1. XSS:
    1. Problem: administrator users were able leave JavaScript in the exclusion-fields for CSS and JS optimization, leading that JS to be executed when the page was (re-)loaded.
    2. Risk: This could be abused by one administrator to execute JS against another administrator.
    3. Solution: This was fixed by applying esc_html (to become esc_attr in the next version as suggested by George Stephanis) to escape the JS-code and avoid it getting executed.
  2. Arbitrary File Upload:
    1. Problem: the code that processes Critical CSS settings imports did insufficient checks to ensure no malicious files were uploaded as it lacked a user capability check, did not check file extension of to uploaded file to be zip and did not check the contents of the zip-file. It did however check for a correct nonce for that specific action.
    2. Risk: this could lead to authenticated attackers uploading PHP-files that could be executed, but that risk was very much limited by the nonce-check (which all exploits I have seen happily ignore).
    3. Solution: the code has been updated to do a capability check, to make sure the file uploaded is a zip-file and most importantly to delete any unknown file found immediately after unzipping (based on an list of known-good files).

A big thank you to the two security researchers (Erin Germ for the XSS and an anonymous whitehatter for the file upload problem) who reported these vulnerabilities in a responsible manner and to the WordPress plugin team for their invaluable help in keeping our users safe.

Autoptimize & Trojan.Cryxos.2960: false positive

I’ve had a couple of reports of Bitdefender flagging optimized JS as infected by Trojan.Cryxos.2960. I investigated earlier today and this almost certainly is a false positive. If you want you can “solve” this hiccup by excluding wp-includes/js/imagesloaded.min.js from JS optimization.

bol.com: please don’t share my data with Facebook

NoScript remains one of my favorite browser addons (or plugins or whatever they’re called these days). Look what it just proposed to block while browsing bol.com (one of the big online retailers in BE and NL);

So when does GDPR go in effect exactly and will I be able to opt-out of data-sharing from that moment onwards?

Code snippet to block author pages

So you can remove the author-pages with an author.php file in your (child) theme, but what if you don’t want to touch the theme you ask? Well, I just added this code snippet to two of the sites I manage to stop user-enumeration (which can be done on any WordPress site by going to /index.php?author=1):

add_action('wp','no_author_page');
function no_author_page() {
  if (is_author()) {
    global $wp_query;
    $wp_query->set_404();
    status_header( 404 );
    get_template_part( 404 );
    exit();
  }
}

Disclaimer: the bulk of above code was shamelessly copy/ pasted from https://wordpress.stackexchange.com/a/27124

No REST for the wicked

After the PR-beating WordPress took with the massive defacements of non-upgraded WordPress installations, it is time to revisit the point-of-view of the core-team that the REST API should be active for all and that no option should be provided to disable it (as per the decisions not options philosophy). I for one installed the “Disable REST API” plugin.

Lykke Li - No Rest For The Wicked
Watch this video on YouTube.

Warning WordPress plugin users about their old PHP

After my initial disbelief about the amount of WordPress installations still on the slow and vulnerable PHP 5.2.17 (or older), I decided to warn users of my plugin with an non-dismissable warning on the plugin’s settings-page (and only there, so it’s not a default WordPress admin notice) cluttering the entire backend):

php52_warning_aoThis is going in AO 2.0.2 (out later today) and will in the future also be added to WP YouTube Lyte and WP DoNotTrack (both of which have a smaller reach).

If you’re a plugin or theme developer and want to warn your users as well (without blocking them), here’s the code I used (do change the translation-domain from “autoptimize” into one that is applicable to your plugin):

<?php if (version_compare(PHP_VERSION, '5.3.0') < 0) { ?>
    <div class="notice-error notice">
        <?php _e('<strong>You are using a very old version of PHP</strong> (5.2.x or older) which has <a href="http://blog.futtta.be/2016/03/15/why-would-you-still-be-on-php-5-2/" target="_blank"> serious security and performance issues</a>. Please ask your hoster to provide you with an upgrade path to 5.6 or 7.0','autoptimize'); ?>
    </div>
<?php } ?>