[TYPO3-core] Access denied for old security bug

Christian Weiske cweiske at cweiske.de
Wed Jun 19 21:04:10 CEST 2013


Hello Helmut,


Thanks for the torough explanation.


> 1. It breaks a feature[5]

This is true.
The reason for it is that the code cannot know if the user name 
is meant to be an OpenID or a normal user name.

What I could do is check if there is an OpenID with the same hostname
as the unnormalized ID. If that's the case, it's most likely to be an
OpenID.

Or, maybe better: Check if the normalized username is a registered
OpenID and use the normalized version if it is. Otherwise, require it
to be a proper URL.

> 2. You claim your patch as bugfix, while OpenID auth with google
> works fine when using the https://profiles.google.com/<profileid> URL
> without any modification

This is correct because you have a g+ profile. If you have a
non-g-plussed google account, you have a dynamic OpenID.

See [10, 11] for more information.

[10]
http://blog.stackoverflow.com/2009/04/googles-openids-are-unique-per-domain/
[11] http://blog.stackoverflow.com/2010/04/openid-one-year-later/


> 3. Your patch introduces a different OpenID handling path 
> (identifier_select) which coincidently works together with the 
> implemented way (user claims id). These two paths should be clearly 
> separated code wise

My patch replaces the existing handling path completely, and works as
the OpenID spec defined the login process.
I don't see why there have to be two different code paths.

> 3a. There is no way I'm aware of to find out what ID to specify in
> the user record without debugging the OpenID response

This is an issue, yes.
There should be a wizard in the backend user form to add an OpenID.
That way the wizard could set the proper value.

> 3b. It stays unclear for users what to specify in the user record and 
> what to specify in the login field

They have to specify their OpenID if they know it.

If they don't, they may fall back to the generic provider URL - which
is made easy for them by the use of Provider-Logo-buttons on other
OpenID consumer implementations.

> 3c. If your statement "Another issue with google is that they return 
> different OpenID identifiers for the same account for different
> OpenID consumer domains." is true (I could not verify it), such an
> approach needs use a truly unique identifier provided by the OP to
> identify the relation to a TYPO3 user

Stackoverflow use their email address for google.com OpenIDs - a
special case just for google. See [10, 11] again.

> 3d. Such unique identifier should be easily retrievable for end users
> or administrators and should be entered in a different field, not the 
> claimed id field

This would be provider-specific, so I wouldn't try it at all.
By allowing multiple OpenIDs, you'd have the chance to log into the same
account on different domains.
This would be a new feature.


-- 
Regards,
Christian Weiske


More information about the TYPO3-team-core mailing list