TYPO3 Core

to be discussed in the security team

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.

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.

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.".

Checking the answer from Mark:

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

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

The attached patch fixes that.

v2 fixes the wrong line break in config_default.php

v3 diff against current trunk and at root level.

uploaded v4 after hints from Marcus Krause on core list

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?

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.

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.

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.

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.

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.

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

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.

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

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. ;)

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?

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).

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

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/

Committed to trunk, rev. 10119.