[TYPO3-dev] Improvement against SQL injections

[Martin Schoenbeck]

Hi Lars,

Lars Houmark schrieb:

> What you suggest relies entirely on correct user setup. We have bad
> experiences with just that. This is why I propose a method that is
> completely independent on the actual setup.

I already explained that it doesn't rely on the user at all. I can't see
any reason why the grants couldn't be set or at least checked by TYPO3.
TYPO3 could even deny operation in the frontend as long as the rights
aren't set properly. So this could be ensured even if a user later changes
rights.

> Yes, I only want to do this for the be_users table, as this is the one
> giving access to the backend, where the user gets a very unrestrictive
> access afterwards.

May be it's enough, to shut the entire site down and require the user to
install a backup. But if you can keep the system clean with a comparable
amount of time, I'ld prefer that.

> I acknowledge your suggestions and think they should be added to the
> security cookbook (I will note this), but would like you to think of a
> solution where there is no need for the user to setup up things correctly.

I don't think, the user has to setup things correctly in this case. But of
course there are many cases, which already require the user to do things
right. So even if the user had to act here that is the better way. A hint
in the security cookbook will be void, as long as TYPO3 uses the same user
for FE and BE access.

> I think my solution indeed will hinder that at least backend access is taken
> by an evil person, and that is at least hindering of successful arbitrary
> queries to the be_users table which equals increased security. Not ensuring
> the entire system, but that is simply impossible with the structure and
> flexibility of TYPO3 as it is now.
> 
> Yes, one can still delete all data in database tables and by that destroy
> the website, but we must hope for a professional hosting setup where backup
> is made on a regular basis.

You'll need that backup not only in this case. If there are no valid admins
left, due to changes in the be_user table, you'll have to grep your backup. 

> What my success criteria is, is only to stop the easy access for a hacker
> that by getting backend access will be able to do the kind of harm we have
> seen in the macina_banners case.

You'll make it more difficult to get backend access with this open door.
But the hacker than has access to modify any typoscript setup and I bet,
there will be chances to call interesting routines that way.

It's generally not a good idea to patch against problems by rising the
level of complexity. At least if there are methods which are intended to
handle the problem. Especially if they are much less complex.

Martin
-- 
Bitte nicht an der E-Mail-Adresse fummeln, die paßt so.