[Bug] Individual POST requests still need CSRF protection

[ayust]

The "automatic CSRF protection" provided by F3 is only automatic against a particular type of forgery, namely hijacking an entire session. It doesn't prevent the more common form of CSRF which is just having the user submit a POST request from a form on another site to your site (which thus uses the valid cookie for your site already on their computer).

To prevent this type of CSRF, you need to at least include the csrf token as part of the POST data itself (in addition to having it in the session cookie) and then compare to make sure the csrf token in the POST data matches the csrf token in the cookie. (A malicious 3rd party site won't be able to read the csrf token out of your site's cookie, and thus will be unable to put it in the POST body.)

See https://fatfreeframework.com/session#csrf for details.

[exodus4d]

You are right, but this kind of attack still requires a valid (stolen) Cookie. Ill check and add an CSRF tokens in future.

But a "simple" POST will fail (even with a valid Cookie). All Ajax Routes are protected against non-ajax requests X-Requested-With: XMLHttpRequest Header check in routes.ini : F3 Doku.

And even if you fake this Header, you ran into the max-expire timeout after a while. This is because all Cookie data is stored on the server side as well. Reade more: https://github.com/exodus4d/pathfinder/issues/138#issuecomment-216036606

In addition to that, any "suspect" SESSION access (changed IP/ changed User-Agend) is logged: (Doku SESSION suspect)[https://fatfreeframework.com/session#Events]. Code: https://github.com/exodus4d/pathfinder/blob/master/app/main/controller/controller.php#L124 which destroys the SESSION. We could improve this behaviour and invalidate the Cookie as well by deleting the matching counterpart from character_authentification table (https://github.com/exodus4d/pathfinder/blob/master/app/main/model/characterauthenticationmodel.php). This would invalidate the stolen Cookie.

[ayust]

Typically CSRF attacks are submitted from the browser of the valid user, just by a malicious site. So the cookie isn't necessarily stolen, just used indirectly. (The malicious site can't actually see the cookie, but mutations from the POST can still take effect.)