Thousands of websites run buggy WordPress plugin that allows complete takeover Miscreants have reportedly scanned almost 1.6 million websites in attempts to exploit an arbitrary file upload vulnerability in a previously disclosed buggy WordPress plugin. Traced as CVE-2021-24284, the vuln targets Kaswara Modern WPBakery Page Builder Addons and, if exploited, it would allow criminals to upload malicious …
Thay's a very basic rule one for WP: the more plugins, the more you should look out for another platform for the website.
WP is OKish for a read-only website, but as soon as you allow interaction and stray away from the original idea behind WP (read: add plugins to make it do things it wasn't really meant for), the more you open the door for trouble.
Wordpress is *great*. All those bugs and problems I've fixed, the hacked sites I've repaired - serious earner.
Yes, unmaintained plugins are a great source of trouble but the core code is still seriously, uh, sub-optimal.
I was doing a site migration recently and found duplicate usernames. Because there is no unique constraint on the field, and it checks for duplicates programmatically, if you're getting hosed by some sort of bot you *will* hit a race condition and ping! duplicate usernames. I could scarce believe that such a widely-used and developed piece of software could still contain such a beginner's mistake.
I thought maybe this was a legacy issue - no, the default schema *still* does not have a unique constraint on usernames. Unique keys are used in *other* tables so there's no stupid excuse that they are trying to support a MySQL version released in 1963.
WP was never meant to be more than a self service blog for people who could not do HTML.
Then it went berserk. And it was never that good to begin with. It rode a wave of blogger mania (remember that ages ago?) and has a popularity it really doesn't deserve.
It's bloated trash with an administration interface that did too many drugs and now hears voices from a Monty Python skit.
This post has been deleted by its author
It would require people knowing HTML, CSS and JavaScript, and they would need also to manipulate the home page and others every time to create links. Moreover they would need a way to upload pages to the web server, that could become a danger itself.
Sure, there could be ways to have an off-line editor with the same functionalities, that could download CSS and themes from the site, let you edit your page locally WYSIWYG, and the upload through an API the result - in an era of web applications where everybody tries to move everything onto the web, where to manage your bulbs you have to connect to a remote site - tell me who is going to develop a multiplatform application to achieve it, even if build on ugly frameworks like Electron that require half a gigabyte just to exist. Maybe MS should resurrect FrontPage?
Anyway dangerous plugins may have nothing to do with online editors - everything depends on what they do and how they can be exploited.
"Static websites are built of HTML, CSS, and JavaScript."
https://www.w3schools.com/howto/howto_website_static.asp
"Static web pages can contain client-side technologies such as HTML, CSS, and JavaScript. They cannot contain dynamic content such as server-side scripts like PHP."
https://cloud.google.com/storage/docs/hosting-static-website
Even if a page is not generate dynamically it still needs to be HTML code - because that's what your browser expects - and if you don't want a 1998esque page, it also needs some CSS and probably a little JavaScript. Probably even more JavaScript since most functions need to be performed client-side.
Good luck, for example, in taking account the different screen sizes and orientations of today's devices.
So you still need or a web page editor a là FrontPage, or you need to code the page yourself in a text editor. And you'll need to manage also the whole structure of your site manually. Feasible maybe for small personal site made of a few pages, it soon becomes a mess for a larger site managed by many users.
What's the meaning you give to it today I don't really care... "static websites" have a specific meaning.
Most people can't waste their time translating "By unifying the elements of the modern decoupled web, from local development to advanced edge logic , Netlify enables a 10x faster path to much more performant, secure, and scalable websites and apps" into something that makes sense....
You too look to have not understand what Netlify is, after all. And it's still full of plugins... https://app.netlify.com/plugins
If the editing doesn't happen on the server, it's likely to happen on a different server unless the editor is implemented as a desktop application that syncs changes (or is being done by hand). If it's just another server, the attacker only has to find that one. Access control means a lot of web hosting systems or companies would probably go with the simplest option, even if it is easier to attack. Most WP plugins aren't really about editing; they're ways to implement behaviors that would ordinarily require writing code. Tons of them are for processing form input of some kind, sometimes including a page for users to check on the results. Those are going to need to run backend code on the webserver, and if storing anything, write access as well. You can implement that correctly, but with thousands of options, it's virtually guaranteed that there will be some who won't.
You would probably say, and I would entirely agree, that it's better to write that with a competent developer instead of finding someone's plugin to do the job. Unfortunately, there are too many people who have a website but not a developer or the means and/or interest to hire one, so that's not going to catch on as it should.
> unless the editor is implemented as a desktop application that syncs changes
https://www.google.com/search?q=static+website+generators&ie=UTF-8
Surely people commenting on an article about word press in an IT oriented site are familiar with the likes of Hugo, Jekyll, Hexo, etc, etc?
Or at least seen the "generated with X” text that many of the templates advertise?
> You would probably say, and I would entirely agree, that it's better to write that with a competent developer instead of finding someone's plugin to do the job.
There is nothing wrong with reusing someone else's code.
The issue is that the code has to be vetted somehow, which is something that only recently we've started doing, with a mixture of cooperative human and automated review.
We're faced with the same tribulations not just with website builders but also with library repositories (PIP, NPM, etc)
Because hiring a competent web developer is expensive, and most users just want "a simple website". Just some static text and a few forms that are more complex than they think they are. I am not a web developer, and I never will be one, but I still can't count the number of times someone has asked me to write a form for their website without thinking it through. For some reason, to the nontechnical mind, a form is as complex as its frontend. They often say things like "How hard can it be to have an order form: you just collect a list of items, an address, and a credit card number, and you can use PayPal for that last one".
They don't want to call a web developer every time they want to add some static page, and they don't really want to pay a team to develop a CMS for them. This leaves them with a set of existing CMS options, and they all end up having similar levels of difficulty and similar security problems. That is, the central systems will probably end up being generally acceptable, but they won't do much except for plain pages, so the users will start pulling in plugins to make the design more appealing and the pages needing active content function better. Now they have many chances for disaster.
My wife uses it but I've said from day one, minimum plugins, always use ones in active development and never, ever do anything that requires any collection of data especially payments. Always pass everything over to trusted third party then the owness is off you if the third-party screws up.
WP is just like any other webapp, it has a frontend and a backend, so therefore you need to treat it like you would any other webapp, smother it with proxies/firewalls/IDS, lockdown every entry point and lock it into a DMZ, never load it with anything you can't afford to lose. Problem is that it's pushed as a no-code, easy to stand up web platform and so every Tom, Dick and Henrietta thinks they're a webdeveloper 'cos they stood up a webapp but they have no clue about security, thinking locking up the admin account will do!
Security is not a "thing" it's a concept with many, many aspects and the sooner people get that into their thick skulls the better the internet will be. I won't hold my breath though.
It's the people that chuck on any random plug in, even if it has no development for years. When they do use current ones, they don't use the auto update features
Then they don't bother putting any security software in place, 2fa etc
And finally, they don't even attempt to lock down the admin area.
Code contains bugs !!!
Borrowed code contains borrowed bugs !!!
Auto-updating borrowed code, auto-updates your borrowed bugs (sometime fixes them / sometimes NOT) !!!
The t'internet runs on code !!!
The t'internet is therefore 'Buggy' !!!
Caveat Emptor in all things, trust nothing and set up multiple lines of defense that you test actually works (re-testing regularly !!!)
Web developers and end users typically don't know much about security. They add plugins without having any way to know how to compare long term maintenance with short term convenience.
As a systems administrator who hosts quite a number of Wordpress instances, I have to say it's a HUGE problem that plugins can't easily be disabled from the perspective of the server without taking the chance of breaking the whole site. This is rather stupid and makes any long-term Wordpress site on the Internet very problematic.
What really needs to happen is that sites need to be able to run even if a plugin is removed / disabled / deleted, and systems administrators need to be able to do this when bad plugins are being exploited. This is because we can't expect web developers and end users to know to log in and disable them themselves.
Because this isn't the case, I've somewhat often had to disable (chmod 0) plugin files that cause a site to stop working, then let the client figure it out. Emailing them to tell them to fix it ASAP doesn't work (although I do this all the time, anyway), because security is an abstract thing they don't understand until it's already too late. So I email them, then break their web sites, then let them scramble to fix it.
It's really, really stupid, and in my mind it's yet another example of how Wordpress wants to coerce everyone to move to wordpress.com because almost all other installations will either break or become insecure if unmaintained.
It's almost as though, err, a simple standard and wysiwig editor are what mere mortals want and the IT world does not want to deliver, because profit from complexity.
The last web page I made (quite some time ago) was a mandatory module on ASP. The spawn of satan does not do the ASP world justice. Three scripting languages with different syntax required "within" not only the same blocks of code but the same lines!
Modern stuff hidden behind endless scripts, css, HTML5 etc is to be blunt, more of the same.
Maybe we need yet another standard... :-P
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
