Hacker News Reader

Comment by Tomte | Hacker News Reader

Since most people don't seem to be aware: you can use Wordpress as a mostly-static website generator.

Use WP Super Cache, and most of your pages are static anyway. A small PHP stub will be hit still, but if you don't even want that, you can just serve the generated static pages without it.

It's well documented, you just edit your httpd.conf/.htaccess or your nginx config to serve the static files generated by the plugins.

Only logged-in users (in most personal Wordpress installations: "just me") or recent commenters, depending on configuration, hit any PHP code at all.

Oh, and commenting works, unless with SSGs out of the box.

Keep the number of plugins small, use a static plugin and security is mostly a non-issue for a personal weblog (it's different for a "real" media operation with all kinds of complicated workflows, of course).

View on HN

> Since most people don't seem to be aware: you can use Wordpress as a mostly-static website generator.

> Use WP Super Cache, and most of your pages are static anyway.

This isn't "static" in the sense of a static site generator because your web server is still running code, reading/writing files, sending SQL queries, interpreting URL query parameters (e.g. for search results pages) and injecting data into templates when pages are being viewed. There is a much greater attack area and types of possible attacks.

For example, the caching plugin itself you mentioned has had remote code execution and XSS security holes in the last 6 months and others in the past:

https://patchstack.com/database/vulnerability/wp-super-cache

Many of these kinds of attacks aren't possible when your hosted website is only HTML, CSS, JavaScript with a CDN in front. Saying you think securing WordPress is practical is one thing, but there's a huge difference between dynamic and static.

> Many of these kinds of attacks aren't possible when your hosted website is only HTML, CSS, JavaScript

Had you read the other comments, where I have replied to this misconception several times already, you would have seen that the setup I describe is just that: "your hosted website is only HTML, CSS, JavaScript".

I'm replying to "Use WP Super Cache, and most of your pages are static anyway", which means PHP is running each request?

You need to read past the second sentence where I explain that WP Super Cache can be configured for fully static operation.

Or if three sentences are too much for you, you could read any of the other comments, all made hours before you jumped in with your inane "well-actually".

Can you link to anywhere that explains more? Pages are only generated when editors make edits and never from requests from visitors? How do you regenerate when you update the theme and what about tag, category and search pages?

At least when using nginx you don't even need WP Super Cache or any other Wordpress plugin. Instead you can utilize Nginx' FastCGI cache feature [1] which works for anything using FastCGI and not just Wordpress.

Here is an example for a tutorial on how to configure the FastCGI cache for Wordpress: https://easyengine.io/wordpress-nginx/tutorials/single-site/...

[1]: https://nginx.org/en/docs/http/ngx_http_fastcgi_module.html#...

You would have to configure that carefully so that for example you didn’t cache shopping baskets.

As shown in the linked guide you'd configure that based on something like an application specific cookie, which is probably required for the shopping basket in the first place anyway. I believe solutions like WP Super Cache handle that the same way, but I might be wrong about that.

Caching solves only the performance problem, which in my mind is the least compelling reason to go for static site.

If your wp-admin routes are still accessible to the public internet, then you are still at risk for broken plugins causing a hack. You have to both cache all static directories and firewall the actual server if you want to avoid being hacked by one of the thousands of scripts that scans every IP address for WordPress plugin vulnerabilities.

> Caching solves only the performance problem, which in my mind is the least compelling reason to go for static site.

One the other hand there are compelling reasons for not going with a static site as well.

Try getting non-technical users to write the markup for their posts by hand without a WYSIWYG editor. Or try to integrate features like comments with a static site without using a third-party service.

> If your wp-admin routes are still accessible to the public internet, then you are still at risk for broken plugins causing a hack. You have to both cache all static directories and firewall the actual server if you want to avoid being hacked by one of the thousands of scripts that scans every IP address for WordPress plugin vulnerabilities.

That's a risk you have with every internet facing software. Yes, static sites are great, because they greatly reduce the attack surface, but there are reasons why not every website is a statically generated site. As the comment which lead to that thread already mentioned it's quite easy to reduce the risk by keeping the number of plugins as small as possible.

I run several websites powered by Wordpress since more than 15 years and so far didn't have any security incident with them.

This is true. But none of my clients have ever stuck to it. The temptation is too great, within 6 months they always seem to justify installing 20 plugins grinding their performance and security to the ground.

I used to recommend WordPress, but I can't anymore, the plugin system (and bloated themes) is a mess.

That seems like a people problem and not a tech problem. You can simply not allow clients to install plugins and strip other such capabilities.

It sounds like you've yet to experience having clients. The decision-making authority generally flows quite differently from what you imagine here. The nature of the decision-making authority is what leads the parent commenter to conclude they can't set clients up with WordPress in the first place (because if they tried to tell the clients "no you can't do that" the client would do so anyway and/or switch to a new vendor do be able to do so).

Yep. This was my experience with WordPress as an employee. The marketing team was very loud about needing admin access to the WordPress instance, installed a file manager plugin, and that file manager plugin was shortly used to start serving malware from our domain.

Guess who got to clean it up? It wasn't the marketing team.

Yes, it's a people problem, not a technical problem. But I arrived at the same solution to the people problem as OP: don't set up a WordPress instance for someone who isn't capable of maintaining security themselves.

> It sounds like you've yet to experience having clients.

No, my experience has been the exact opposite. Our clients don't want to fiddle around themselves. They don't care whether their site/app is made with Wordpress or Laravel or Nodejs or w/e as long as it works well and is tailored to their needs. We also explain why this is more robust, flexible and efficient for all parties involved.

> because if they tried to tell the clients "no you can't do that" the client would do so anyway and/or switch to a new vendor do be able to do so

If they did that we've lost them and they lost us. It's just not how we work.

However it's the other way around, many clients we've had moved away from solutions that were too malleable and unstable/slow/hard to maintain etc.

Wordpress is one of the most insecure platforms out there. Avoid using it if you care about security.

This comment is a load of nonsense. Wordpress core has regular and comprehensive security reviews. Wordpress is the most deployed publishing platform globally. Like with any web application you should be deploying it behind a Web application firewall with a fit for purpose ruleset, and additionally with wordpress you can integrate one of several application firewalls into the application - several of which have decent full time security and development teams that actively discover, patch and mitigate zero days and new exploits.

Anything you add beyond that is on you, and you should be vetting your vendors or own code properly.

I have to wonder what your purpose for attack here is. Are you developing a competing product?

I don't know enough to comment about WordPress. But a secure applications don't need a WAF to be secure. WAFs in the steady-state are really just fuzzy bug injectors that hope to inject bugs over top of exploitable code.

The main use for WAFs that I consider valid is emergency response to recently discovered vulnerabilities while a patch is being discovered and applied.

The other use case is external rate limiting and DoS protection. But most often it is better to do that in the app anyways.

They do plenty more than that:

- Can section off certain requests

- Can rate limit

- Can catch basic injection attacks

With the wafs that integrate with WP such as wordfence they can also do things like:

- Check for bad file permissions

- Check for bad web server configuration

- Recieve ruleset updates for zero days that are actually threat surface specific

Having a WAF in place that is threat surface specific isn't as much about saying "its not needed if the code is good" as much as it is saying "the code might not always be good. We are not perfect. I'm at least going to have an extra layer or two of defence to try and stay safe(r) and give me some breathing room between an exploit and a patch".

It's just the oft touted "WordPress is insecure" meme.

Okay, I won't argue with you. You are clearly a Wordpress Architect.

Alright, who's the funny guy? https://i.ibb.co/Xpbm1hR/funny-guy.png

In my experience it's quite the opposite. It's not perfect, but it's safe enough for most users.

As long as you have WP updated, and a good configuration with your stack (PHP, MySQL, Nginx) it's hard to hack.

The main vulnerabilities come from 3rd party plugins and themes, and shared hosting with older versions of the stack. It's like faulting windows for vulnerabilities in an external .exe app.

If you use the default setup, and follow security guidelines, you should be ok.

It is windows' fault. Its their platform, architecture, their default configurations, sandbox, UX for security, etc

By this extension, you should be saying it is the Linux kernel’s fault all these sites were hacked.

90% of installations don't do this.

This comment is a lame hit job. WordPress is the most widely used publishing platform in the world and highly extensible, so there are always going to be third party plugins and themes which get compromised.

If security is a concern you can simply avoid third party plugins and themes, or limit your use of them to reputable vendors who have good track records.

The code of WordPress itself is pretty robust and the Core team has a great history of fixing vulnerabilities quickly.

I have had a different experience. I’ve been using WP since it was a wee bairn, and have written a number of plugins and themes, over the years.

It is not for every use case. I think some of the new static site generators are great, but WP fits the bill, when we need a fairly dynamic, configurable, maintainable, site.

The “security issues” are, IMNSHO, a reflection of the much wider “depenecapocalypse,” that is plaguing the entire software development industry, where lightly-trained, and inexperienced, devs, slap all kinds of executables into their projects, with hardly a glance at the bona fides of said executables, which, in my experience, can be … questionable.

I admit that I have created “Frankensites,” by using too many plugins (in fact, today, I am about to rewrite one, using as "bare bones" an architecture, as possible). Even good plugins can have a limited shelf life, and I have learned (the hard way) that paying for extensions and themes buys me almost nothing. I have been aghast, when examining the code, in some of these.

There’s a lot of crap WP code, out there, but I have been fairly impressed with the quality of the code and architecture of the core system.

The one thing that I think needs improvement, is the WordPress Codex. It’s a mess. I’m often better served, examining the code directly, than relying on that.

I don't do Web sites as a living. There's millions of better Web developers than me. I like to be able to walk away from a site, and let it stand on its own. WP has served me well, for that.

I personally love the WordPress Hook system. You really can manipulate everything with plugins.

> The one thing that I think needs improvement, is the WordPress Codex.

The original Codex can be considered obsolete as it has been replaced by developers.wordpress.org which is much more informative and up to date.

As I said: with this setup, all the readers (everyone but me) do not even hit any Wordpress code anymore. It truly is a static site generator. You can look at the generated HTML files in the file system. That's what the web server serves.

Did you remove all the code pages? Otherwise, an attacker is not restricted to following links on your site, they can access the code urls directly?

No, they can't. As I said, the nginx or Apache configuration makes sure.

Look it up, you're routing everything to static files in file system directories.

Only if you are requesting an URL (however "you" are identified) the webserver even contemplates serving something else.

It's an explicit rule for the special case. Everyone else doesn't see a PHP-FPM execution path at all.

If it generates something, it can still do whatever it wants with the generated files if the purpose is to, for example, embed spam links.

If the server is the target, it either still has access to it, or to some alternative computer which, for a private individual writing a blog, will be their much more valuable personal device.

Yes, you can spin up a VM, generate html, run it through all sorts of tests and only then upload it. The victims of this hack aren’t going to do that.

That's a threat model that is wildly imaginative.

Tell your web server to only serve the login stuff to you (certificates, HTTP Basic Auth, whatever). Problem solved.

And what is your solution?

A SSG also generates something and could embed bad stuff.

Something has to upload your SSG generated files and thus needs access to your web server. If you're running it on your personal device it could compromise it.

Really, stop trying so hard to invent Wordpress problems. If you don't like it, nobody forces you to use it.

If you can login or comment, you do hit Wordpress code right?

It could be fine if you put the admin portal behind a firewall but I would also recommend moving forward and stop developing new websites using Wordpress if you care about security. And you should probably care about security.

The issue here was plugins from compromised third-party repository. This has little to do with WordPress. It’s the mechanism Apple refers to as justification for the App Store monopoly which, I guesss, is hated on alternative days to supply chain hacks.

Your Favorite platform will be exactly the same if a bad guy has access and inserts it;s code or if you are dumb enough to install a random third party code from a random website.

My personal blog uses one of the default themes, I hosted extremely cheap, I NEVER touch it because it is autoupdated and it just works.

I did not review WordPress code so I can't tell how secure it is, but using this article to do a lazzy hit on WordPress is pathetic, this issue is as related with WordPress as you installing an .exe fom a random website is a Windows issue.

WordPress is insecure by design.

tl;dr: Use a static site generator.

The biggest reason is that its pages are not statically generated and allows for code execution when they contain no dynamic content.

The second biggest reason is the marketplace for plugins and themes; even if WordPress security audited their entire standard release, every single theme or plugin you install could compromise your installation. You’d think of a theme as something that provides colors and spacing, but they’re fully executable programs.

WordPress is conveniently written in PHP, which attracts inexperienced programmers with no understanding of web security.

The attack that OP links to is a supply-chain attack made possible by WordPress’es software architecture, but it could have happened on most more secure alternatives if they were equally popular.

So while it’s easy to ridicule WordPress for having no security and a poor architecture to withstand most attacks, we mustn’t forget that it’s a combination of its huge popularity and the ease of use caused by its simplistic choices that has lead to this breach.

If the critics spent as much time building and selling what they see as the “better option” to WordPress, perhaps we wouldn’t be in this place. As it is, they just do the easy thing, playing “pigeon chess” by making these hackneyed, unsupported assertions.

A better assessment is that WordPress has made trade-offs regarding security, as anybody in the real world must. Individuals must also make their own trade-offs, including whether to run WordPress at all, then how to configure it and which third-party code to use. Sometimes we get the trade-offs wrong, and that should affect how people make future decisions.

> WordPress is insecure by design.

Is there a proof for that?

>tl;dr: Use a static site generator.

Most People that use WordPress are not develoeprs or technical people. Find similar product with a WYSIWYG GUI , theme , plugins, cheap hosting, no bullshit licensing or breaking backwards compatibility and promote it to people or whoever hosts this blogs.

I think you are suggesting someone to replace his IDE with notepad since you can build application with notepad and gcc directly.

PHP has a pretty good deployment story in FPM since 10+ years. Every worker can run in a read-only chroot, or with separate uids.

Wordpress has only one entrypoint and only needs to write to its data directory, so it's quite decent.

The big issue with wordpress is with the vast plugin system, where all bets may be off depending on what you run.

just don’t install tons of untrusted plugins and themes like you would also not do on any other platform you host.

even whitehouse.gov uses WordPress: https://wordpress.org/showcase/the-white-house/

https://www.searchenginejournal.com/wordpress-core-vulnerabi...

All my logs, if wordpress or not, get constantly hammered with random wordpress backdoor requests. Even if it were generally secure, the one day it's not can break everything.

Simply not true. WP core is very secure.

But this doesn't protect from faulty REST entrypoints, XML-rpc, wp-admin/* links, right ?

Or just use one of the hundreds of newer, more secure, CMS alternatives out there.

Have those newer platforms been audited to the same extent as WordPress? Even if the core of any new CMS is “more secure”, it’ll be faced with the exact same problems the moment it grows big enough that third-party developers begin to release add-ons.

There is no need for e.g. Hugo, Jekyll, ghost or many such setups to be audited. Because their model is inherently secure.

interesting info!

Reply on news.ycombinator.com