Part 3: Safety nets vs. bad code

If you haven’t looked at part 1 and 2 here, I suggest you do before reading on. This is a direct continuation of part 1.

So the original $wpdb->prepare vulnerability, which, I remind you is based on a potential typo in third-party code, is followed up with a new potential vulnerability based on double preparing a query. So again, bad third-party code.

So here’s one for you. If a developer does $wpdb->prepare( "SELECT * FROM wp_users where ID = %d OR %d". $_GET['param1'], $_GET['param2'] ); (note the . instead of the ,) do I also get a $500 bounty? How far will this go? Will the method be removed completely because #security? To what extent should WordPress and PHP be blamed for potential developer mistakes?

Shouldn’t these be addressed in the actual third-party code and not in core? I’m at a complete and utter loss now. What’s next?

Shout outs to Slavco for bringing all these issues up both with the codebase and the community, and how things are or should be handled.

On WordPress Security and Contributing

…and how neither really worked today.

A sad story in two parts, where I’m rash, harsh and untactful. An explanation, a rant, a call for support, a call for action. You do not have to agree with me, I may be just an asshole and haven’t realized it yet 😉

Continue reading

Large and Laggy Gravity Forms

Over at GravityView, I have the pleasure of working on Gravity Forms-related things and sometimes we have a performance issue on our hands. This time it was an issue with a form that has about 15 visible conditional fields, about 300 (yes, three, zero, zero, three hundred :)) hidden calculation fields and a product total at the end.

Slow Gravity Forms

This form was very laggy in the browser. Any interaction took around 3 seconds to propagate through, blocking the rendering thread completely.

Continue reading

12 WordPress Plugin Vulnerabilities in 12 Months

I’m challenging myself to find 12 plugin vulnerabilities in the next 12 months, right in time for WordCamp Moscow 2018, where I’ll present peculiar vulnerable code and talk about practical security mistakes that don’t get caught by the official plugin repository review process.

Javo Themes Spot LFI Vulnerability

Whew, it’s been a while…

I’ve had the misfortune to work with yet another theme from ThemeForest. A $60 premium theme and nothing less! Meet Javo Spot by Javo Themes…

Javo Theme Vulnerability

Within half an hour of fiddling with it, trying to filter the output of their Listings Directory (which ended up being a 5-hour pain-in-the-butt task, which is a story for another day), I came across a glaring unauthenticated Local File Inclusion vulnerability (an LFI for short).

Continue reading

WordPress Nonces Vulnerabilities

Quick Page/Post Redirect Plugin: A Case Study

Quick Page/Post Redirect Plugin has 200,000+ active installs, with version 5.1.5 and older vulnerable to an attacker setting redirects to any URLs in bulk.

Quick Page/Post Redirect WordPress Plugin Vulnerability

And why? All because the developer thinks a 5-byte WordPress Nonce will stop the bulk redirect import functionality from running. Newsflash: It won’t

Continue reading

Dynamic Python Mixins

I was pretty surprised to find out how straightforward it is to create mixin factories and templates in Python. I had a bunch of classes with attributes that needed special getter and setter methods with JSON serialization logic inside of them.

class Model:
    parameter = None

    def get_parameter(self):
        return json.loads(self.parameter)

    def set_parameter(self, value)
        return self.parameter = json.dumps(value)

With several such classes, each containing different amount of attributes that need JSON setters and getters I was aiming to keep it DRY with mixins, but since the number of attributes and their names differ between classes, I’d need a template mixin, a mixin factory that generates mixins dyanmically.

Continue reading

Lighthouse – WordPress Performance Plugin Review

Like many rants, this one starts with a promise. One made by the developers of Lighthouse on their marketing page:

…optimize MySQL tables by removing all unused table space (both MyISAM and InnoDB)…

Lighthouse WordPress

All unused table space for InnoDB via a PHP plugin? Suspicious, I got my hands on a copy of the plugin to see how it accomplishes this claimed feat. Well, obviously it didn’t reclaim all InnoDB tablespace, just some of it using the OPTIMIZE TABLE method (only effective when innodb_file_per_table is set to “on” which is enabled by default in MySQL 5.6.6 and higher). The ibdata file remained untouched.

Okay, no problem, not unexpected. But then I read into some of the other code and a second, much more substantial promise:

A zero-footprint tuning plugin…

…I became pretty angry. I’ve always been a skeptic of magic optimization plugins, and Lighthouse was unfortunate enough to get my review.

Continue reading

Remove Duplicate WordPress Category Pages

A rather peculiar problem has come my attention yesterday. WordPress has an infinite amount of category pages that are absolutely identical. For example:

This happens for all hierarchical taxonomies, and here is why. Basically, WordPress only queries the last term in the path.

Continue reading

WordPress Dashboard Autobookmarks

Here’s something I put together as a conceptual idea. WordPress Dashboard Autobookmarks keeps track of how popular a dashboard page is by counting how many times it’s been visited by an administrator and provides an Admin Bar menu with the most often used dashboard screens. This allows administrators to keep returning to their most-used dashboard screens at click of a button.

WordPress Dashboard Autobookmarks

The plugin can be found on GitHub and is at a highly experimental stage for now.