.

[GHANONTEST]

.

[GHANONTEST]

https://www.owasp.org/index.php/PHP_CSRF_Guard

[ssokolow]

I see two problems with that idea:

1. CSRF protection breaks the ability to navigate independently in separate tabs because loading and/or submitting a token-protected form in one tab will invalidate the tokens for forms in other tabs. (It's also easy to accidentally implement it in ways that break the back button. My student loans agency does both.)
2. Whoever wrote that helper on the OWASP site is seriously misinformed about the Creative Commons Attribution ShareAlike license. (There's no such thing as "just" a ShareAlike license)

None of them are GPL-compatible because the GPL says "all derivative works must be GPLed" and the CC-BY-SA says "All derivative works must be CC-BY-SA".

The only way they are compatible in layman's terms is that bundled resources for an application (eg. icons and other imagery) don't count as derivative works of the code and vice versa. (It's common for games to GPL their code and then use another license for the resources to prevent the combined whole from being legally allowable for third parties to sell on App Stores)

[ssokolow]

@GHANONTEST: Not really. It's like saying that you should turn off cookies because a few PHPSESSID URL parameters are better than being tracked around the web. (Aside from some sites requiring cookies for session tokens, it's been proven that it pollutes copy-pasted links and has various other problems)

It's like breaking the Back button because you're too lazy to do your AJAX/Flash application properly. Big UI design no-no. Not only can it be confusing, but it's bad PR because it looks much easier to fix than it is, so people who use it end up taking a hit to their reputation and that trickles down to FatFree. (Human-Computer Interaction and UI/UX design is the area I'm specializing in.)

However, I can imagine a CSRF protection scheme which should satisfy everyone:

• CSRF protection is automatically on for POST forms and automatically off for GET forms but both behaviours can be overridden. (eg. Sites sometimes use POST for Advanced Search forms because they take so much data that they run the risk of exceeding URL length limits in some browsers and CSRF protection for those is more pain for no gain.)
• Some mechanism is implemented to preserve more than one CSRF token per user.

The problem is that I haven't confirmed that the second requirement is actually possible. If it is, it would be be tricky to get right and may end up requiring Javascript somewhere. (Per-tab alternatives to cookies are only available via Javascript)

[ikkez]

as mentioned in issue #23, F3 already has some build in sanitizing features and some unit tests revealing them. Within the Docs at http://bcosca.github.com/fatfree/#forms-handler the Data Sanitation section tells some more about security.

[ikkez]

well it was just a short shot by the way - i guess such CSRF protection with tokens has its right place inside a form builder class,... but as long as there's no such plugin in F3, this would be the first thing to start with.

[KOTRET]

ikkez is right - tokenhandling is part of how you build up your forms and not F3 itself. And a form-plugin - huh... not that easy to satisfy all needs. If you have your own form-builder, then just implement a method to generate tokens and in submit just compare them and create a new one.