Half-Elf on Tech

Thoughts From a Professional Lesbian

Tag: security

  • Plugins: My Way Or Nothing

    Plugins: My Way Or Nothing

    Back when I started explaining why I dislike security plugins, I mentioned hating people who thought they knew everything.

    Noah (not his real name) is a good example of that kind of drama.

    Not Safe Enough

    Very rarely do plugins get an email that starts out with claims we’re too dumb to understand security.

    In this case, Noah submitted a search plugin. Not a security plugin. And on a quick look, it had the following serious issues:

    • direct access to files with POST calls outside of functions
    • calling wp-config.php directly to get DB access
    • non-prefixed functions, defines, and classes
    • non-sanitized data being processed and non-escaped data being output

    Pretty normal in so far as poorly written plugins go, and Noah got an email with the usual details on what’s wrong and what to fix.

    Noah did not take it well and claimed our rules were arbitrary and made to protect people. Yes? I mean, of course the rules are there to protect people! And one can argue any rule is ‘arbitrary,’ but that’s how they work. Noah went on to say that was okay, but rules had disadvantages too. To that end, sure, he’s got a point. The rules do limit innovation to an extent but usually that’s got a reason.

    The email went on for 1500 words about the problems people face (resource usage, mostly, and caching), and Noah included this gem:

    You are not able to solve these problems since you waste all of your time defining rules, handling security problems and bothering people who are offering their assistance to you for free.

    Noah via email to Plugins

    We wouldn’t have to make all those guidelines and handle security issues if people actually fixed them, but I felt that was besides the point.

    Let’s be honest here, Noah’s email was a lot of drama and words, signifying nothing at all. Making WordPress faster and having it use fewer resources is a great idea. But sir, this is an Arby’s. Or rather, Noah my man, this is a search plugin that has obvious security issues (sanitizing/escaping), makes dangerous calls that won’t always work (calling wp-config.php which can be moved), and crap for prefixes.

    Not Smart Enough

    I did pick out the line “you can’t understand what I do” and rolled my eyes. Generally speaking, if someone tells you that, they’re the fool, not you. It’s like people who jump to tell you “I have a decade experience in WordPress!” They want their perceived standing in the community to excuse behaviour. That may happen, but I never cared if it was Matt himself submitting a plugin. Security is security. Hell, I once closed my own plugin for a security issue I’d missed 5 years prior (hilariously I only realized it was mine when I was about to hit send — there was a lot of laughing).

    And I absolutely am smart enough to take one look at Noah’s code and recognize that his entire point was to have a plugin search WordPress and intentionally not use the built in WordPress security features. Like nonces. Normally that is from a lack of education and I think of it as a no-harm/no-foul. I remember when I didn’t really understand nonces, after all!

    But in Noah’s case, he believed he was smarter than everyone else using WordPress and, instead of submitting patches to improve it for everyone, he was just going to circumvent WordPress’ security entirely. And that is a non-starter.

    I am also smart enough to see his plugin could be brought into compliance pretty easily, which was why I didn’t reject, I pended.

    Not Clever Enough

    I replied to Noah explaining his rant was pretty off topic not to mention very wrong in many places. The code was not safe to use, and we generally didn’t accept plugins that didn’t ‘use’ WordPress unless it was safe.

    Perhaps I should explain a little here… See, there are two issues with calling wp-load.php or wp-config.php. The first issue is that people can, and do, move both the config file and the wp-content folders, so there would have to be a lot of fallbacks to make sure it would work for everyone. The second is that calling those directly is how you obviate WordPress’ security.

    A sneaky third is that there’s no reason you should need to do that in the first place. If you call your plugin properly, with init and so on, then you get all the fun WordPress stuff without the drama. I know it’s a concept a lot of pure PHP devs struggle with, especially when they want to have ‘a url’ that people can use on their site (like a plugin wants your site to have example.com/myplugin), because that is a little tricky with WordPress.

    In the email to Noah I made it clear. If he wanted to be hosted on WordPress.org, he had to follow the guidelines and that included our security requirements.

    I mean, come on, here’s the part of the email where I tell him to sanitize, and he asks if that’s correct:

    > When you include POST/GET/REQUEST/FILE calls in your plugin, it’s important to sanitize, validate, and escape them.

    Did you ever think, if this is really correct?

    Noah via email to Plugins

    Yes. Yes I do think it’s correct to sanitize, escape, and validate.

    Also telling him “you must use the most appropriate function for sanitizing” (by which I mean ‘don’t sanitize a number as a text field, y’all’) he says:

    Who are you, that you think you are allowed to tell me what I “must use”? Are you thinking, you would be god?

    Noah via email to plugins

    A god?

    A screenshot that says "I am a generous god."

    Jokes aside, Noah made it clear he thought the rules were bullshit, and he had no intention of ‘helping’ anyone. I shrugged, rejected his plugin, suspended his account, sent his emails to the blocked bin, and moved on my way.

    One Year Later…

    A new search plugin showed up, and at first it didn’t trigger any memories for me. In fact, this version had corrected most of the things I’d flagged in the first one. A lot of people submit similar plugins, but at this point I was about 7ish years into reviews, so I was pretty good at spotting repeats.

    Just like people have writing styles, people have coding styles.

    Around halfway through the review, something clicked. I went and checked, and lo and behold it was Noah! He used a new domain, but DNS showed the same person owned both domains. Him. And he wasn’t really trying to hide it since, when I rejected the plugin, he replied from his first account’s email.

    He explained that in the last couple of weeks, we’d ‘twice’ gotten in trouble together. I thought I hadn’t heard from him in nearly a year, and now I was worried he had used multiple accounts. But before I got into that work, I read his email.

    I Didn’t Read His Email

    It’s true. I skimmed his 2500+ word email that was filled with … well … bullshit. He claimed that the use of saved replies meant I was ignorant and only doing that because it was easy… You know what, let me bullet point.

    1. He thinks Automattic owns the plugin review team.
    2. He believes he was 100% right and I was wrong, but he made the security changes anyway.
    3. I was selfish for not listening to him, but he’s not rude for not listening to me.
    4. He doesn’t believe telling me I’m stupid and paranoid was rude.
    5. He expected me to do the emotional labor of telling him how to behave.
    6. He claimed I rejected his plugin without a word (even though he replied to the email where I explained it was for abusive behaviour).
    7. He’s mad I rejected his resubmission, even though the original email said NOT to resubmit or make a new account (… I mean …).

    I did not reply since at the end he’d said this:

    This is my very last attempt to offer my software to you. If you don’t answer this email, I will delete the plug-in. But I believe you would serve WordPress better if you would give the software a chance.

    Noah via email to Plugins

    Alas, he tried twice more that year before (seemingly) giving up.

    Oh, and no, he didn’t have other accounts. He was sniffing some glue to come up with a claim that he and I had been in contact at all after that first rejection.

  • Plugins: I Hate Security Plugins (mostly)

    Plugins: I Hate Security Plugins (mostly)

    Do not get excited. This is not going to be a name and shame post. No plugin will be named directly, though I bet a number of people will wonder if I meant their plugin.

    So here is your one and only explanation. After reviewing plugins for something between 12 and 15 years, as a pretty much daily process, I have incredibly strong opinions about development, companies, and ideologies. If you, while reading this, think I might mean you … probably not. You folks have no clue how many of the same problems I’ve seen!

    Actually, if you’ve read stories like ArsTechnica on how a plugin was tracking users, you have an idea. But it gets worse.

    With that done, I hate …

    99% of ‘Security’ Plugins

    This includes Jetpack. I know I said I wasn’t going to name and shame, and I’m not. Jetpack is the perfect illustration of the first problem with security plugins, and that is their WAF (web application firewall) requires editing files, and multiple times it’s broken on upgrade.

    I repeat, this is not a shame! The problem isn’t Jetpack is bad or wrong, here. The problem is even within a webhost, you get a dozen different versions of server software! Trust me, your webhost would loooove if all our sites were on the same server, but that isn’t how it works. You acquire servers in batches, so you get batches of ‘like’ and then god knows.

    But. Because of the myriad versions of server setups, it is impossible for Jetpack (or any WAF type plugin) to work perfectly 100% of the time. And this is especially true of upgrades, where servers prioritize different processes.

    Basically, I hate them because they can’t do the one thing for everyone, and I accept that.

    The real thing I hate about security … The things I hate…

    • They aren’t secure
    • They’re the wrong tool for the job
    • They slow your site
    • They think they know everything for everyone

    Safety in Danger

    Not being secure is as galling as you think. I have seen the vast majority of security plugins have the most basic wrong code out there. We’re talking not sanitizing, wrong sanitizing, not using prepare with SQL calls, not escaping, using sanitize functions to escape (and vice versa), and no nonces.

    All that was seen in a plugin I reviewed back in late 2022, and I remember just putting my face in my hands and shouting ‘aaaaarrrrrrgggggghhh’ loud enough to wake my aged cat. And it was not the only one.

    There are very few security plugins that have ever passed an initial review without having to be held back for security. I can only think of one in 2022-23, and they had a unique WordPress.org-only error (stable tags).

    Because of that, I’m probably never going to use anyone’s security plugin. I just cannot trust plugins that, by their nature, are trying to protect, but are not safe. It’s like locking your front door and leaving your patio doors wide open.

    Hammering with a Spoon

    I also have long said that most security plugins are the wrong tool. This directly relates to making your site slow, because you are using WordPress to monitor and secure itself. That’s always gonna be slow, folks. And honestly having your app be the check for itself has the blindingly obvious flaw of … if the site gets hacked, that plugin is gonna be useless in 10 seconds.

    The correct place for a firewall is a separate app on your server (or via DNS). The wall comes outside the town, people! It draws the line between dangers and safe.

    PS I would rename any plugin that’s a WAF to a castle or something beside wall. You’ve built a tiny fortress castle and WordPress is the noble who lives inside. You’re the last line of defence.

    The Need for Speed

    How do security plugins make a site slow? This should be obvious. If a plugin has to run on every single load of your site and check it the person visiting is an evil doer… it slows things down. The more checks, the slower.

    That’s it. Pretty simple.

    This is another reason I think they’re the wrong tool. They’re on WordPress, and run using the same specs that WordPress can. PHP is usually more limited than other commands on a server.

    I Know You Know

    The whole “I know better” schtick was popularized by Steve Jobs. He claimed he knew what customers wanted before they did.

    There was a plugin developer who had a security plugin that thought that. He got into a pissing match with another plugin that is hard to explain without naming names. Now, in this case I don’t feel the need to protect. They took to the forums and outed themselves. Heck, you can see some of the details of this saga on WPTavern.

    Even though there is a little more to the story, it really doesn’t pertain to this. Suffice to say, some of my burnout is directly related to that event, which was years before I retired from plugin reviews. Oh and no, it’s not about a safe-space situation that people seem to think I run in when I tell them I’m not going to continue a conversation. I just don’t feel the need to waste time and energy on someone who refuses to compromise. I feel that if I’m at an impasse and won’t be able to change the other’s mind, I will agree to disagree and stop arguing.

    That event is far from the only time I’ve seen someone decide “I know what is best, and I will force it” in a security plugin. Instead of giving options, or recommended settings, they go out and block what they think is wrong, regardless of the nuances. Sometimes they do it without a way to override, and that just isn’t cool.

    While the goal of perfect security is laudable, the reality is it’s impossible. There will never be a perfect solution for everyone, and if your security plugin doesn’t allow for the nuance of the real world, then I got nothing for you.

    Basically, Don’t

    This probably reads like “don’t bother with a security plugin.”

    There are some reasons you would want to use them. I use a lot of security checks on my sites, within WordPress, but for a specific purpose. See, I use them as tools to interact with services.

    For example, Akismet and spam. I have written bespoke plugins to stop a serial idiot from submitting a form so I don’t have to fire up my terminal and block IPs. I hate IP blocks. They always hurt the innocent.

    And yes, I am using the WAF from Jetpack right now on a large site! Warts and all, it’s been helpful.

    But for me? Having seen what I have with security plugins? They will always be a hard sell.

  • Why We Hate Your Security Reports

    Why We Hate Your Security Reports

    I was having a day where a bunch of security reports were dumped in my lap. There have been days where those have been hundreds. Thankfully this wasn’t, but it did make me sit back and think about why I hated so many reports.

    In general, everything can be summed up as “The person reporting doesn’t provide all the relevant information.” Sometimes they don’t know, and that’s okay. People don’t learn by osmosis, they have to be taught. But a lot of the people submitting reports do know and just don’t. And the real crux of it all? People aren’t explaining why things matter.

    Let me explain…

    The Uninformed

    These are the people who report an app and say “It’s this app because I installed it and I was hacked.” Another variant is “It’s this app because that’s where the hacked file lives.”

    And the email will have no other information. With those, I have to explain not only are they probably wrong, but I have to dig and get at the information.

    • Why do you think it’s this app?
    • Do you have any evidence?

    Those are pretty basic questions at the heart, but it’s on me to explain why correlation isn’t causation, and just because (say) Hello Dolly was infected does not mean that it was vulnerable.

    This has no solution other than education. I dislike those, but since most people are pretty cool about it when I explain how I know it’s not the app they think it is, it’s okay.

    Semi-related are people who email us security logs from their services, and those are always messy, since it’s information without enough context. Which I’ll get to in a minute.

    The Too Terse

    Sometimes reports are explanatory but not enough. “It’s an XSS in this app.”

    Now, the good news is I know what I’m looking for. The bad news is that someone who actually knows what the issue is has decided to not share, which means I now have to figure out how they figured it out. It used to be I’d do that, but then they’d email back all snarky and bitchy that I didn’t find the one they found. Nowadays I push back. “Can you please provide details?”

    That has a weird hit-and-miss. Sometimes people are pretty chill and explain. The majority do what I think of as a pre-teen eyeroll. You can actually tell they’re huffing in annoyance that someone dared ask them to unpack what was in their heads.

    To put this differently, have you ever had someone say “Hey, the website’s down.” and just … not give you an error message? You know how maddening that is? Right that’s what we’re talking about.

    The Non Explainers

    You’d think this is the same as Terse, but it’s not. The non-explainers don’t explain WHY something is a security issue.

    I know, someone’s reading this going “Hang on, but if I tell you it’s a SQL injection vulnerability, and where it is, isn’t that enough?” And the answer is, most of the time, yes! The people who give a great proof of concept, with exactly how to replicate it, in clear English, are my favourites. They break down how things happen so you can see “Oh that’s why.” But… When they don’t, it means someone (read: me) has to go and figure out “Okay, why is this bad, and how bad is it?”

    The Hater Reporters

    I can’t believe I had to add this one in, but here we are in 2021 and there are some ‘security reporter firms’ who think the best way to report an issue is

    1. make it public
    2. attempt to make other people feel bad
    3. dogshame developers

    For them, the only way forward is their road or no way at all, and they cannot be reasoned with. Eventually someone will sue them for releasing a 0-day vulnerability without even trying to privately disclose first, and when that happens, I’ll make the popcorn.

    The Issue Is Education

    If you go back through, you can see the real issues are people not unpacking what they actually know and sharing in a digestible manner! And this is terribly endemic of security companies more than anything else.

    For example, recently a security company reported a local file inclusion (LFI) issue. Now for those who don’t know, the issue is the code in question could be used to include any file on the server. Including a hacked file. But if someone just told you “Hey that’s an LFI and you’re bad!” then, even if they take the time to tell you where the issue is, if they’re not explaining to you how it’s exploitable, you may not know!

    And then, even when people explain it, they explain as if they’re talking to a developer of their caliber. I certainly am, but the people I’ve got to pass the report to (the actual devs) are not always. Even when they are, sometimes they’re total berks who will snark that it’s not worth the time to escape things at that low a risk.

    Understanding Risk

    Security is massively important but the reality is that it’s not the first thing on most people’s minds when they write code (sorry folks). Usually people concentrate on making the code work first. Then, once it works, they go back to make it safer. I’m not casting aspersions here. There’s nothing wrong with making it work first. The issues begin when people don’t take security with the proper seriousness.

    Just the other day I saw someone who had to be told that yes, you always escape content you’re echoing. Why? Because users are humans, and humans do some really stupid things. Even if you think of yourself as average, that means roughly half of your users are not as smart as you, which means that half is who you’ve got to look out for. You sanitize content you save, you scape content you echo. All. The. Time.

    And yes, I’ve seen people who are experienced developers, people with plugins whose user count is in thousands, reply that it’s not needed to escape because … it’ll make their code slower.

    Sometimes I tell people “This is why I drink.”

    Proper Education

    Now. Part of this is on the community/company. WordPress, where I do a lot of work, has decent documentation about security. In fact, as of late WordPress’ docs have been phenomenal about this!

    Here’s what the plugin dev docs say about nonces:

    If your plugin allows users to submit data; be it on the Admin or the Public side; you have to make sure that the user is who they say they are and that they have the necessary capability to perform the action. Doing both in tandem means that data is only changing when the user expects it to be changing.

    Now. That kind of explains why you want to do this, but does it explain why it’s needed for security? Only from a high level. For the crux you have to scroll down a little:

    The capability check ensures that only users who have permission to delete a post are able to delete a post. But what if someone were to trick you into clicking that link? You have the necessary capability, so you could unwittingly delete a post.

    Now that makes a lot more sense, right? That is a good doc, assuming people read it.

    And look at the bolded intro for escaping:

    Escaping means stripping out unwanted data, like malformed HTML or script tags.

    Whenever you’re rendering data, make sure to properly escape it. Escaping output prevents XSS (Cross-site scripting) attacks.

    Whenever. Not sometimes, not when it’s convenient. WHENEVER.

    And yes, this means every single time you echo anything as a variable, you damn well escape it. No questions asked.

    But when I say proper education, I mean in explaining why a specific issue is, in fact, an issue.

    Communication Is Queen

    If you’re a regular person who sent a report you weren’t sure about, you’re fine. This next bit is not about you. This is about security experts and other developers.

    Did you contact developers, privately, about issues with their code? If you’re a security company, do you have documentation on your site to explain how something in an XSS or LFI vulnerability? Did you explain in the contact why something is a risky LFI? Did you take a minute to share a Proof of Concept to illustrate how you knew something was a risk? Did you describe why and how the POC shows the risk?

    That’s what you have to do.

    You want other developers to be better and to write better code? Then you communicate, clearly, and take time to ensure what you’ve said is understandable by the recipient.

    I hate your security reports because they’re not reports at all. They’re dumping a problem on someone else and not giving them the tools to progress. You’re expecting them to do all the work you already did, which by the way is a waste of everyone’s time. It wastes my time because now I have to do everything you already did, and it wastes yours since I’ll probably ask you for the details.

    But. If you start with a private, polite, report of “Hey, I found this. Here’s how and here’s why I know it’s an issue.” then you, you my friend, are heroes. You’re actually making the entire world better for everyone.

    Thank you.

  • Vulnerability Reports Miss The Mark

    Vulnerability Reports Miss The Mark

    Lately I’ve been getting a lot of ‘vulnerability’ reports.

    I use the term loosely because the reality is these are not actually serious vulnerabilities. A couple months ago I started getting a lot of weird reports like this:

    A FLAW FOUND ON YOUR WEBSITE!

    Website Security Vulnerability Notification

    Hello, a security researcher reported a security vulnerability affecting [your] website via [company] coordinated and responsible disclosure program:

    Those can be super scary! Is there really a massive issue?

    No. But I know why it feels that way. And frankly I think a lot of these people are targeting the wrong group. Let’s get into it.

    Scare Tactics

    In the case of all the ones I got, there was only one that I felt actually was. But first, here’s what people reported:

    • The PHPInfo Page was public
    • Directory indexing
    • People can list users (aka User Name disclosures) via the REST API
    • Your xmlrpc is showing
    • Incomplete SSL Protection
    • Your email records allow spoofing/DMARC compliance

    The last one? Absolutely an issue. I thanked that person and kicked them some money. But the others? They’re issues, but they’re also incredibly minor! Heck, this user name listing ‘vulnerability’ does not take the following into consideration:

    1. It’s on a site where every author has a page
    2. We have an ‘about us’ page that lists everyone anyway
    3. Strong passwords are enforced
    4. We have a firewall

    The only way I could really improve that would be to enforce 2FA, which I’m contemplating for admins. But that begs the question… is this a vulnerability?

    Okay, let’s ask why does this work? It’s known that WordPress has a REST API. This API can be used to list public information about registered users. Now the API does ‘expose’ the user data for everyone who’s authored a public post that is shown in the REST API. Posts and pages and some custom post types included. If the user hasn’t authored posts, you won’t have permission. So again, we’re only able to list public authors. Okay.

    Could that be bad? Sure. In the same way having a front door could be bad if someone kicked it in. But ‘security’ isn’t why I would ever consider blocking that. We literally list all the authors publicly already. If someone wants to use wp-json to grab them, cool. It only shows public information we displayed already, after all.

    Why would I consider blocking? To ensure stability. That is, people hammering my site to find out that I’m not user on HalfElf (surprise!) makes my site slower. But… I have a firewall and Mod_Security, and IP Tables, which means if you hit my site enough, it’ll block you. Also a lot of stuff is cached, like it should be. Which means this is not a ‘vulnerability’ but more of a ‘best practice notice’ in my opinion.

    And finally … FFS why are you telling individual site owners this!? If you really think it’s a security issue, take it up with WordPress!

    How Do You Stop Them?

    Well, generally you fix the ‘issues.’ Even if you think it’s full of shit, you fix it. So okay, what do we do?

    PHPInfo? Locked it down. I use it for regular checks of other things. If you’re not, just delete it.

    Directory Indexing? I put this at the top of my .htaccess (and yes, you should, I’d removed it for some tests):

    ### Prevent Directory Browsing ###
Options All -Indexes

    XMLRPC? I said “Nope, not gonna change.” Because I use the WordPress iOS App.

    SSL? You’ll want to check your setup on things like SSL Checker or Immuniweb or SSL Labs. I found SerpWorx’s tool to be invaluable for spelling out what was missing. The easiest by far was SecurityHeaders.com. For that, I ended up adding this to my .htaccess:

    ### Extra Security
<IfModule mod_headers.c>
	Header set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"
	Header set X-XSS-Protection "1; mode=block"
	Header always append X-Frame-Options SAMEORIGIN
	Header set X-Content-Type-Options nosniff
	Header always set Expect-CT "max-age=7776000, enforce"
	Header set Referrer-Policy "same-origin"
	Header always set Permissions-Policy "geolocation=(); midi=();notifications=();push=();sync-xhr=();accelerometer=(); gyroscope=(); magnetometer=(); payment=(); camera=(); microphone=();usb=(); xr=();speaker=(self);vibrate=();fullscreen=(self);"
</IfModule>

    The one thing I left out was Content-Security-Policy because that one is crazy complex and needs a lot of testing since a lot of content on the site is remote and needs special rules.

    Email/DMARC? That took a lot longer, and I had to talk to my email provider to sort it out. But you can run your domain through the MXToolBox checker and see what you’re missing. It’s going to make you cry. Email sucks.

    Okay but I wanna hide users!

    I hear you. You can do this in .htaccess:

    ### Block User ID Phishing Requests
<IfModule mod_rewrite.c>
    RedirectMatch 301 ^/wp-json/wp/v2/users(.*) /about-us/

	RewriteCond %{REQUEST_URI} !^/wp-admin [NC]
	RewriteCond %{QUERY_STRING} author=\d
	RewriteRule ^ /about-us/ [L,R=301]

    RewriteCond %{QUERY_STRING} rest_route=/(.*) [NC]
    RewriteRule (.*) /wp-json/%1 [L,R=301,QSD]
</IfModule>

    Now. This means on that site if you go to example.com/?author=1 you will not go to someone’s page. But if you go to example.com/author/ipstenu/ you still would. Which IMO points out how stupid that ‘vulnerability’ is. Yes, I am aware you can see the authors. Oooooh. You’re supposed to!

    Conclusion?

    A lot of those vulnerability emails are bullshit. I politely reply “Thank you for your concern however we are not blocking access to that because the API is used by other things. It’s considered to be public knowledge anyway.” I may end up writing a form letter.

    And the sucky thing is that one of the sites that collects all that stuff relies only on the reporter to determine if it’s resolved. Both issues they have for the domain in question? 100% resolved. But they say ‘unpatched’ … probably because I told both reporters I’m not paying them.

    I added this to my profile:

    We do not accept reports of basic WordPress functionality, such as the Rest API being active, the use of xmlrpc.php, the enumeration of users, etc. Those are an acceptable risk. Please don’t bother reporting them, they should be addressed with WordPress directly, not end users.

    By the way. The bug bounty program that keeps emailing me? Uses WordPress. And guess who’s site has /wp-json/wp/v2/users available to list all their public authors? Yeah. Because it’s not a goddamn major issue.

    I know someone’s gonna point out it could be a major issue. Sure. Like having a window means your house or car could get broken into. That doesn’t mean you remove all the windows!

  • Still Not Using Plugins for Security

    Still Not Using Plugins for Security

    Seven years, and my answer to 'do I need a security plugin' is the same.

    Nope.

    What is a Security Plugin?

    A security plugin is not a plugin like 'brute force protect' or 'limit login attempts.'

    A security plugin is like Better WP Security or WordFence or a hundred other plugins that promise to scan your site and let you know what's changed.

    This is not to say that first set of plugins aren't there to make you 'safer,' it's that those are single use, targeted plugins that address a single issue. Limiting login attempts prevents someone from trying the same attack over and over and over until they get in.

    By contrast, all-in-one security plugins try to do everything. They scan your code, your data, and your site. They look for all the possible attack vectors and they try to plugin them.

    What Makes That Secure?

    That's the question I ask people. If a plugin adds in 2-factor authentication, I ask them what it does for them? Password expirations, captchas, file compares etc. Those are all good things, individually, but are they applicable for all people? What, specifically, about those things makes you more secure or not?

    Now. Before you get all shirty with me, I am well aware of what all of those things are good for. With the exception of captchas (which are not accessibility friendly, please stop using them), all of those things make a lot of sense. You expire passwords and, one hopes, require strong passwords to make it harder to break in. But if you have a 2FA setup, do you need to require rotating passwords?

    It’s All About Thinking

    Security plugins stop people from thinking about what's going on.

    I've seen it time and again, people install a plugin that 'makes them safe,' follow the bare minimum of requirements, and then install whatever they want without thinking about it, leave registrations open, and oops, get hacked.

    This is not to say that security plugins don't prevent some of that from happening, but they're often an 'after the fact' solution. That is, usually a security plugin doesn't know to block X until X has been exploited. That's kind of the nature of the beast, though, and why WordPress and many other CMS developers don't release full details on security fixes until they've been out there for a while. They want to give people a chance to upgrade before saying "Hey, y'all who didn't are super vulnerable."

    It’s Also About Speed

    Security plugins also have a tendency to make your site slower. This usually comes up when people have turned on everything that comes with a security plugin. Which goes right back to my point about thinking. The user doesn't think, because they're not yet educated, about the impact of the code on their site.

    To put it simply, the more things you ask WordPress to do before it can load a page, the slower it will be to load a page.

    Pretty cut and dried, right?

    What’s My Answer?

    I don't call this the 'right' answer or even the best one. Not everyone has access to my resources after all, so it's not fair to say "Hire Mika to think for you!" But to me, the best answer is to use the resources you have intelligently.

    Firewalls, from a server side, are all but a requirement to me. If your web host doesn't have one, and most at least have ModSecurity, get a new web host. If you disabled it on your site because a random plugin doesn't work with it, delete the plugin and turn it back on. If you can't move to a new host, look into firewalls like Incapsula or Sucuri. Put something between users and data.

    Site Scanning is a great tool, but don't run it on WordPress. A great example of smart security scanning is VaultPress. It's a remote service that has a copy of all your files and it scans the copy, not your site, for issues. There are other services you can use that scan your site without affecting traffic. Again, web hosts often have tools for this.

    Be Aware of what's going on. Don't just let security be a black box. Make sure you know what kinds of attacks are common on your site. If you're hit by a DDoS, for example, where they're just hammering your site to take it down, a 2FA plugin will not help. If they're trying to log in all the time, a scanner is probably not what you need.

    Lock It Down. If you don't need it, don't use it. If you don't need it on, turn it off. Update regularly. Don't install everything under the sun. 

    Don’t Buy Into FUD

    This is a tricky balance. On the one hand, I want to say 'don't panic if your favourite security plugin of choice tells you everything doomed!' Remember, they're trying to sell you things. But on the other … don't think everything's fine and dandy.

    It's not a simple solution. You have to simultaneously be aware of problems and not overwhelmed by them. You have to learn how to care about which ones are important to you and which are not.

    In a word, you have to think.

    And there is no plugin on the planet that can think for you.

  • Thimking About Security

    Thimking About Security

    It's been a while since I last talked about security and WordPress plugins, so I thought it was a good time to do it again.

    I still don't use any. But we'll get to that in a minute.

    Don’t Be ‘Stupid’

    My mother is one of the few people I know who has almost completely conquered the will to be stupid.

    Miles Vorkosigan on his mother, Cordelia Naismith Vorkosigan
    Brothers in Arms by Lois McMaster Bujold

    Understanding what makes something secure or insecure is not as obvious as I wish it was. I often say that the trick to being secure is not being stupid. Of course that's easier said than done, and I know it.

    Still, my record holds true that the one time I was hacked, it was from my own stupidity. I knew it was wrong and foolish and I did it anyway. And my guiding principal of security remains a constant reminder "Don't be stupid."

    But what is stupid? Every time you leave your house, you lock your doors, right? You do the idiot walk, as my grandmother Taffy called it. Keys, wallet, phone? Is the gas off? Is the heat on? Are the windows closed? You check the normal things and then you lock the door and off you go.

    Of course, we all have been an hour into an 8 hour drive and panicked "Did I close the garage!?" And for some people, even the simple act of locking the door is an arduous journey of 10 or 30 or 55 checks. In order to say 'don't be stupid' we have take ourselves honestly and seriously, and remember that 'stupid' just means 'don't not think.'

    THIMK

    That was not a typo. Nor was the title of this post.

    While we all make fun of IBM and MAD Magazine, I recall reading "Welcome to the Monkey House" by Kurt Vonnegut, and Ma Kennedy had the sign over her desk. At the time, I was unaware of the MAD magazine spoof on the matter. THINK was a sign folks at IBM had, and THIMK was the spoof.

    When I read it in Vonnegut, and bear in mind I was young and naive, I found it far more compelling than the idea of telling someone to THINK. With the letter changed, it forced me to reassess my assumptions of what the meaning was. After all, telling someone to THINK means, well, think. But telling someone to THIMK is a different matter.

    Eating the Elephant

    You know that old joke? How do you eat an elephant? One bite at a time. Well. That's security.

    I've been a loud opponent of the TSA, the way it's implemented in the US currently. It makes us feel better by making us think (N) that something is being done. And, yes, the TSA has found problems. But their job is to look through a thousand small things and find the odd-one-out. They're looking for the weird.

    When we perform a security audit over anything, be it a plugin or a server, or a door, we look for what we know is likely wrong. When I review a plugin, I look for the common issues. I skim for them, or grep for them, because I know what I'm looking for, and my eyes are trained to find it.

    But then, once I see the major and common issues aren't there, I read the whole thing. I look at the plugin as a whole entity, and I think. What does the code mean? What is it's intent?

    Metaphysical Security

    Without the ability to spy into the soul of the developer and glean an understanding of their raisons d'être, we're left with monitoring actions and making best guesses. And we're going to be wrong from time to time.

    It's no secret that last year, the WordPress security world found a new villain in the despicable people who buy plugins and slip backdoors into them. I saw some complaints that this sort of vulnerability wouldn't exist in [insert your CMS here], except … it will. It can and it will.

    We are all vulnerable because we choose to trust. We trust the developer to have good intentions. We trust the reviewers to be good people and care more about the security and sanity of code than themselves (which is a whole different ball of fish). We trust the ongoing development not to be handed over to evil people.

    That last one is unavoidable. People trust me to review code and react in the 'best' way for the community. But what if someone found my asking price and bribed me? What if I let bad code like backdoors into the WordPress Plugin directory? It would probably get caught, eventually, but still. Even if we locked down plugins to specific users accounts and didn't let anyone but admins (like me and Otto) add users, we would still at the end of the day remain vulnerable to humanity.

    Security Is Ongoing

    The truth is this.

    We are always, every day, insecure and vulnerable.

    Having a website that is your 'life' or career or business or even just a passion-project is dangerous.

    You should treat your website with as much thought and security as you do your own home. Check the gas. Check the lights. Make sure the door is locked. Get a security system. Hire someone to review the site and the server. But take it seriously. 

    Your website is 'you' on the Internet. And it deserves as much care as locking your car and not parking it in a shady part of time.

    Summary?

    Pay attention to what you put on your website.

    Trust no one. Not even me.