Bug #22336

Backend session is locked to useragent

Added by Andre Haensel over 11 years ago. Updated over 10 years ago.

Status:
Closed
Priority:
Should have
Category:
-
Target version:
-
Start date:
2010-03-29
Due date:
% Done:

0%

Estimated time:
TYPO3 Version:
4.3
PHP Version:
5.2
Tags:
Complexity:
Is Regression:
Sprint Focus:

Description

When the browser changes the user agent, the user is logged out from backend. There is no configuration option for this.

The useragent string is changed e.g. by Firebug/FirePHP.

The lock provides no security against session hijacking because every attacker who can spoof the session id, can easily forge the useragent string, too.
(issue imported from #M13938)


Files

useragent.patch (4.23 KB) useragent.patch Administrator Admin, 2010-08-27 14:04
0013938_v2.patch (4.22 KB) 0013938_v2.patch Administrator Admin, 2010-08-27 14:28
0013938_v3.patch (2.86 KB) 0013938_v3.patch Administrator Admin, 2010-09-02 19:20
bug13938_v4.patch (2.88 KB) bug13938_v4.patch Administrator Admin, 2010-09-02 23:38

Related issues

Related to TYPO3 Core - Bug #22251: Google Chrome Frame Plugin leading to lost sessionsClosedMichael Stucki2010-03-08

Actions
Has duplicate TYPO3 Core - Bug #23053: Typo3 login expiration note shown immediately after logon with Internet ExplorerClosedSteffen Gebert2010-06-30

Actions
#1

Updated by Marcus Krause over 11 years ago

to be discussed in the security team

#2

Updated by Marcus Krause over 11 years ago

The TYPO3 Security Team is fine with making the check configurable.
By default, the UA should still be bound to the user's session.

Binding the UA to the session has been okay for years and has been deployed on a wide range of web applications. Then, the plugins were created that break the browser's behaviour.

I'll reset the ticket's state to new.

#3

Updated by Ralle Büchnitz over 11 years ago

This seems to be part of the solution for my problem. :)

If you log in without firebug enabled and then switch to frontend and enable firebug to check/inspect output. I often will be logged out. The only way to prevent is to open and close firebug immediately. Otherwise the ajax session-validity-check will log me out. Hopefully you have firebug open already or don't need it during work on a website?!

Then (after logged out) another problem occurs. The relogin popup form is shown and will not allow to relogin by clicking the button! So I have to wait 30 seconds to enter my password again.

Actually keep firebug open for all time is no real option. Memory-consumption will grow, as well as network log will be flooded with all ajax requests and answers. There are actually a lot of requests and not realy necessary for backend. And changing the firefox-settings (network on/off ,...) each time you switch from frontend to backend is pretty annoying.

#4

Updated by Mark Möller-Bengtsson over 11 years ago

Certain addons for IE, such as ChromeFrame frequently changes the user-agent which totally breaks the session-management in TYPO3.

Described here: http://www.devcomments.com/Google-Chrome-Frame-Sessions-at87777.htm

To circumvent this behaviour set the install-tool-value lockHashKeyWords to blank instead of useragent.

As Andre states in the report, "The lock provides no security against session hijacking because every attacker who can spoof the session id, can easily forge the useragent string, too.".

#5

Updated by Björn Pedersen over 11 years ago

Checking the answer from Mark:

lockHashKeyWords is available only for FE, so the solution would be to add it also for BE.

#6

Updated by Björn Pedersen over 11 years ago

Additionally it turned out, that this setting seems not to be used by class.t3lib_userauth.php.

The attached patch fixes that.

#7

Updated by Björn Pedersen over 11 years ago

v2 fixes the wrong line break in config_default.php

#8

Updated by Markus Klein over 11 years ago

v3 diff against current trunk and at root level.

#9

Updated by Markus Klein over 11 years ago

uploaded v4 after hints from Marcus Krause on core list

#10

Updated by Frederic Gaus over 11 years ago

Small hint:

Many customization themes of IE lead to differences in the user-agent string send within an ajax-request and the user-agent string within a normal get-requests. Sample browser-themes are

T-Online-Browser
AOL-Browser

For example some version of T-Online-Browser:
normal request:
Mozilla/4.0 (compatible; MSIE 7.0; TOB 6.07; Windows NT 5.1)
AJAX request:
Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1)

So I'm asking myself: Should the user-agent check be disabled by default?

#11

Updated by Markus Klein over 11 years ago

Oho! Thx for this info.
This is getting a question for the security team more and more.

if we disable this by default, which is actually neccessary after your findings, we could actually drop this lockHash.. feature completely.

#12

Updated by Frederic Gaus over 11 years ago

Further result of my tests:

The user-agent of the last installed browser is send. If someone has the T-Online browser installed and starts the normal IE, the T-Online user agent is send.

After installing the AOL browser, the three browsers send the AOL user agent.

After deinstallation of both browsers (AOL and T-Online), the normale IE still sends the user agent of the last browser.

I'm not sure, if this behavior is the same on all operating systems.

#13

Updated by Helmut Hummel over 11 years ago

Marcus' statement is still valid. Just replace "the plugins" with "customization themes of IE".

We should ship a default configuration that is more secure instead of compatible with some strange marketing themed browsers.

#14

Updated by Markus Klein over 11 years ago

Welcome to the juggle between security and usability.

It cannot be the choice of the sysadmin whether to allow a normal usage of a member area for these users by disabling [FE][lockHash..] or not.

I've really no idea how widespread these themed browsers are, but you can't put a message underneath the login box saying: "Hello user! We're using AJAX in our member area. If you're using a themed IE browser - like from AOL - we are sorry, but it won't work for you."

Any suggestions how to deal with this situation?
Maybe we should look up some statistics about the usage of these user-agents to get an orientation what we are dealing with.

#15

Updated by Helmut Hummel over 11 years ago

Markus, this discussion is neither in scope of this report, nor is this a good place to discuss. Please move the discussion to the typo3.dev list. Thanks.

#16

Updated by Markus Klein over 11 years ago

Ok, this may not be the scope of this report, but it's in the scope of the RFC pending on core list as the changes in the last patch also affect lockHash.. for the frontend. I'll move the discussion to dev list tomorrow.

But my opinion is, that this RFC should not be commited until there's a clear statement from the core team, if or how we should deal with these stunted browsers.

regards

#17

Updated by Helmut Hummel over 11 years ago

The patch changes nothing because $TYPO3_CONF_VARS['FE']['lockHashKeyWords'] was set to 'useragent' in config_default for ages. It only introduces the possibility to switch off this check for BE users also.

#18

Updated by Markus Klein over 11 years ago

And this is the problem. We have new information that this feature, even though it's been there for ages, can cause troubles. As we're already touching this setting - by moving the point where it is read - we could think of improvements at the same time.

I tried to state what I think about this, but as nobody else seems to share my opinion I'll shut up now.

Thanks for the latest patch on the core list.
Regards

#19

Updated by Helmut Hummel over 11 years ago

Markus, I did not intend do discourage you. I only wanted to keep seperate things seperate. Introducing a new feature (enabling the admin to disable useragent locking for be users) in one thing, changing a default setting another. Of course they are related, but still different.

If you insist on changing the default, discuss this on the dev list (like I suggested) and/ or open a new ticket and set this one to related.

Easy as that. ;)

#20

Updated by Marcus Krause over 11 years ago

I'am of the same opinion of Helmut. It's a good protection against session hijacking.
We don't want to change current behaviour. But this RFC enables you to loosen the setup and such prevents problems with your specific setup. A progress after all, don't you think?

#21

Updated by Frederic Gaus over 11 years ago

Here is how Magento treats this topic: There is a user agent check available, but it's disabled by default.

Another solution could be:
- Store two different user agent strings per user. One for ajax and one for normal requests. This would at least solve the problem with themed browsers. For everyone where this is not enough (e.g. because he uses special plugins), provide a way to disable the check completely (like the attached patch does).

#22

Updated by Sebastian Mendel about 11 years ago

Where is the vote button? this logut-mechnism is really annoying ... but sorry for the noise -- keep on finding a best for all solution! :-)

#23

Updated by Markus Klein about 11 years ago

Hi Sebastian,

please subscribe to the core list http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-team-core and give your +1 on reading and testing.
Latest patch version is v8.
Have a look at the core list history.

Please also read the list rules here:
http://typo3.org/teams/core/core-mailinglist-rules/

#24

Updated by Ernesto Baschny almost 11 years ago

Committed to trunk, rev. 10119.

#25

Updated by Susanne Moog over 10 years ago

  • Target version deleted (4.5.0)

Also available in: Atom PDF