|
|
|
|
|
|
by nightpool
685 days ago
|
|
|
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. |
|
|
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.