akeeba / fof

Rapid Application Development framework for Joomla!™ 3 and 4
0 stars 0 forks source link

Update Controller.php #580

Closed f-liva closed 8 years ago

f-liva commented 8 years ago

This is the correct method to check the token because trying to get it from the input data get problems with servers that use some caching systems like Varnish or other when the token is manually reset from a specific cache-system pilot plugin.

Running a component made in FOF in the SiteGround hosting, always get 403 forbidden errors due this wrong check procedure.

If you need more explanations ask to me.

f-liva commented 8 years ago

What's the problem with Travis? The test which failed isn't inherent to this change.

nikosdion commented 8 years ago

I don't understand what you are trying to do here. The Controller::csrfProtection() method checks to see if a security token (session token or form token) exists in the request. Instead you replaced that with a call to JSession::hasToken() which merely checks if a session token exists in the current session WITHOUT checking if the session token matches the one set in the request – or, worse, if there is no token set whatsoever! In other words instead of checking if someone inserted a key to the lock and whether the key can turn the lock you are only checking if a lock is installed on the door, in which case you let everyone in.

Also, do note that you do get 403 forbidden because you're apparently caching a page that contains URLs or a form which include a token. Since Varnish caches the pages globally, a page generated from User A's session ends up being displayed in User B's session. Since the security token is by definition different in different sessions you will of course get a 403. Forms and pages with links that contain tokens must not be cached. You need to send a cache busting HTTP header (set the expiration into the past).