[TYPO3-dev] Idea for hardened TYPO3 BE-User-Accounts

[Henning Pingel]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Christian and Dmitry, hi everybody,

This topic "Hardening TYPO3 core against stealing usable backend user
account data via existing SQL injections" has recently been discussed to
quite an extent within the TYPO3 security team before and also after
T3CON07 - and I'm happy to see that there is now also a discussion on
the dev-list.

The security team had quite an amount of ideas regarding solving this
problem. At the same time, some of us also were of the opinion that it
wouldn't harm to discuss this topic publicly on this list (dev) to get
more opinions and ideas, since the problem is no secret any more since
T3CON07. (As long as no unknown security holes are revealed, public
discussions about security improvements are IMHO a good thing.)

So if anybody of you has further ideas regarding this problem, I would
like to encourage you to discuss them here. We already seem to have
found a concept on how to improve things within the security team, but I
personally would find it sad if this discussion you have started here
would not be "supported" / acknowledged in some kind of way by the
security team or some of its members. ;-)

Since I have not asked permission of the other security team members to
publish our current concept here I don't want to post it at this time.
But I would like to talk extensively about the problem we are trying to
solve, because it can't hurt TYPO3 developers to think about it.

The basic problem is that we try to harden a TYPO3 installation to be
still secure even after a security hole in an installed extension has
already been exploited. We try to somehow introduce a second inner
security "wall", because the attacker was already able to jump over the
outer (and only) security wall - by exploiting a SQL injection. "First
security wall" means: A cautiously configured web server where all
software components used (Apache, PHP, MySQL, TYPO3, ...) have been
correctly configured to not open up any security holes.

Building a second wall makes only sense if the wall is of the same
height everywhere. So we have to take care that we don't increase the
height of one half and forget to increase the other half of it. SQL
injections are not the only security vulnerabilities that we face from
time to time.

So to simplify this a bit it means we try to protect one PHP script from
the next PHP script within the same web space, because we don't want to
trust it too much. This is not an easy task, maybe it's even impossible.
But it's still important to work on it, because the probability that we
might use an extension that contains an unknown security issue is not
that low. (Here many PHP based web applications / WCMS's IMHO share the
same problem.)

Within the security team we finally named four problems that we want to
solve with our concept. I quote here from our internal discussions:

1) We don't want it to be possible to login with the md5 value that's
stored on the server but only with the password itself.

2) We don't want it to be possible that bad guys listening on the
network line can sniff the passwords (the problem SSL addresses).

3) We don't want bad guys to be able to obtain a md5-hashed password
from the be_users table (through an unknown SQL injection in an
extension).

4) We don't want bad guys to be able to add/modify a valid user account
in table be_users (through an unknown SQL injection in an extension).

So I hope I can help to reanimate this thread a bit with this posting.

Cheers,

Henning
Member of the TYPO3 security team


Am 26.10.2007 10:51 schrieb Christian Trabold:
> Hi Dmitry,
> 
>>> What about a new field in be_users which stores a value (the salt)
>>> which is unique for the given TYPO3-Installation (eg
>>> TYPO3-Encryption-Key).
>>>
>>> If a backend user logs into the backend this value is checked against
>>> the current TYPO3-Encryption-Key.
>>
>> Than it should be not clear encryption key but md5($username,
>> $encrkey). And remember about database keys. This query hits performance.
> 
> I reconsidered my idea and came to the conclusion, that it would not
> harden anything...
> 
> 
> Why? Well, if a hacker can fire SQL-Statements, it's easy to fire one
> first SELECT-Statement to get the salt, which could be used in a second
> run for an INSERT-Statement.
> 
> 
> 
> *Conclusion*
> The very best way to harden TYPO3 is minding the coding guidelines [2]
> and the TYPO3 Security Cookbook [2].
> 
> 
> Greetings,
> 
> Christian
> 
> 
> [1]http://typo3.org/documentation/document-library/core-documentation/doc_core_cgl/current/
> 
> [2]http://typo3.org/teams/security/




-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHJ6oqWAnue6OC6+URAvpKAJ97I1XGwyLcJ0GgQDzgTBcc5wwYSACfTE8q
tLs0DtEHudZ2tsiEuIW1tPM=
=+JSF
-----END PGP SIGNATURE-----