Silverstripe-framework: [CONTROL] Session invalidation because of UA String | One Plus Devices

[mrgray]

Affected Version

Tested on 4.0.3

phpunit/phpunit            5.7.27             The PHP Unit Testing framework.
silverstripe-themes/simple dev-master c2fdd14 The SilverStripe simple theme (default SilverStripe 3 theme)
silverstripe/recipe-cms    1.0.3              SilverStripe recipe for fully featured page and asset content editing
silverstripe/recipe-plugin 1.1.0              Helper plugin to install SilverStripe recipes
silverstripe/tagfield      2.0.0              Tag field for Silverstripe

But potentially affects all previous versions.

Description

One Plus devices (current and old) send different User Agent strings for GET and POST requests which causes session validation to fail because of,

vendor\silverstripe\framework\src\Control\Session.php

/**
     * Init this session instance before usage
     *
     * @param HTTPRequest $request
     */
    public function init(HTTPRequest $request)
    {
        if (!$this->isStarted()) {
            $this->start($request);
        }

        // Funny business detected!
        if (isset($this->data['HTTP_USER_AGENT'])) {
            if ($this->data['HTTP_USER_AGENT'] !== $this->userAgent($request)) {
                $this->clearAll();
                $this->destroy();
                $this->start($request);
            }
        }
    }

It's a documented bug found in their forum, but a resolution probably isn't close,
https://forums.oneplus.com/threads/chrome-user-agent-is-different-when-making-an-post-request.691815/
https://forums.oneplus.com/threads/inconsistent-user-agent-string-chrome-for-android-ajax-requests.796666/

Steps to Reproduce

• Logging into the CMS with a One Plus device and moving between pages.
• Additionally, adding a logging event to the Sessions.php file for monitoring the UA string between requests.

Debug Data

Here are the strings between requests for One Plus 5 and One Plus 3T, respectively,

GET: Mozilla/5.0 (Linux; Android 8.1.0; ONEPLUS A5000 Build/OPM1.171019.011) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/66.0.3359.158 Mobile Safari/537.36
POST: Mozilla/5.0 (Linux; Android 8.1.0; Build/OPM1.171019.011) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/66.0.3359.158 Mobile Safari/537.36

GET: Mozilla/5.0 (Linux; Android 8.0.0; ONEPLUS A3003 Build/OPR6.170623.013) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/64.0.3282.137 Mobile Safari/537.36
POST: Mozilla/5.0 (Linux; Android 8.0.0; Build/OPR6.170623.013) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/64.0.3282.137 Mobile Safari/537.36

Proposed Fix

We resolved this for our e-commerce systems by creating a configuration flag that allows disabling UA validation for session management. Another potential fix would be to drop UA validation completely? They're inconsistent and borky.

Pull requests

• [x] https://github.com/silverstripe/silverstripe-framework/pull/9170

[dhensby]

I'm definitely in support of removing the session invalidation on UA change as I've never thought of it as being a secure way to invalidate the session. It is essentially an HTTP header that anyone can spoof, so why should we trust it or give it weight over any other user input?

[dhensby]

However, this is unfortunately deemed a "security feature" so it'll need some really good reasoning for removing it.

OWASP also recommends using the UA as a way of detecting session anomalies (https://www.owasp.org/index.php/Session_Management_Cheat_Sheet#Detecting_Session_ID_Anomalies) so we really do need the One+ to sort this out as it's deemed "industry standard" to do so

---

Edit: OWASP do however acknowledge that these changes are basically useless against a "skilled" attacker

Although these properties cannot be used by web applications to trustingly defend against session attacks, they significantly increase the web application detection (and protection) capabilities. However, a skilled attacker can bypass these controls by reusing the same IP address assigned to the victim user by sharing the same network (very common in NAT environments, like Wi-Fi hotspots) or by using the same outbound web proxy (very common in corporate environments), or by manually modifying his User-Agent to look exactly as the victim users does.

[kinglozzer]

Given the market share that OnePlus have now (apparently ~50% in India), I think we need to do _something_. Perhaps just a flag to allow users to turn off the user agent validation (with a note about implications / recommending HTTPS)?

[dhensby]

(that's 50% of the "premium" market, FYI)

The User-Agent check protects against someone brute-force checking for existing session IDs with no knowledge of the session they are trying to steal.

If they manage to guess a session ID, there's no guarantee it'll be a session of a user they want access to (it could be a search bot's session, an un-authenticated visitor, a logged-in user, or an admin), if they find one (let alone an admin user) it's just pot luck. I don't want to work out what the chances are for a standard PHP set-up (clearly it depends on number of currently active users, too), but I imagine it's really really hard.

What it doesn't protect against is an attacker who knows the user session they want to hijack (ie: they are in a cafe on public wifi and they can inspect network traffic), even if using HTTPS the attacker can spoof it and intercept, they then know the SessionID they want to steal and the user agent (because they can see it in the requests).

Features like rate limiting would make session ID brute forcing impractical and we could also add some other features to block users/IP addresses that attempt to repeatedly access non-existing session IDs.

[a2nt]

Random UA is a way to protect browser against fingerprinting and SS won't work with privacy enhanced browsers

[maxime-rainville]

Do we want to provide a simple config option to allow people for whom this is a concern to disable UA checks when validating session?

It sounds like a reasonable way to address this issue without opening a security can-of-worms.

[dhensby]

Random UA is a way to protect browser against fingerprinting and SS won't work with privacy enhanced browsers

As much as I really don't think UA protection for session hijacking is worth the effort; OWASP does recommend it, so "privacy" browsers should be aware of this and accept it.

With the goal of detecting (and, in some scenarios, protecting against) user misbehaviors and session hijacking, it is highly recommended to bind the session ID to other user or client properties, such as the client IP address, User-Agent, or client-based digital certificate. If the web application detects any change or anomaly between these different properties in the middle of an established session, this is a very good indicator of session manipulation and hijacking attempts, and this simple fact can be used to alert and/or terminate the suspicious session.^[1]

[1] https://www.owasp.org/index.php/Session_Management_Cheat_Sheet#Binding_the_Session_ID_to_Other_User_Properties

They do also suggest IP address change as another indicator, which I think is completely mental given the prevalence of mobile phones and the likelihood that they could switch from WiFi to Cell data at any time.

[dhensby]

Do we want to provide a simple config option to allow people for whom this is a concern to disable UA checks when validating session?

Maybe that's best :/

[ioquatix]

I am having the same issues with a different framework, and I found this discussion really helpful.

The other framework is tracking request ip and user agent. I've never had an issue with user-agent changing, but I've definitely had issues where the browser switches between IPv4 and IPv6.

I'm not sure what the solution is. I would be nice if the client could provide a per-domain unique fingerprint for this purpose.

[ioquatix]

I ended up removing IP address checks. I typically deploy all sites over SSL anyway. That being said, IP address was probably a pretty good check... but hard to validate in the face of legitimate changes (e.g. mobile roaming/wifi, IPv4/IPv6).

[johnanders123]

Is there any update on whether you will be able to disable this check with a configuration. I'm having a similar issue with Cloudfront.

[maxime-rainville]

I put a quick PR together to disable the user agent string check. https://github.com/silverstripe/silverstripe-framework/pull/9170

I had a quick glance and didn't find an IP address check on the session. Do we know, for a fact your session gets invalidated if your IP changes?

[johnanders123]

No, I haven't dug that far into the issue. I know that it is the user-agent
that is causing the issue when it is passed through Cloudfront to the app.

On Tue, 6 Aug 2019 at 22:13, Maxime Rainville [e-mail]
wrote:

I put a quick PR together to disable the user agent string check. #9170
https://github.com/silverstripe/silverstripe-framework/pull/9170

I had a quick glance and didn't find an IP address check on the session.
Do we know, for a fact your session gets invalidated if your IP changes?

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/silverstripe/silverstripe-framework/issues/8073?email_source=notifications&email_token=ADZATMD434TJTZIZ3ESQNODQDFFDNA5CNFSM4FAEQNBKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD3UU6NY#issuecomment-518606647,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ADZATMFAFOC67CEJYKLQZWTQDFFDNANCNFSM4FAEQNBA
.

--
John Anderson | System Administrator | Springload
[email protected]
www.springload.co.nz

m:[phone]
p: [phone]

Proud sponsors of NZ Festival http://www.festival.co.nz/, Webstock
http://www.webstock.org.nz/, and Collaborate
https://app.letscollaborate.co.nz/.
We're also proud to offset our carbon emissions.

[dnsl48]

https://github.com/silverstripe/silverstripe-framework/pull/9170 has been merged. It's gonna make it to the next minor release (SS 4.5).

@johnanders123 does cloudfront generate some random user-agents, or is it something else? AFAIK it's a best practice not to whitelist user agent on cloudfront anyways? https://stackoverflow.com/questions/52964794/aws-cloudfront-forward-user-agent-but-dont-cache-against-it

[ScopeyNZ]

Should we close this issue because #9170 is merged or is there more scope to this PR?

[dnsl48]

Looks like it's done. John, let me know how it goes with cloudfront :)
Otherwise, the feature should land to 4.5 release.

[johnanders123]

That's great news. Thanks! :) I believe the issue is that if the user-agent is whitelisted on cloudfront it will vary and it is not recommended from a caching point of view. In certain key circumstances we would like to be able to still log that information for informational purposes even if there is some inconsistency.

[dnsl48]

In certain key circumstances we would like to be able to still log that information for informational purposes even if there is some inconsistency.

I see. Well, then it feels like same issue as for the topic starter, since CloudFront by default replaces User-Agent header with Amazon CloudFront, which is a static string and doesn't change.