[nightpool]

I'm not sure I really understand the weight this article gives to "nonces"—from an outside perspective, it seems like writing an titled "Exploiting authorization via cookie on Google.com" when you've found a simple XSS. In each case, the problem isn't the nonce itself, but rather the fact that developers are 1) allowing arbitrary file uploads with insecure sanitization, 2) embedding a secret value in frontend JSON blobs that any user can read, or 3) a completely unrelated SQL injection vulnerability.

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.

[nightpool]

After some thinking: I think a large part of the blame here also falls on the Wordpress documentation. It says that nonces should "never be used for authentication, authorization or access control", but it doesn't explain why. In actuality, nonces seem like they could be a very useful way to authenticate certain actions when a classic authentication session is not available (for example, when sending a user an email that allows them to take an action that they may view on another device or without an existing session, like a "password reset" form, or when authenticating a webhook callback). The fact that plugin developers aren't given enough info to reason through the security implications themselves makes these kind of mistakes more likely, and it also leads to this "cargo cult" security mindset you see in the article where any use of the nonce value magically makes your plugin less secure, regardless of the context. Instead of reasoning through what actually caused the 3 vulnerabilities found, the author just blames the problem on nonces.

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.

[progmetaldev]

While I do completely agree with you, you also seem to have a much more advanced knowledge of Wordpress than the average developer. I obviously can only speak from my own experience, but to me it seems that Wordpress' popularity mostly revolves around the discoverability of its API, and most developers only consult the documentation when completely stuck on an issue that trial and error doesn't solve.

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.

[nightpool]

I know next to nothing about WordPress and haven't used it since I was very little, these opinions just come from my general knowledge of web development, especially trained by my 5 years of Rails experience. Never underestimate the power of a good framework to illuminate the ways in which bad frameworks fail.

[progmetaldev]

Absolutely, most of my experience came from starting with MVC frameworks in PHP, Ruby, and .NET (of course after learning the language itself).