Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.If an attacker is able to get a user's session cookie, it's then easy perform a brute force attack on the user edit form to guess the password because there is no flood control. Given a known session cookie, this can be deployed to a botnet to perform brute force attacks and attempt to guess the user password.
This report was reviewed by the Drupal security team, and it was agreed it can be fixed in public: this vulnerability requires another vulnerability to exist in order to be exploited.
Credit: mohd haji.
Beta evaluation:
Beta phase evaluation
| Issue category | Task because this is a security improvement. |
|---|---|
| Issue priority | Major because it is two-step exploit. A prerequisite to use this attack is that your sessions are stolen, and if that is the case, the situation is already very bad. |
| Prioritized changes | The main goal of this issue is security. The issue is already known for Drupal 7 and requires a major exploit in order to be exploited itself, but would be considered a security improvement if implemented. |
Comments
Comment #1
larowlanShould this be higher than normal given security?
Comment #2
gregglesProbably.
Comment #3
dawehnerNot sure how, but it would be really great if you would be able to maybe use a trait or something else on any form,
which then adds flood control, or at least makes it as straightforward as possible.
Comment #4
greggles@dawehner that's a great idea! Something like #755584: Built-in support for csrf tokens in links and menu router
Comment #5
cilefen CreditAttribution: cilefen commentedThis is a triage at the Los Angeles Sprints. @phillamb168 and I did the triage.
The issue summary is up-to-date and is understandable by non-security specialists.
We reproduced the issue. In order to simulate a cookie theft, we injected the cookie with the browser console like this:
For example:
We compared what happens to the flood table when someone fails to log in (flood entries appear in the table) as compared to failing to enter the correct password on the user edit form (flood entries do not appear). There is no flood control on the change password form.
We found a related issue that is adding a flood control trait, #2431357: Extract a reusable UserAuthFlood service and reuse it in UserLoginForm and BasicAuth and UserAuthenticationController. We are postponing this issue on that and updating the other issue accordingly.
We spoke with two members of the security team and @alexpott and the consensus is that this is a Task, so we are changing the category to Task. Drupal 7 does not have this security improvement so we are adding the "Needs backport to D7 tag".
We think this is acceptable for the release candidate phase, but not vital.
Comment #6
xjm(Saving proposed issue credit for discussion and triage participants at LA.)
Comment #7
gregglesI don't think this should be postponed on the other issue since the other issue is for 7.x.
Comment #8
gregglesPardon, I got confused on which this issue is blocked.