For #3 especially, it's pretty confusing to single out nonces as especially vulnerable. Any secret defined in wp_config would have been similarly exposed by this exploitation method. For example, the SECURE_AUTH_KEY or the LOGIN_KEY. If you had found an installation that put those values in the database (probably common for multiuser installs), would you have instead written an article that claimed "Wordpress logged in sessions should never be used for authentication"? Or that wordpress auth sessions are "often misused by developers"? Similarly with #2, you make a haphazard effort to tie the improperly sanitized uploaded files back to nonces by saying "a nonce is required to acces the uploaded file", but that really doesn't have anything to do with the vulnerability itself—many users on wordpress installs are required / expected to upload publicly visible files, or files visible to their own user. Or even files visible to the administrator! The method of authenticating access to the files has nothing to do with the vulnerability itself, it was only a small piece of trivia required to properly exploit it in this specific plugin in some cases.
And another thing, if Wordpress developers really only want nonces to be used for CSRF prevention alone, why are they so complicated and so exposed to the developer? A more simpler and less "security by complexity" based approach would be to just e.g. use a cookie with a random value and a hidden field with a random value and expect them to match, like Rails does. If these nonces didn't have all of this "hash the user's ID and session token and the current action and add in a 12 hour lifetime" complexity, then developers would be much less tempted to use them for authentication. Additionally, why is the "verify" function exposed to developers at all, instead of being part of a higher level function like "register ajax route" or "register post route"? These are all weaknesses in architecture that make the misuse of nonce values for things beyond CSRF tokens more likely. It's not enough to just write a few lines of documentation and say "There we go, I've secured everything now!". You need to actually figure out what use-cases people are using these functions for and then figure out more secure-by-default ways to address those use-cases, otherwise you're not going to make any progress.
My experience with Wordpress is more around general PHP security, and reviewing compromised websites to determine whether a cleanup and patch is possible, rather than dumping it and starting over. I'm not sure if improving the documentation and making the API more secure (while also adding some complexity) would fix the vulnerabilities you suggest, or if it would turn less experienced developers away from using Wordpress in the first place. I'm a big fan of adding logging code to user defined functions, to make it easier to get a higher level view of what code is actually executing in a running website.
If you haven't considered it before, and aren't currently involved in it, reviewing Wordpress codebases for vulnerabilities can be pretty lucrative and challenging in an enjoyable way (assuming those you consult with take your advice). Regardless, you seem to be in the small number of vocal developers that might be able to bring about that type of change, for what it's worth.
Even popular plugins don’t do the bare minimum like escaping output.
Security in WP seems more like an afterthought to me, which is a shame to say the least.
It is a common pattern to reregister i.e. when in a hurry so you end up with multiple ids. If you also have userids in addition to email addresses, it can easily become a hard problem in itself to solve/remember which email/pw corresponds to which userid. Obfuscating user/password error messages can make this much worse.
Techies often forget what a messy world non-engineers live in.
Isn’t NOT disclosing that security by obscurity?
> The problem with returning a generic error message for the user is a User Experience (UX) matter. A legitimate user might feel confused with the generic messages, thus making it hard for them to use the application, and might after several retries, leave the application because of its complexity. The decision to return a generic error message can be determined based on the criticality of the application and its data. [1]
Though it's a pretty low bar. Given the common uses of Wordpress, there is certainly a very strong argument that it warrants the extra security.
I'm not defending its UX, I think it should have more generic errors. Just pointing out that this one particular example is not in and of itself the best banner to hold up when it comes to bad security as it is not a clear cut answer. A person could be very considerate of security and still come to the conclusion that the better UX is worth the risk.
[1] https://cheatsheetseries.owasp.org/cheatsheets/Authenticatio...
If you force good passwords it really shouldn’t matter too much if the usernames can be enumerated.
For a forgotten password where an email is entered, I always send back a success message. I understand that humans type their emails incorrectly, but allowing a user to enter an email address and seeing a message stating the email wasn't found has now just become a way for an attacker to discover what emails are registered with a website. From there, social engineering becomes much easier, as well as brute forcing ONLY a password and not an email/password combination.
I understand that the complexity in this is due to human frustration, rather than a technology problem. Probably one of the more complex problems to solve. I wish I could paste over these issues by writing more code.
1. By common standards, this is considered bad practice, especially in the context in which WordPress operates. User enumeration is widely considered to be an unacceptable consequence of error messages this specific, in most circumstances.
2. There are only very slightly more cumbersome ways to get the functionality desired by this choice (e.g., ‘forgot password’ email loop that’ll email you if you entered an email address for which no account exists).
Bluntly, WP is from a time where security was considered an afterthought, and done very poorly. Especially in PHP land.
They’re undoubtedly carrying a lot of that legacy code, and more importantly, a lot of that cultural baggage.
These are _always_ backronyms. _Always_. If anyone ever tells you that [random word that's been around for a while] is an acronym, they are _wrong_. (Possible notable exception for 'fubar'; that one's old enough now and probably really is an acronym).
Source: originally come from a time and place where you call your friends one for a laugh (and shout it at actual ones you know from cars)
See, e.g., https://csrc.nist.gov/glossary/term/nonce
I am not sure how widespread this specific nonce problem is.
It definitely is a problem -- I am not disputing that.
(Just as it's a problem that people have tended to assume that is_admin() or admin-ajax implies that by the time your hook runs, there's already a valid administrator session, when there isn't. But this is covered in the documentation.)
But the concept here is actually pretty obscure to WP developers so I would imagine they tend to consult the documentation, where they will encounter this at the end of the process:
https://developer.wordpress.org/reference/functions/wp_verif...
Nonces should never be relied on for authentication or authorization, access control. Protect your functions using current_user_can(), always assume Nonces can be compromised.
--
As to the rest of the article, I wish it were written less lazily:
> Unfortunately, as history shows, most WordPress plugins, even popular ones, often contain security vulnerabilities.
Most of them often do?
Not so. Definitely some often do, and there are repeat offenders, and many have, but by volume most WordPress plugins are small and do pretty simple things.
> So far this year, 280 critical (CVSS score 9.0+) vulnerabilities have been found in WordPress and its plugins.
This is disingenuously phrased, to my mind: "WordPress and its plugins" suggests a single authorship and conflates WP with the plugins.
WordPress itself has had no 9+ vulnerabilities this year (or indeed since 2021).
https://www.cvedetails.com/vulnerability-list/vendor_id-2337...
(Not to mention that the post is talking about 280 9.0+ vulnerabilities in seventy thousand plugins, the long tail of which have maybe dozens of activations at most.)
> There are dozens of SQL queries in every WP plugin.
Overreach again. Sure, many (perhaps the majority) of plugins cause additional SQL queries through the posts and options APIs, but most plugins contain little to no custom SQL.
This actually is a great point. A few years ago when working on a code analysis tool, we mirrored every single WP plugin and let it chew on them for a while.
It used a mixture of static and dynamic analysis, and “kinda worked” to some extent.
It found more issues than we could reasonably handle, and a lot of them were in plugins with maybe two installs ever and that hadn’t been activated in years.
We ran out of beans before implementing a proper triage system that would score the findings based on popularity or “last updated” data.
I may revisit this sometime though, as my ideas on static and dynamic analysis have come a long way since then!
