Project

General

Profile

Actions

Bug #77403

closed

CSRF protection not usable for anonymous users

Added by Christian Weiske over 7 years ago. Updated over 7 years ago.

Status:
Rejected
Priority:
Should have
Assignee:
-
Category:
Security
Target version:
-
Start date:
2016-08-04
Due date:
% Done:

0%

Estimated time:
TYPO3 Version:
7
PHP Version:
Tags:
Complexity:
Is Regression:
No
Sprint Focus:

Description

When a user is not logged in as frontend user, FormProtectionFactory::get() only returns a DisabledFormProtection, disabling all protection.

Bug #56633 where it was implemented does not say that it only should work for authenticated users.

FrontendFormProtection also fails if there is no user logged in.

So currently there is no official way to protect forms against CSRF attacks for non-logged in users.
A use case would be to prevent contact forms to be submitted without the user having a session, i.e. automated submissions by bots (spamming).


Related issues 1 (0 open1 closed)

Related to TYPO3 Core - Bug #56633: Add Formprotection Class for FE usage (API for ext developers)ClosedHelmut Hummel2014-03-07

Actions
Actions #1

Updated by Wouter Wolters over 7 years ago

  • Assignee deleted (Helmut Hummel)

Please do not assign tickets directly to someone.

Actions #2

Updated by Helmut Hummel over 7 years ago

  • Status changed from New to Rejected

Let me cite OWASP for what a CSRF attack is:

Cross-Site Request Forgery (CSRF) is an attack that forces an end user to execute unwanted actions on a web application in which they're currently authenticated. CSRF attacks specifically target state-changing requests, not theft of data, since the attacker has no way to see the response to the forged request.

In other words, execute actions on behalf of a victim without the victims consent.
This means: no CSRF attack is possible without a victim being authenticated.

The described use case has nothing to do with CSRF, but goes more into what is described here: #75987

Last but not least, a token check where a token is stored in the session and compared against a submitted token, would be no mitigation for that very case. A spammer could simply aquire a valid token with one request (as it would be only bound to an anonymous session) and use that for unlimited subsequent requests to send forms.

Short: your use case needs a different solution and our CSRF protection framework does what it shall do.

Actions

Also available in: Atom PDF