Hardening ClassicPress?

General Discussion Security News
21

This is a great idea, KMH. One of the issues which annoys me so much about Automattic WordPress is intentional neglect of core functionality. Basics like a form system, basic SEO (something like our FV Simpler SEO, nothing complex), caching, performance improvements, an SMTP plugin – all of that should be built-in. In a simple and robust way.

That way if a forms plugin wishes to further enhance the WordPress forms logic, the path is straightforward. Use the existing functionality and build on top.

ClassicPress needs a competitive advantage.

Something clear like a “more secure WordPress” would be a good start. “No plugins required. We’ve got your back,” would be a good second act.

What’s so very annoying about WordPress is how Gutenberg and the page builder mania has made WordPress so much clunkier and less productive a CMS. I’d love to try to explain to people that ClassicPress is a high productivity CMS, not just a page builder but that’s probably too much thinking for the current publisher crowd who are far too interested in fiddling with blocks and not nearly interested enough in building out content quickly and efficiently.

22

My opinion is those need to remain in plugin territory. Here is why:

CP can be installed in very different environments, each having their features - who knows how those can conflict with that?

My hosting for example offers SMPT by default, what happens if CP has a SMPT module conflicting with that? having it in core with a disable switch means people need to made aware of the risk of the thing breaking their site and need to be educated on when to enable it or not. This means that is something “more” that possibly is there to be left unused because they do not need it.

Same goes for security, optimization and maintenance features.

If they are there and are made redundant by they setting they are installed in they could also conflict with it.

About forms instead, your aim seems to be “having a simple one in core to set a standard to follow” - core is not there to force developer in one standard - there are coding practices and checks the devs have to undertake to deliver clean code but that pretty much what core can enforce.

Trying to set a forced standard for everyone kills variety and freedom both for users and devs. And BTW not every site needs a contact form.

CP is about delivering a very clean and stable core that devs can build upon. it’s made for the creators (both devs and users!) and its aim is continuing to offer the ability to build upon it. Security by default does not mean it offers you an all-in-one suite of tools already in core, there are plugin devs to solve that. it means that when developing for core sensible measures are applied to help make it more secure like password hashing, pepper for password, the early change to the user agent that I suggested to avoid privacy leaks years ago… I am here since 2018 when CP was born and I have seen many discussions on how to clean core and make it more secure to allow developers to build on something better than WP and I can totally tell you that this part of the mission IMHO has been honored.

23

By the way another amazing omission I just discovered is that Classicpress does not cache, and there are plugins which cost $8 per month to cache data on your own server. It baffles me that Classicpress (wordpress) apparently does not have basic caching built in.

1 Like
24

and it’s because some servers already offer caching. CP does not need to have it all in core. the user/dev needs to know what they are doing and decide which measures to undertake according to their own setup. core aims at making this simple and easy with features that do not stand in the way.

1 Like
25

@ElisabettaCarrara Thank you for taking the time to share some concrete counter-examples.

You gave the example of SMTP as something which should not be included in core (when you wrote STMP you probably meant SMTP).

SMTP configuration is not part of WordPress hosting. If it is, it would be extremely easy for the host to simply allow ClassicPress to do the heavy lifting. To recap what SMTP is, it’s just the configuration of WordPress to use the SMTP credentials which your host provides. The host still provides the SMTP even if ClassicPress includes configuration for SMTP. Almost all ISP still offer SMTP sending options even if many of them encourage users to use custom API credentials (which is a nuisance as it just makes sending email more complicated). I am not suggesting that ClassicPress try to maintain custom API configurations for all the major providers (Amazon SES, Sendgrid are two who encourage API sends for instance). But to reliably support SMTP directly in the CMS would be a huge win.

My hosting for example offers SMPT by default, what happens if CP has a SMPT module conflicting with that?

I’m bemused by the idea which dedicated WordPress hosts would be eager to include ClassicPress installs on their servers. Nothing could be worse, as ClassicPress is not identical to WordPress.

If ClassicPress remains identical to WordPress it cannot succeed and develop. WordPress does so many things wrong, the only path as an alternative would be to forge a better path. Yes to cross-compatibility for many plugins but frankly the whole advanced plugin ecosphere should burn to the ground at this point, as most of it is so toxic, badly coded, crippled and invasive at this point.

Capable developers could quickly take the required FOSS plugins and bring them up-to-date for ClassicPress in better versions without endless admin notices and without intentionally crippled features. I’m not against Pro plugins (we develop one) but am against restricting basic functionality. If a plugin is worth paying for it shouldn’t be solving the basic core problems almost every publisher faces.

26

My hosting is NOT a WP hosting, is a plesk server with some configs that I selected from the host and is basically a shared could hosting since for my needs this is enough. they have all the configurations up for me and emails send just right from my CP website WITHOUT a plugin or integration to make all that work (and they do not end in spam either). anything installed on my site should have its use and as I have that kind of server with that setup I would switch off such a feature if it was indeed in core.
CP is already DIFFERENT from WP (please go to GitHub and READ all the changelogs from 2018 to now to see how) and there is more to come.

Including stuff in core can totally happen if there is a real need, since I personally think what is discussed here is basically plugin territory I believe those should not be included but who knows… I am one and my opinion counts as one.
About porting plugins… Look at my Also in This Collection plugin for ClassicPress in the directory, it’s a port of Also in This Series WP plugin with some slight enhancement for CP - I am basically specializing in that. I also ported some themes but since I am not a perfect dev I am still working on some of my themes and plugins to make them basically better. I am not alone however and if you just look at the directory you might discover some gems.

1 Like
27

The best caching for most sites is not page caching but object caching. But which object caching solution depends on the host environment. And all of them are free.

2 Likes
28

WordPress’s greatest failure is building crippleware and turning the WordPress directory into a cross between a used-car lot and a snake oil convention. Most of the most egregious marketing nonsense could be solved by including core functionality in core.

To include reasonable caching (nothing ultra-advanced) would be a huge advantage, particularly when not using non-WordPress hosts. It would be very easy to include a disable caching checkbox in preferences. In most cases, internal WordPress caching does not interfere with the advanced caching a host might implement (Litespeed) or something else.

29

I’m not sure if we are talking about the same thing when I mentioned caching. Maybe I need to clarify myself a bit.

As a professional software developer, it is my task to not hit the database over and over for the same query. This is easily done with a short lived/session lifetime in-memory cache INSIDE the application code. This rhetoric goes for the whole request lifecycle, including browser. Don’t execute statements for which you already know what the outcome is going to be (inside the scope of the session/transaction/request).

Following this pattern, the production software I work on daily is generally fast enough for big peak loads, without additional Redis, Upscaling or CDN. Sure, we could add a cache on the load balancer or client, and it would be a good thing too, but is no excuse to not be careful with resources inside the application.

Doing the same thing with the same outcome over and over is simply bad practice. If I see this, the answer “yes but caching should be solved outside the application” is not acceptable in my dev team. Every component should put reasonable effort in being careful with “expensive” resources like disk, databases, network.

I like Classicpress over Wordpress in that respect because it is minimal, does not do extra actions, and generally follows the reasoning above: Don’t do useless things. On a single modern multi-core machine with gigabytes of RAM a modern application should be able to handle a thousand page visits per second without crutches. (I haven’t tested but I have good hopes for Classicpress in that respect :wink: ).

I’d to be able to tell you what one thousand visits per second look like on my classicpress installation but I guess my little personal blog is not popular enough for that :smiley:

1 Like
30

Now I’m confused. You said this before:

By the way another amazing omission I just discovered is that Classicpress does not cache, and there are plugins which cost $8 per month to cache data on your own server. It baffles me that Classicpress (wordpress) apparently does not have basic caching built in.

Which seemed to be about page caching. It’s certainly not referring to the type of caching you’re talking about now.

In fact, CP (and WP for that matter) already has the type of caching you’re now talking about. There might still be some functions that don’t have it that would benefit from it — I recall that get_users() had caching added just a couple of years ago — but it is the norm. If you can identify some other functions that would benefit from it, then we’ll be happy to take a look.

But an object cache will often do the job anyway, and it doesn’t need to be something as complex as Redis. I use this for most of my sites: GitHub - l3rady/object-cache-apcu. But, of course, it will work only if you have the APCu module installed.

If not, then I suggest this: SQLite Object Cache – WordPress plugin | WordPress.org But, again, it needs the SQLite3 extension.

For those using Litespeed, the Litespeed Cache plugin makes it simple to use Memcached. But again, it needs the Memcached extension to be available. It can also apparently be used to hook up to Redis, but I have never tried that.

1 Like
31

Aha :slight_smile: Good to have this conversation. I guess I am triggered by the answers which I read as “don’t do caching, we have external tools for that” and it started with the more worrying “don’t do security, it should be handled by the provider/machine/externally” (these are not literal quotes, it is how it sounds in my head).

Up to now, with the limited traffic my site has, Classicpress shows to use very little resources and is sufficiently fast to serve whole pages in under 200ms, while running inside a Docker on an old Mac Mini. It is open to the Internet, and the only additional thing I did is block internet access to wp-config, wp-admin, wp-login and disabled xmlrpc, just to be on the safe side. There is also a CrowdSec setup in front of it.

Maybe I am reading to much behind the posts. I think software security should not require any plugin, it should be inherintly safe. Not opening too much to the internet is common sense and practice, but it should not be assumed or relied upon by the software. I think Redis is something you only need if you get thousands of hits on your server and page load times go down, and you have an extra machine to just handle the caching for you. If the cache is on the same machine your Classicpress runs, it would be a reason to check out the performance of Classicpress code.

I’m very tempted to see how much load I can put on my little server to see when and where it breaks down now :slight_smile:

1 Like
32

If you’ve read all the comments in this thread, you’ll know that I was the one whom you are paraphrasing and that a webhost then responded:

There is a big difference between software as a service and downloadable software that can be uploaded to a wide variety of different environments. ClassicPress is offering the latter, for which the best security is indeed performed outside CP. There’s always going to be a limit to how “inherently safe” we can make it when we have little idea of the hosting environment in which it will be used.

But yes, ClassicPress is significantly faster than WordPress. Obviously, we never took on all the bloat that comes with Gutenberg and full-site editing. But we’ve also replaced a lot of old jQuery and obsolescent JavaScript libraries with modern HTML and vanilla JS.

1 Like
33

Hi Tim, yes, that was what I was paraphrasing. I must say that I think I mostly disagree with the way you phrase it (or the way I read it), which might be different from what you mean to say.

Classicpress is, and should behave as, a responsible part of a SaaS because it will be run that way in many cases.

“Good software” is memory and resource efficient (both internal and external), and can be assumed to be reasonably safe in terms of password storage (hashing passwords, clearing memory after use, etc) in my opinion. I have built Phone Apps, Backend software and embedded software for racers in my life, and am currently part of a team running a public transport SaaS for 3 countries. In all these situations this is true.

Yes, there are things which the software can’t handle internally, like load balancing, extra layers of security like Web Application Firewalls, full disk encryption etc. I would say that these are very helpful and I would very much advise everybody to use all those. The internet is a beautiful place, but also has some proper sleezeballs scanning your ports.

The thing is, when I read things like “There is a plugin for securing passwords” or a “plugin to add caching” it triggers me. Maybe it is simply external developers not understanding what Classicpress is doing under the hood, and are misinforming users, giving wrong impressions.

Having said that, I think that when I look at Classicpress, it is fast, efficient, more modern, and has a smaller attack surface because of the more modern way of doing things, so if the proof of the pudding is in the software, I think we are on the same page. Maybe it is just that I have had some experiences with inexperienced developers in my team thinking “but that’s not my problem” that make me react this way.

I apologise if I sounded offensive or frustrated, that was not my intention. Please keep up the good work, I’d love to see Classicpress stay and be used and maintained by enthusiastic people for years to come. If I ever pick up better PHP skills I might even help :wink:

34

I disagree with that statement sorry.

CP is a CMS that can be used as a SaaS but it’s not limited to this use only. This means that while a SaaS only product really needs what you are describing, a CMS that was born to build websites needs server side security/caching/backups enabled (and each server is different) and benefits also of measures taken at the site level in addition to the server ones.

If and when it is used as a SaaS there is to take into consideration how the server it runs on is set up and the features it needs - and in that case having something in core could hinder the ability of the dev to adapt it to its environment (because again, there are many ways that environment could be set up).

The percentage of websites made with WP according to stats is about 43% of all the web. Of this 43% about a 5% or 6% is built to be a SaaS model and this means that your statement is not entirely relevant. CP prioritizes the CMS use because the percentage of SaaS using CP is very low as of now considering also the numbers relevant to WP. Basically it’s a matter of how users are using it.

1 Like
35

I agree that any internet facing machine would need hardening you describe, but my point is that the application itself is not excused to not do that.

For example: CP has a login form. This login form is internet facing. Shouldn’t the security and performance it provides be the same, wether it is self-hosted, or a SaaS?

36

I think you are missing the point here. Generally speaking WP/CP were not intended to be used as SaaS - basically WP was born in 2003 from a blogging CMS because the Matt was not happy with it.
It has then evolved to be able to do SaaS, yes (and this means CP has more or less same ability) but they are not specialized pieces of software intended to build SaaS platforms specifically from their birth. You can’t ask something that was not intended to be a SaaS to behave as one following all the constraint a specific SaaS software has to abide to. The approach WP (and CP) take is modular design. That means a very lean core with plugins and themes to extend it. To handle what you are saying should be managed by core there are a lot of plugins already doing a wonderful job, and users can select what they really need among them. If a user has for example a local install with no access to the internet on their machine what use can they have for the security you are asking for? You do not know what people do with a CMS so the modular approach is the best because people are free to add to it whatever they really need.

1 Like
37

There are security features that can be shared across both types of site, yes. And they are. that’s what roles and capabilities are all about. So one user logging in is not necessarily the same as another user logging in. And we use the bcrypt hashing algorithm to secure the password.

But otherwise the situations are so unpredictable that there’s no way that one-size-fits-all will work. The most important thing to secure about about the login page is who can reach it. By definition, that is best accomplished from outside of ClassicPress. (A SaaS actually takes much the same approach, but the software is marketed as one entity.) I have already quoted a webhost who explained that it’s important that CP doesn’t conflict with what they do, so I’m not really sure why you’re trying to argue against that.

If you want more, or different protection, that’s what plugins are for. “Plugin” isn’t a bad word. In fact, as @ElisabettaCarrara pointed out, CP is intended to be modular, so that we don’t cause software bloat. Some people want to protect the form with a Cloudflare input box; others like Google Recaptcha; others like to password-protect the page, etc. Users can choose which they want by selecting the appropriate plugin.

Or not; I use none of these. I practise what I preach and rely on my host to weed out the vast majority of bad actors before they hit the login form. Instead, I use a plugin to enable me to have more granular roles than the defaults in CP, and require the use of 2FA for the admin and editor roles.

1 Like
38

I was more triggered and concerned about the standard parts and the programming ethos. The login form is not a plugin, so I expect that to be properly programmed, with for example use bcrypt and a salt.

So no, I think CP is not a “special kind of software”, in the sense that I expect it to be performant and safe and tested. “Modular” is different, that is more the discussion of what is and what is not part of the software.

All the stuff that is in vanilla CP when I install it (and I have), I expect to be performant and safe, as I would expect from professional code. So far, it seems to be.

1 Like
39

I have thought further about what @AlecK said about providing uncomplicated caching from within CP, and I think he’s probably right. So I have opened a PR at APCu object cache by KTS915 · Pull Request #2199 · ClassicPress/ClassicPress · GitHub . Please try it out and feel free to leave comments on the Github repo.

2 Likes