Exploiting authorization by nonce in WordPress plugins

I&#x27;m not sure I really understand the weight this article gives to &quot;nonces&quot;—from an outside perspective, it seems like writing an titled &quot;Exploiting authorization via cookie on Google.com&quot; when you&#x27;ve found a simple XSS. In each case, the problem isn&#x27;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.<p>For #3 especially, it&#x27;s pretty confusing to single out nonces as especially vulnerable. <i>Any</i> 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 &quot;Wordpress logged in sessions should never be used for authentication&quot;? Or that wordpress auth sessions are &quot;often misused by developers&quot;? Similarly with #2, you make a haphazard effort to tie the improperly sanitized uploaded files back to nonces by saying &quot;a nonce is required to acces the uploaded file&quot;, but that really doesn&#x27;t have anything to do with the vulnerability itself—many users on wordpress installs are required &#x2F; 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.

The problem isn’t with Wordpress, it’s with it being so accessible that the lowest bar dev shops spit out code as quick and cheaply as possible. Best way to avoid security issues is to not use third party plugins or themes without auditing them.<p>Even popular plugins don’t do the bare minimum like escaping output.

This 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.<p>Security in WP seems more like an afterthought to me, which is a shame to say the least.

Unfortunate naming...<p><a href="https:&#x2F;&#x2F;dictionary.cambridge.org&#x2F;dictionary&#x2F;english&#x2F;nonce" rel="nofollow">https:&#x2F;&#x2F;dictionary.cambridge.org&#x2F;dictionary&#x2F;english&#x2F;nonce</a>

There is imprecision and conceptual forcing and there are sketchy constructs in this post that are annoying given its subject area. It is also shoehorning in other known vulnerability issues to pad out the article, when it is a pretty concise topic.<p>I am not sure how widespread this specific nonce problem is.<p>It definitely <i>is</i> a problem -- I am not disputing that.<p>(Just as it&#x27;s a problem that people have tended to assume that is_admin() or admin-ajax implies that by the time your hook runs, there&#x27;s already a valid administrator session, when there isn&#x27;t. But this is covered in the documentation.)<p>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:<p><a href="https:&#x2F;&#x2F;developer.wordpress.org&#x2F;reference&#x2F;functions&#x2F;wp_verify_nonce&#x2F;" rel="nofollow">https:&#x2F;&#x2F;developer.wordpress.org&#x2F;reference&#x2F;functions&#x2F;wp_verif...</a><p><i>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.</i><p>--<p>As to the rest of the article, I wish it were written less lazily:<p>&gt; Unfortunately, as history shows, most WordPress plugins, even popular ones, often contain security vulnerabilities.<p><i>Most</i> of them <i>often</i> do?<p>Not so. Definitely <i>some</i> <i>often</i> do, and there are repeat offenders, and many <i>have</i>, but by volume most WordPress plugins are small and do pretty simple things.<p>&gt; So far this year, 280 critical (CVSS score 9.0+) vulnerabilities have been found in WordPress and its plugins.<p>This is disingenuously phrased, to my mind: &quot;WordPress and its plugins&quot; suggests a single authorship and conflates WP with the plugins.<p>WordPress itself has had <i>no</i> 9+ vulnerabilities this year (or indeed since 2021).<p><a href="https:&#x2F;&#x2F;www.cvedetails.com&#x2F;vulnerability-list&#x2F;vendor_id-2337&#x2F;product_id-4096&#x2F;Wordpress-Wordpress.html?page=1&amp;cvssscoremin=9&amp;year=2024&amp;order=1&amp;trc=2&amp;sha=bf68bee9cf43b1563f81a697645aea1c05646e0f" rel="nofollow">https:&#x2F;&#x2F;www.cvedetails.com&#x2F;vulnerability-list&#x2F;vendor_id-2337...</a><p>(Not to mention that the post is talking about 280 9.0+ vulnerabilities in <i>seventy thousand</i> plugins, the long tail of which have maybe dozens of activations at most.)<p>&gt; There are dozens of SQL queries in every WP plugin.<p>Overreach again. Sure, many (perhaps the majority) of plugins <i>cause</i> additional SQL queries through the posts and options APIs, but most plugins contain little to no custom SQL.