4 ms·

Exploiting authorization by nonce in WordPress plugins

73 points by nelse 2y ago

francis-io 2y ago
Unfortunate naming... https://dictionary.cambridge.org/dictionary/english/nonce https://dictionary.cambridge.org/dictionary/english/nonce
- JohnKemeny 2y ago
  Yes, but this is quite old usage. A cryptographic nonce is a "number used once". A nonce is essential in proof-of-work. See, e.g., https://csrc.nist.gov/glossary/term/nonce https://csrc.nist.gov/glossary/term/nonce
- kevindamm 2y ago
  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.
  - zarzavat 2y ago
    “Slut” originally means an untidy woman but if you call someone that, a knowledge of etymology is not going to help. Language doesn’t work based on precedent.
    - kevindamm 2y ago
      I'm not talking about precedent -- the comment was that it was a poor choice of term, implying that the term in the article came about later.. when the uniqueness sense of the word has been in use since long before that. Though the slang word looks like it originated in '71 and the cybersecurity use of it only goes back to '78, so perhaps it was a poor choice indeed. Though, with its similarity to the use by dictionary editors and cartographers, it makes sense why they would pick that term. I only today became aware of the pedophilia reference for it and will have a difficult time unthinking thoughts of revulsion whenever I encounter the security-related term, but what can you do.
      - multjoy 2y ago
        Imagine the delight we had over the fantastically named Nonce Finance.
  - phpnode 2y ago
    that's likely a backronym
    - kevindamm 2y ago
      I did a little more digging and it seems you're probably right about that.
  - rsynnott 2y ago
    > Your linked term comes from an acronym written on prison cell doors (Not On Normal Courtyard Exercise) 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).
    - kevindamm 2y ago
      Yeah I shouldn't have assumed that was right, even if it seemed more likely than "nonsense" and especially since I'm not very familiar with UK slang. It seems the exception is those terms with origins in military and academia.
- deleted 2y ago
  [deleted]
- mikrl 2y ago
  The preferred spelling of nonse is n-o-n-S-e although c-e is an acceptable ethnic variant. 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)
  - multjoy 2y ago
    It’s always been nonce. Source: have used it since the eighties.
jftuga 2y ago
[flagged]
- deleted 2y ago
  [deleted]
ecjhdnc2025 2y ago
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. 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_verify_nonce/ 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/product_id-4096/Wordpress-Wordpress.html?page=1&cvssscoremin=9&year=2024&order=1&trc=2&sha=bf68bee9cf43b1563f81a697645aea1c05646e0f 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.
- fullspectrumdev 2y ago
  > 280 9.0+ vulnerabilities in seventy thousand plugins, the long tail of which have maybe dozens of activations at most. 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!
bubblebeard 2y ago
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. Security in WP seems more like an afterthought to me, which is a shame to say the least.
- cloudking 2y ago
  Yep, I've found fail2ban wired to NGINX logs is a good solution against brute force and DDoS attacks on my WordPress sites.
- cqqxo4zV46cp 2y ago
  What we can say for sure is: 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.
- savolai 2y ago
  It can indeed be incredibly confusing for users if that is not disclosed, bordering on hostile. 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?
  - SketchySeaBeast 2y ago
    It makes it so much easier for attackers - they then can know that a user has an account there too, and can then use that information to find that user's other known passwords. It's offering up information the attacker might not have.
nightpool 2y ago
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 2y 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.
dawnerd 2y ago
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. Even popular plugins don’t do the bare minimum like escaping output.

73 points by nelse 2y ago

Unfortunate naming... https://dictionary.cambridge.org/dictionary/english/nonce https://dictionary.cambridge.org/dictionary/english/nonce

JohnKemeny 2y ago
Yes, but this is quite old usage. A cryptographic nonce is a "number used once". A nonce is essential in proof-of-work. See, e.g., https://csrc.nist.gov/glossary/term/nonce https://csrc.nist.gov/glossary/term/nonce
kevindamm 2y ago
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.
- zarzavat 2y ago
  “Slut” originally means an untidy woman but if you call someone that, a knowledge of etymology is not going to help. Language doesn’t work based on precedent.
  - kevindamm 2y ago
    I'm not talking about precedent -- the comment was that it was a poor choice of term, implying that the term in the article came about later.. when the uniqueness sense of the word has been in use since long before that. Though the slang word looks like it originated in '71 and the cybersecurity use of it only goes back to '78, so perhaps it was a poor choice indeed. Though, with its similarity to the use by dictionary editors and cartographers, it makes sense why they would pick that term. I only today became aware of the pedophilia reference for it and will have a difficult time unthinking thoughts of revulsion whenever I encounter the security-related term, but what can you do.
    - multjoy 2y ago
      Imagine the delight we had over the fantastically named Nonce Finance.
- phpnode 2y ago
  that's likely a backronym
  - kevindamm 2y ago
    I did a little more digging and it seems you're probably right about that.
- rsynnott 2y ago
  > Your linked term comes from an acronym written on prison cell doors (Not On Normal Courtyard Exercise) 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).
  - kevindamm 2y ago
    Yeah I shouldn't have assumed that was right, even if it seemed more likely than "nonsense" and especially since I'm not very familiar with UK slang. It seems the exception is those terms with origins in military and academia.
deleted 2y ago
[deleted]
mikrl 2y ago
The preferred spelling of nonse is n-o-n-S-e although c-e is an acceptable ethnic variant. 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)
- multjoy 2y ago
  It’s always been nonce. Source: have used it since the eighties.

jftuga 2y ago

[flagged]

deleted 2y ago
[deleted]

ecjhdnc2025 2y ago

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. 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_verify_nonce/ 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/product_id-4096/Wordpress-Wordpress.html?page=1&cvssscoremin=9&year=2024&order=1&trc=2&sha=bf68bee9cf43b1563f81a697645aea1c05646e0f 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.

fullspectrumdev 2y ago
> 280 9.0+ vulnerabilities in seventy thousand plugins, the long tail of which have maybe dozens of activations at most. 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!

bubblebeard 2y ago

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

cloudking 2y ago
Yep, I've found fail2ban wired to NGINX logs is a good solution against brute force and DDoS attacks on my WordPress sites.
cqqxo4zV46cp 2y ago
What we can say for sure is: 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.
savolai 2y ago
It can indeed be incredibly confusing for users if that is not disclosed, bordering on hostile. 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?
- SketchySeaBeast 2y ago
  It makes it so much easier for attackers - they then can know that a user has an account there too, and can then use that information to find that user's other known passwords. It's offering up information the attacker might not have.

nightpool 2y ago

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 2y 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.

dawnerd 2y ago

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. Even popular plugins don’t do the bare minimum like escaping output.