Half-Elf on Tech

Thoughts From a Professional Lesbian

Author: Ipstenu (Mika Epstein)

  • How Hackers Find You

    How Hackers Find You

    I made a bold statement that pissed someone off. I told him that hackers don’t use Google to find vulnerable sites and attack them.

    They don’t, you know. Sure, they can do that, and I’m certain some of them run scripts to collect a list of people to hit up, but that’s incredibly inefficient. The only kinds of people who do that, who get lists of websites to touch, are people who for good reasons need to do that. Like maybe running a script to ping all your domains and trigger a WordPress automatic update by kicking off cron. And sure, a hacker could use a tool like WPScan to collect all the awesome information. But they don’t.

    But like I said, doing that is inefficient. The longer it takes a hacker to find you, attack you, and break you, the more likely it is that you’ll be upgraded. With WordPress in specific, the moment that hacker hits your site, your WP install has probably already begun the upgrade to make you more secure. Assuming that, what a hacker wants, what they need, is to hit you once, hit you right, and hit you hard.

    What a hacker really does is use that annoying BotNet to distribute an attack on as many websites as possible in one blast.

    Do All Hackers Do This?

    I should clarify something. When I say ‘hackers’ I don’t mean a specific person who is out to get you, in particular, and wants to destroy your site. Those attacks take as much tech smarts as they do social engineering. When I talk about hackers who are taking down sites, I mean the ones who know about a plugin or theme or core exploit to your site and are going to en masse blast the hell out of the internet to take ’em all down or leave their backdoors for whatever they do with these sites. Perhaps I should call them script kiddies, since many are.

    Why Do Hackers Do This?

    I have no idea.

    It used to be we hacked sites to prove we could. Then we hacked them to get in and get information we wanted. Then … somewhere along the line we started to hack to deface and leave viagra links. I don’t know what ‘good’ the hackers get out of the end result. It doesn’t make sense to me, but then again, I don’t understand why people buy most ‘as seen on TV’ things.

    How Do Hackers Find Your Site?

    One (kind of cool) thing they can do is, once they find one site, using a tool like SameIP to collect a list of everyone else on the server. That’s great for attacking people who are on shared hosts because they all have the same IP. And once they have your domain on their own list, they keep it and will hit you forever.

    But what if they just want a list of all 23% of the internet running WordPress? It’s not that hard. BuiltWith, for example, has a list of many of the WordPress sites.

    Certainly it’s not that hard to do. There used to be a site called Hacker Target that had a list of all WP sites: https://hackertarget.com/100k-top-wordpress-powered-sites/ The URL doesn’t work anymore but the idea is there. One could take such a list and just attack it.

    Similarly, if you happen to be on an insecure server, one could hack the server and from there collect a list of all domains (since the server has to know it’s domains) and, in the case of a very insecure server, get all the domains on the network, and attack all of those. The shell commands aren’t all that terrible.

    The point is, both of those methods are far, far, faster than just grabbing a google for ‘this plugin’ or even ‘this error.’

    How Do Hackers Find Out What You’re Running?

    This is where people step in and say “WordPress shouldn’t announce it’s version to the masses!” It should, because of what I say the next section (see “Do Hackers Care What You’re Running?”), but the short is that your site content tells them. They can run scrapers to pull your site data, the layout, the way files are stored, and they can tell. It’s like figuring out what car you’re driving.

    In fact… Think about that for a second. What kind of car are you driving? Does having the car logo on the car make it more or less secure? It may, if there’s a specific ‘hack’ for your car, but the trained professionals will still know, even if you pull off the logos, so in the end, you’re not really protecting yourself.

    Do Hackers Care What You’re Running?

    No, they don’t. Sorry. They don’t. Once a hacker has a list of websites, they don’t care if you run WordPress or Drupal or Joomla or Ghost. They’re going to attack with what they know is vulnerable and keep at it until they have a success. Then they take that success and leverage it to get to the next site. And on and on.

    So when you get hit by 100 bot-net computers, being tagged for timthumb when you don’t even have it installed, that’s what’s going on. They do not care what you’re running.

    How can you protect yourself?

    Use a good host who cares about security. Use up to date versions of all web tools and their extensions. Follow those tools and get updates regularly as to any security issues with them.

    WordPress is not “Set it an forget it.” You have to keep paying attention.

  • Design for Multisite or DIE

    Design for Multisite or DIE

    I don’t mean you need to design all your code to have special Multisite features. I mean that if you’re not writing code to work on multisite, you’re probably doing a lot of things non-optimally and not fully WordPressy. When you write your code with Multisite in mind, you’re actually writing it with the basic tenants of WordPress itself. It forces you to think about how WordPress is used, how it might be used, and how you can be flexible and extendable.

    Let’s throw out the idea of network options and activation for a moment and consider the ways we can write our code to make it work for Multisite and the world. The truth is that if you’re coding ‘for Multisite’ in many ways your coding for WordPress in the best way possible.

    Calling Files

    There’s a time and a place for ABSPATH but it’s as a last resort. There’s a time and a place for get_bloginfo('url') but it’s not to call .'/wp-admin/admin.php either. Did you know admin_url() will get the url to the admin area using the right protocol (http or https) for you? And it works for Multisite. Instead of hardcoding your paths or assuming everyone has WordPress installed in the root of their website (they don’t), use the functions and template calls WordPress has created.

    Oh and stop supporting the old WordPress 2.x ways of determining folders. It’s 2015. We’re good.

    Saving Files

    Saving data to the disk means everyone can read it. Duh, right? Well, where do you save uploaded files? You use wp_upload_dir of course. That works on Multisite just fine. Instead, if you hardcode in /wp-content/uploads/myplugin/ then you’re saving things for everyone. If you’re not using the WordPress options to grab the upload directory, then your code won’t work on Multisite and everyone will be sad.

    This extends to where you save your cache files. Did you know there’s a plugin that saves the cache to the plugin folder itself? Besides the fact that the cache didn’t have a way to flush and grew to 700megs over the year the person used it, that cache was for all the sites in the network. All. Saving the cache to a unique location (I suggest /wp-content/pluginname-cache/siteID) prevents cross contamination of cache.

    Saving Options

    If you write a plugin that, to save its data, it creates a new DB table and saves it there, that can be okay. But if your plugin on update then drops that table and recreates it… That was not pulled at random, by the way, I was reviewing a plugin that did that. Instead he should have been using the function update_option() to create (and update) the options. And yes, it knows.

    But that’s an extreme, I admit. What isn’t an extreme is people creating their own tables. It happens a lot. And when they do, they often forget that we have $wpdb->prefix which means they force create wp_mypluginname instead of $wpdb->prefix . "mypluginname" … guess which one’s smart enough to know it’s on Multisite?

    (If you want to make a network table use $wpdb->base_prefix and use update site option for network wide options, yes, we know the naming conventions are weird.)

    Theme Customizer

    Not everyone can edit theme files. Not everyone can make child themes. On a Multisite, the only person who can do that is the Super Admin. Site Admins have no access to edit files or upload themes. Worse, if you make a change to a theme, everyone who uses that theme gets the change. What happens when a site wants a special header and your theme doesn’t allow those to be edited via the customizer? The customizer is there for a reason. Use it. At the very least make things hookable to allow plugins to do simple things like change footers. Please. Please. That’s one of the things that themes get wrong constantly.

    What Else?

    What do you think would be improved if people ‘coded for Multisite’?

  • Mailbag: Network Shared Media

    Mailbag: Network Shared Media

    Doug asks:

    On the WP Forums (at https://wordpress.org/support/topic/multisite-with-one-media-library) you posted this comment:

    Ipstenu (Mika Epstein) Half-Elf Support Rogue, Volunteer Forum Mod & Plugin Referee Posted 1 year ago # http://wordpress.org/plugins/network-shared-media/ Keep in mind, this is generally something that kills your site’s performance.

    Unfortunately, the thread is closed so I can’t ask you to elaborate through the forum. So can you elaborate via email reply on exactly where or how the “performance is killed” as a result of installing & activating the `Network Shared Media` plug-in? Thank you, -Doug

    The problem is that WordPress Multisite was built to be multiple separate sites. You used one install of WordPress, one install of all your themes and plugins, and one ‘user base,’ but outside of that, the sites are all separate. Which plugin is active is different, which theme is used is different, and most importantly your data is segregated.

    Your data includes your media.

    The concept of ‘sharing media’ is a great one. If you have a network, you would want to have a way to share all common media in a way that every site can call it and insert it. But the way most plugins (including the one mentioned above) go about it is by doing sql queries:

    $blogs = $wpdb->get_results( $wpdb->prepare("SELECT blog_id, domain, path FROM $wpdb->blogs WHERE site_id = %d AND public = '1' AND archived = '0' AND spam = '0' AND deleted = '0' ORDER BY registered DESC", $wpdb->siteid), ARRAY_A );

    The code, in and of itself, isn’t bad, but that’s just to get a list of sites on the network. Then you have to check if each user has access to upload files to the site. Then you have to use switch_to_blog to go to each site and load the images.

    What happens if you have a lot of sites and a lot of images?

    Your site is slow.

    We’ve made a lot of improvements on that end, but extensive DB queries when you have to cross paths like that can be ‘expensive’ on a computational level. Not to mention those large DB queries can cause headaches if you use database caching. All that data has to be generated and cached on every load. That too will slow your server down.

    Now this won’t always make your site slow, but if you use it and you end up with a slow site, I’m not surprised.

    The next logical question, of course, is do I have suggestions or alternatives? I don’t. I actually do suggest people use that plugin if they need shared media. Or I suggest they don’t use Multisite.

  • Multiple Languages, Multiple Approaches

    Multiple Languages, Multiple Approaches

    I was contemplating WordPress and how it handles multiple languages recently. There are really two main aspects of multilingual sites. There’s multiple languages for the reader (the visitor) and there’s multiple languages for the admin. The two may not be in sync.

    For the Admin

    This has always been a little tricky. Assuming all projects have the same number of available language packs, you get two primary methods of translating the admin section.

    First is the site is set for a language. That means the owner of the website decides “This site will be English, have a nice day.”

    The other option is to have the setting be per user, so a user goes to their settings page and says “I speak French.” Obviously the main site setting (see above) will be where they start from, and this can be a little weird to find on some apps.

    The per-user setting is the most common, though it gets rather complex when you consider things like a WordPress multisite network. What if I want to make a site for the French and edit it in English? In MediaWiki too, this is an issue. I can only edit French WikiPedia in French. Initially. I can go in and change it per site, but there’s no global ‘default my account to English.’ Which is right? In the case of WikiPedia, it would be sensible to default me to the language on the site where I first make my account. If I sign up via fr.wikipedia.org, I should default to French.

    For the Front End

    If you only need one language, this is pretty easy. Pick the language for the site, write in it, and you’re done. For most Americans, this is ‘standard.’ But what happens when you need multiple languages on the front end? For the most part, things have to be either intended from the start or something you add in later. And both have drawbacks.

    WikiPedia, for example, has two methods. First they have a site for each language that cross links back to other languages:

    WikiPedia keeps links to other languages on the sidebar

    They do this via Interlanguage Links, but also via an extension called Translate which allows groups of people to translate.

    ZenPhoto uses serialized data. When you edit your content, you can add in the descriptions for it in each language. This has pros and cons. Weird things happen if the CMS ever forgets what language you’re using (an issue I actually did have for a while).

    When we look at WordPress, it tends to use plugins. Currently I’ve been recommending Bogo for translations. The other options are to make a Multisite and have each language be a site, but without the Interlanguage Links features of MediaWiki, cross-linking people back and forth based on language can be complicated.

    Another options?

    I’m not as versed in translations as I should be. Are you? I’d love to hear how you (and your projects) handle multiple languages for both admins and visitors.

  • Software Death Isn’t New

    Software Death Isn’t New

    The answer, Jeff, is yes. But they’re weird and hard to find.

    Back around 2008 or so, my father published a paper on the death of Lisa Norris.

    Don’t know who she is? Don’t worry. Most people don’t. Norris died of radiation overexposure that was determined to be caused by a software issue. People hadn’t fully tested software changes. I only know who she is because I maintain my father’s website and converted all his PDF articles to posts. In doing so, I read them all.

    I’m not a mathematician like my father, and luckily he and I share a fantastic trait. We’re both used to explaining technical things to non-technical people. Or rather, we can explain the technical things to people who are cleverly technical in other arenas. Yes, that’s where I learned it.

    When I saw Jeff’s tweet, I asked if he was serious (as opposed to just ruminating on Twitter) and then directed him to two of my father’s articles. First I pulled up the one about Lisa Norris, since that stuck in my memory. But then I remembered he’d written an article for the Nikkei Asian Review that was more non-mathematician readable. Knowing that he’s written the first paper gives a little more credence to the statements he makes when he talks about Death by Software.

    The part that has always stuck in my mind is this quote:

    As Dr. Nancy Leveson wrote in her Therac-25 investigation report: “Most accidents are system accidents; that is, they stem from complex interactions between various components and activities. To attribute a single cause to an accident is usually a serious mistake. We want to emphasize the complex nature of accidents and the need to investigate all aspects of system development and operation to understand what has happened and to prevent future accidents.”

    When we talk about how software can (and will continue to) kill people, we get stymied by the considerably complexity of the question. Did Lisa Norris die because no human thought “This looks weird?” That is also why it’s hard to say “Give me the statistics on all people who died because of software failure.” We have to define what, specifically, is a software failure.

    In the book (and the movies) “Fail-Safe,” we face nuclear war because a light burns out causing a false-positive alert resulting in American bombers heading to the USSR. It’s very similar to the boom “Red Alert” (and of course the movie “Dr. Stranglove”). The failure is that our fail-safe measures, the steps we take to make sure that a machine (or computer) cannot make the situation worse is nothing more than a pipe dream.

    At its crux, the deaths by software are often the result of failure of imagination. I first learned of the phrase when reading about the Apollo 1 fire back in 1967. Astronaut Frank Borman spoke at the post-mortem hearings of how the deaths, the fire was born from our failure to imagine how things could go wrong.

    Why don’t we have statistics? We would have to be very specific in what we ask for. How many people have died because their GPS was wrong? How many people died because the software to handle Anti-Lock Brakes failed? We do not lump all software failures together, making the research mystifying and bewildering. This is not meant as an excuse, though even to me it feels like one. We should be more transparent in how our software kills.

    And rest assured. Software kills.

  • Coding My Own Dogfood

    Coding My Own Dogfood

    I say no to a lot of pull requests on code.

    This is because I write plugins, not something massive and monolithic and used on a million websites. I’m a sole developer for my code, for the most part, and while pull requests are always welcome, the main reason I reject them is because I eat my own dogfood.

    Back in March of 2015, I decided to start using CloudFlare because we, at DreamHost, parter with them, so I should, you know, use them. It’s the same reason I use PageSpeed so much. And WordPress. I use what I use because I need to use it to be good at it.

    You cannot possibly be expected to write code for WordPress and support it if you don’t use it.

    I say this over and over again when I’m training people on WordPress. If you want to get good at supporting and fixing WordPress, then you need to use it and fix it. A lot. Every day. You need to use it so you know where everything is and can recognize what it should and should not do. You need to fix it so you know how to make it go back to looking like it should.

    If you’re writing code for WordPress, you need to do that too.

    Here’s my bottom line. If I’m writing a plugin, it’s going to be because I need what it does. If I’m writing a plugin, it’s because I’m going to use it. If there’s a feature I disagree with, I won’t add it in. If it’s something I will never use, it’s not going in. If it’s code I cannot test, I will never, ever, add it.

    That last one gets people mad at me a lot.

    The reality is that if I add in a feature for you and it doesn’t work, I can’t fix it because I don’t have the access needed. I cannot reproduce the error. If I can’t do that, how can I possibly fix it? I’ll have to work with you, via posts and emails, if you can’t fix it yourself.

    Pull requests are a wonderful thing, but if you’re making a pull for a new feature that’s something I can’t validate and test, then you’re also taking on the responsibility I did for the community. You’re promising to help me test it, develop it, future proof it. You’re promising to be there when I want to release a new version for everyone else. You’re promising to help support it and help others debug it.

    Are you ready for that?