[TYPO3-dev] Improvement against SQL injections

[ries van Twisk]

Since we have DBAL in place,

why not parse all SQl statements and deny insert/delete/updates to
tables using a rule set similar to ACL's.

I am always against giving extension direct DB access (in any system)
and I strongly believe there should be a proper DB API.
directly using SQL is often way to dangerous when it's done from a  
extensions point of view.

One other method similar as above is not to give access to BE tables  
when no
BE session is active. This can be done from MySQL directly using each  
DB's
permissions system. That's why it's there for and an be used as such.

Of course some sort of service needs to be build (it might be already  
in TYPO3 and can be used with
minor modifications) that can authenticate a FE user to a BE table.

Appart from that:
With a proper DB API you can also setup a ACL on a DB level.
Then you can tell the system what extension can insert/update/delete  
to what tables and fields.
What the permissions are etc. This could be something for TYPO35 of- 
course and
cannot be done in typo3 4.x branche anymore.

The first idea would be possible with typo3 4.x blanche of course.

Ries (thinking out loud)

On Jun 15, 2007, at 1:48 PM, Lars Houmark wrote:

> Hello developers - especially core team,
>
> We have recently seen a rather big threat with macina_banners, using
> simple SQL injections to gain backend access.
>
> That made me start thinking about how to improve the backend against
> exploits where modifications to the be_users table has been done by
> the evil person.
>
> Here is my idea:
>
> We need a new file. Suggestion for filename: checksums.php - placed
> in the typo3conf folder.
>
> This file holds an array with a checksum of all be_users where the
> checksum is created from the fields; username, password, admin,
> usergroup, disable, tstamp and maybe some others. This checksum is
> being evaluated everytime a login is done. If the checksum is correct
> the user is logged in. If not, well, no login. This is logged and
> maybe a warning email like the admin login warning is sent.
>
> When a user is created or modified, this array is updated, so that
> the checksum is correct.
>
> Why all this?
>
> Well. When an evil person is using an exploit, he gain access to
> modify rows in the database. An simple insert query can add another
> backend user, which is admin!!! (only a 1 is needed in the field  
> admin).
>
> By having a simple file, with this array with checksums, this is no
> longer possible. We think that the macina_banners case used exactly
> this method and gave the evil person a very extensive access to the
> actual installation.
>
> These modifications is pretty simple. Only modifications to the add/
> edit core functions for users is needed. Of course the constant
> syncing of the checksum array needs to be pretty intelligent, but
> hey... You are intelligent guys ;). Besides that some initial
> creation of the file and array is needed for users updating from
> older versions.
>
> We have discussed this on the security list and feel this will secure
> TYPO3 in a new dimension, cutting of the evil hackers way of gaining
> the backend access.
>
> Maybe you think the file method is not very nifty, but if you have
> any other smart way of getting the same done, please enlighten us ;)
>
> I an see only positive things about using the file. Cross platform
> compatible. Very well tested. Completely separated from the database.
> Why a new file and not just use the localconf.php? Well. Remember the
> localconf bug? ;) Also the localconf.php is thought of as a file that
> can be manually edited by advanced users. This way they may modify
> this checksum array - maybe by mistake, locking themself and maybe
> everyone else out of the installation. The file should be documented
> in such way that it is DO NOT EDIT!
>
> I would very much like to see this implemented very soon. I feel this
> is very much going to secure TYPO3 on a new level, because right now,
> it is actually very easy to get backend access, if one can find just
> one simple SQL injection.
>
> If I am talking all gibberish - then please tell me, and I will try
> to explain myself better ;)
>
> Have a nice weekend...
>
> Regards,
>
> Lars Houmark
> lars at typo3.org
>
> Team Leader of the TYPO3 Security Team
> _______________________________________________
> TYPO3-dev mailing list
> TYPO3-dev at lists.netfielders.de
> http://lists.netfielders.de/cgi-bin/mailman/listinfo/typo3-dev