Closed (fixed)
Project:
Drupal core
Version:
x.y.z
Component:
forms system
Priority:
Critical
Category:
Bug report
Assigned:
Unassigned
Reporter:
Created:
21 Oct 2006 at 14:43 UTC
Updated:
14 Nov 2006 at 08:15 UTC
Jump to comment: Most recent file
Comments
Comment #1
heine commentedNote: I'd rather keep the rewriting of node revisions / menu disable to use $_POST and the rewriting of some old style (4.6) forms to other issues.
Comment #2
heine commentedModified to prevent XHTML validation errors (as in http://drupal.org/node/90635)
Comment #3
eaton commentedJust ran this through its paces on a fresh install. Some forms, like poll.module's voting, aren't fully FAPI-ified and thus are unaffected by this security check. Others, like commenting and node creation, properly throw a validation error when submitting a form with a tainted or missing token.
Comment #4
drummThis is a big patch, any other reviews? Anything different from the 4.7 version?
Comment #5
Jo Wouters commentedI'm not sure if this is a security issue, but it is relatively easy to get to know the 'drupal_private_key':
The token (which is publicly shown in every form) is calculated with this function:
The session_id is know to the user, $value is the forum_id.
$private_key is the only unknown part.
And since $private_key = mt_rand() (a number between 0 and 2147483647 on my machine) it is relatively easy to get to know the drupal_private_key.
(it costed me less then 40 minutes to find 2 different drupal_private_keys)
Apart from that, this patch seems to be working on head.
Comment #6
Jo Wouters commentednote: that should be "$value is the form_id" of course.
We should put the issue about the 'drupal_private_key' in a seperate issue. I'll open one, and attach a patch.
Comment #7
heine commentedChanged into a 256 bits key.
Comment #8
heine commentedComment #9
Kjartan commentedBeen using this patch on my site for a few days now and haven't had any troubles yet.
Comment #10
drummCommitted to HEAD>
Comment #11
(not verified) commented