Exploiting authorization by nonce in WordPress plugins
nowotarski.info
Exploiting authorization by nonce in WordPress plugins
1–10 of 45 posts
Re: Exploiting authorization by nonce in WordPress plugins
#2Re: Exploiting authorization by nonce in WordPress plugins
#3Re: Exploiting authorization by nonce in WordPress plugins
#4Unfortunate naming... https://dictionary.cambridge.org/dictionary/english/nonce
See, e.g., https://csrc.nist.gov/glossary/term/nonce
Re: Exploiting authorization by nonce in WordPress plugins
#5I 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.
Re: Exploiting authorization by nonce in WordPress plugins
#6Unfortunate naming... https://dictionary.cambridge.org/dictionary/english/nonce
Re: Exploiting authorization by nonce in WordPress plugins
#7Unfortunate naming... https://dictionary.cambridge.org/dictionary/english/nonce
That definition was made after the sense being used in this article (and this sense has been widely used in cybersecurity in general). Your linked term comes from an acronym written on prison cell doors (Not On Normal Courtyard Exercise) while the meaning of "used only once / unique" has an etymology dating back to Middle English.
Re: Exploiting authorization by nonce in WordPress plugins
#8Security in WP seems more like an afterthought to me, which is a shame to say the least.
Re: Exploiting authorization by nonce in WordPress plugins
#9Unfortunate naming... https://dictionary.cambridge.org/dictionary/english/nonce
That definition was made after the sense being used in this article (and this sense has been widely used in cybersecurity in general). Your linked term comes from an acronym written on prison cell doors (Not On Normal Courtyard Exercise) while the meaning of "used only once / unique" has an etymology dating back to Middle English.
Re: Exploiting authorization by nonce in WordPress plugins
#10This reminds me of an article in which brute forcing the WP admin panel was discussed. The problem was that when supplying inaccurate user credentials you would get an error message telling you which was wrong. Their dev stated this was a design choice, that you needed to balance security and user friendlyness. Security in WP seems more like an afterthought to me, which is a shame to say the least.
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.