Allow form tokens to be used on anonymous forms in some cases

An alternate solution would be to use the stateless csrf protection concept described here: http://appsandsecurity.blogspot.de/2012/01/stateless-csrf-protection.html

We might also consider a simpler approach with HTTP Origin or Referrer header checks as described on https://www.owasp.org/index.php/Cross-Site_Request_Forgery_%28CSRF%29_Pr... . That way we would have a stateless CSRF protection for anonymous users. Not sure about browser support for the Origin header.

The seckit module already does some Origin checks: http://cgit.drupalcode.org/seckit/tree/seckit.module#n327

So we could do something similar in the appropriate Form API places for anonymous users.

I'm still researching browser support. http://caniuse.com/cors seems to be only about CORS, which does not say anything about the Origin header alone.

I was experimenting a bit with Origin header checks today, but it seems that Firefox does not send it on POST requests https://stackoverflow.com/questions/29034776/why-does-firefox-not-always...

Referer information is increasingly not being sent either, so that's one less source of information (which was unreliable anyway).

A security scan from one of our customers has reported this as a major security issue:

Cross-Site Request Forgery (in https://example.com/user/login)

Description :
In the majority of today's web applications, clients are required to submit forms
which can perform sensitive operations.
An example of such a form being used would be when an administrator wishes to
create a new user for the application.

In the simplest version of the form, the administrator would fill-in:
* Name
* Password
* Role (level of access)

Continuing with this example, Cross Site Request Forgery (CSRF) would occur when
the administrator is tricked into clicking on a link, which if logged into the
application, would automatically submit the form without any further interaction.
Cyber-criminals will look for sites where sensitive functions are performed in
this manner and then craft malicious requests that will be used against clients
via a social engineering attack.

There are 3 things that are required for a CSRF attack to occur:
1. The form must perform some sort of sensitive action.
2. The victim (the administrator the example above) must have an active session.
3. Most importantly, all parameter values must be **known** or **guessable**.

Arachni discovered that all parameters within the form were known or predictable
and therefore the form could be vulnerable to CSRF.

_Manual verification may be required to check whether the submission will then
perform a sensitive action, such as reset a password, modify user profiles, post
content on a forum, etc._

Solution :
Based on the risk (determined by manual verification) of whether the form submission
performs a sensitive action, the addition of anti-CSRF tokens may be required.
These tokens can be configured in such a way that each session generates a new
anti-CSRF token or such that each individual request requires a new token.
It is important that the server track and maintain the status of each token (in
order to reject requests accompanied by invalid ones) and therefore prevent
cyber-criminals from knowing, guessing or reusing them.
_For examples of framework specific remediation options, please refer to the references._

Same for:
https://example.com/user/password and others.

Question:
Is this really such a vulnerability? And how we can solve this?
We have already installed https://www.drupal.org/project/seckit but maybe with the wrong settings?

@handkerchief Drupal already uses anti-CSRF tokens in forms for authenticated users (such as the administrator in the report text that you quoted).

This issue is about adding CSRF protection for anonymous users, who would typically not have access to forms such as the one to create / modify other user accounts.

For details of the built-in CSRF protection, see for example:

https://www.drupal.org/docs/7/security/writing-secure-code/create-forms-...

For Drupal 8 you can see some of the code which handles CSRF tokens in, for example:

https://api.drupal.org/api/drupal/core%21lib%21Drupal%21Core%21Form%21Fo...

thx @mcdruid for your response. I'll do that.

Some anonymous forms, like the login form, would benefit from CSRF hardening - https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forger...

Attached is a D7 proof-of-concept. It could use some documentation and tests, if it is potentially a good approach.

anonymous_forms_with_token allows configuring specific forms to get an anonymous token. When one is generated, $_SESSION is used to stash when it was generated.

Since form tokens work as long as the form cache is there, these sessions are cleaned up once that expiration has passed, in drupal_session_commit(). This allows anonymous sessions to be deleted if they are used to make requests, without generating form tokens, for some time. They are also cleaned up on login by drupal_session_regenerate().

Fixing the PHP notice.

My apologies if this is an incorrect way for using the comment feature. Since Detectify has declared the login-csrf vulnerability a medium level issue, I have to be able to fix this on my D7 site. Seckit didn't fix it, so I was trying this patch. Unfortunately it throws an undeclared _Session value in line 358 of session.inc
I'm at a loss as to what to try next. Any and all help is greatly appreciated. Thanks! kmkelmor

The existing patches are for Drupal 7.x. I am not sure which is the correct status between Active and Needs work.

I would use the latter, since the existing patch needs to be re-rolled for Drupal 8.x. Please change the status if it's not correct.

RE #1

Stateless CSRF technique is now supported by Symfony:
https://symfony.com/blog/new-in-symfony-7-2-stateless-csrf

https://github.com/symfony/symfony/commit/27d8a31d105ed53a043e4e21321279...

According to #29 I made a test project and integrated the Symfony security-csrf library. It has worked perfect on anonymous and logged in users.

Maybe we can make the csrf token generation in Drupal to be made with this component.

Here is the example service that I used:

<?php

declare(strict_types=1);

namespace Drupal\test_token;

use Drupal\Core\Site\Settings;
use Symfony\Component\HttpFoundation\RequestStack;
use Symfony\Component\Security\Csrf\CsrfToken;
use Symfony\Component\Security\Csrf\CsrfTokenManager;
use Symfony\Component\Security\Csrf\CsrfTokenManagerInterface;
use Symfony\Component\Security\Csrf\TokenStorage\SessionTokenStorage;

/**
 * TokenManipulator responsible for handling CSRF token operations.
 */
class TokenManipulator {

  /**
   * Token intent to use on token manipulation.
   *
   * @var string
   */
  protected string $tokenIntent;

  public function __construct(
    Settings $settings,
    protected RequestStack $requestStack,
  ) {
    $this->tokenIntent = $settings->get('default_token_intent', '');
  }

  /**
   * {@inheritdoc}
   */
  public function isTokenValid(string $token): bool {
    $manager = $this->getManager();
    return $manager->isTokenValid(new CsrfToken($this->tokenIntent, $token));
  }

  /**
   * {@inheritdoc}
   */
  public function generateToken(): string {
    $manager = $this->getManager();
    $token = $manager->getToken($this->tokenIntent);
    return $token->getValue();
  }

  /**
   * Retrieves the CSRF token manager.
   *
   * If a session is available, the manager will use session-backed storage;
   * otherwise, it will default to in-memory storage for the request lifecycle.
   *
   * @return \Symfony\Component\Security\Csrf\CsrfTokenManagerInterface
   *   The CSRF token manager instance.
   */
  protected function getManager(): CsrfTokenManagerInterface {
    $request = $this->requestStack->getCurrentRequest();
    $session = $request?->getSession();

    // Use session-backed storage if a session is available; otherwise the
    // manager will keep tokens in-memory for the request lifecycle.
    $storage = $session ? new SessionTokenStorage($this->requestStack) : NULL;

    return new CsrfTokenManager(NULL, $storage);
  }

}