[2.1.7]: Session verification failed

[sbulen]

Basic Information

Some users on forums who have guest views disabled have had issues with Session Verification Failed errors after patching to 2.1.7.

Source of the issue appears to be the empty cookie check in PR #8394 :

SMF/Sources/Session.php

Line 177 in 05f4aa8

// Don't bother writing the session if cookies are disabled; no way to retrieve it later

...since removing it resolves the issue for these folks.

Interesting that the issue happens on the non-modal login box but not the other login links... I suspect stale session vars are getting used for the non-modal login somehow.

I cannot reproduce this, & have spent a LOT of time attempting to do so. But it's been reported twice on no-guest-browse forums since the 2.1.7 patch.

I'd hate to remove it, as it has helped A LOT in terms of CPU on my forum during botnet attacks.

Still thinking it thru... Any ideas, feel free to share...

Forum discussions:
https://www.simplemachines.org/community/index.php?topic=594016.0
https://www.simplemachines.org/community/index.php?topic=593947.0

Steps to reproduce

1. Disallow guest browsing
2. ???

Expected result

No response

Actual result

No response

Version/Git revision

2.1.7

Database Engine

All

Database Version

No response

PHP Version

No response

Logs

Additional Information

No response

[sbulen]

The core of the issue, I think, is that there is no way for the session write to detect if cookies are disabled.

The ONLY real test for disabled cookies is to write to it & read it on the next transaction. Which, of course, you cannot do in the middle of a session write. The empty cookie test used now works well, because everyone will at least have the PHP session cookie no matter what.

But there are clearly times even that is getting deleted somehow. There are some terribly convoluted ways I can reproduce, e.g., multiple forums on the same server, log out of one on one tab kills the PHP session cookie for the other on the other tab... (Which, itself, is fascinating, because it means PHP is using the same session ID for both forums... Same PHP server, same browser...)

[sbulen]

Sharing tests & thoughts thus far.

I still cannot reproduce this issue in 2.1.7; no combo of SMF & environment settings that I've tried destroys all the cookies as seen in the forum reports.

However, I do see this behavior if I test with a no-guest-browsing forum with #9126...

Background... Two forms of botnet attacks can cause significant resource issues, for similar reasons. 'Long tail' botnet attacks, where hundreds of thousands of different IPs hit you with only one request each, and 'Cookie-less' botnet attacks, where the bot disallows cookies (or ignores them, or otherwise passes bogus sessions). Both types of attack can force crazy high volumes of new, unique session creation, because that guest looks new to the forum with each request. Your DB CPU is totally at the mercy of the bots in these scenarios.

So just don't write them! But... Without writing a session, all the session checks fail, because they validate against session contents, which don't exist... Even if you were to give guests a pass on session checks, they'll fail the token check for the same reason. The login form token is also validated against the session contents.

Everyone is a guest until they login... I don't think we want to get rid of session & token validation for logging on, that feels like a recipe for disaster. So we need sessions for all guests??? That's the conundrum: can't live with them, can't live without them.

OTOH...

It works 100% of the time with logon links & the modal login form - even for the users reporting this in 2.1.7. It is failing for some users, specifically when guest browsing is forbidden, specifically for the non-modal logon form... That logon form, which is presented instead of the board index when guest browsing is disabled, is somehow ending up using stale session vars, so passing a bogus session when the user tries to logon.

I think the logon links work because they grab fresh session vars (and a new cookie) when the modal form is built. So I believe making the non-modal form behave more like the modal form will fix the issue.

Related PRs across 2.1 & 3.0: #9126, #9152, #8394, #8399

[sbulen]

Connecting the dots... The modal form works because it performs the "only real test for disabled cookies" described above... It forces a session/cookie & immediately tests against its contents.

[jdarwood007]

For things that need it, like certain forms, we can do a JavaScript check to see if document.cookie exists and present the warning if it does not. We can even disable some features if they are not needed for those without cookies.