Opened 13 years ago
Closed 12 years ago
#21111 closed enhancement (fixed)
Make nonce unique for users AND non-users
Reported by: | sc0ttkclark | Owned by: | nacin |
---|---|---|---|
Milestone: | 3.5 | Priority: | normal |
Severity: | normal | Version: | 3.4 |
Component: | Security | Keywords: | has-patch |
Focuses: | Cc: |
Description
Currently, wpnonce works from the nonce tick + action + current user ID. That means, nonce is only guaranteed unique for the current user and all other non-users can potentially share the same nonce.
As a solution to this problem, I'm requesting we add additional unique-ness for non-users. See below for my suggestion, it would go directly below the $uid variable set, within wp_create_nonce and wp_verify_nonce.
if ( empty( $uid ) ) $uid = uniqid( 'wpnonce_', true );
The use case for this addition, is for usage within a theme for public forms and other actions that do not require a logged in user.
Attachments (3)
Change History (13)
#3
@
13 years ago
I don't see how this would work. uniqid() uses the current time in milliseconds, which means that a nonce generated to be given to the user, and a nonce generated to be compared to the nonce provided by the user, will never match.
#4
@
13 years ago
- Keywords has-patch added
No way for me to modify the original description now, but attached a solution in the form of running a filter if $uid is empty. Please excuse my original solution example, I'm working on a low amount of sleep at the moment trying to get a project finished.
With the patch, plugin authors are free to interact with sessions/cookies to create unique IDs for non-users and continue using wp nonce functions instead of having to roll their own, which means they either have to use their own plus wp nonce functions for logged in users, or their own entirely. This solves that issue.
@
13 years ago
Here's another potential fix, which doesn't use a filter, and instead works off of REMOTE_ADDR + HTTP_USER_AGENT
#6
@
13 years ago
- Cc info@… added
$_SERVER[ 'REMOTE_ADDR' ]
can change on every request, it is not reliable. And the UA string can contain malicious code, it should be escaped.
#7
@
13 years ago
@toscho That extra patch was an idea, the current one on the table to be referenced should be 21111.2.diff at http://core.trac.wordpress.org/attachment/ticket/21111/21111.2.diff
Have you actually tested this? Wouldn't you end up with a different value when checking from the value initially generated?