[TYPO3-dev] Improvement against SQL injections

[ries van Twisk]

On Jun 16, 2007, at 12:52 AM, Lars Houmark wrote:

> On 16/06/07 0:17, in article
> mailman.328598.1181945865.21067.typo3-dev at lists.netfielders.de,  
> "ries van
> Twisk" <typo3 at rvt.dds.nl> wrote:
>
>> 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.
>
> Well. First of all. In the macina_banners case the atual statment in
> question was not going through any TYPO3 core SQL engines and by  
> that not
> the DBAL engine, making any parsing impossible. And by that it  
> leaves this
> solution to a halt, because it will never be asked to do any work.  
> We can
> (unfortunately) never rely on extensions developers use DBAL  
> reliant code.
>
>> 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.
>
> So am I. But the way PHP is designed and TYPO3, this is (again
> unfortunately) what we are facing.
>
>> 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.
>
> Yes. But this really requires some very comprehensive MySQL work  
> (and by
> that is needed to be ported to all database platforms). This may  
> set some
> specific requirements to the MySQL version and I feel this is a very
> extensive method to reach the goal.
>
> In case we want to reacht this goal: Is the current session  
> handling system
> based on the MySQL or is it selfbuild in PHP? If not, then we need  
> to recode
> that as well - and make all of DBAL compliant.
>
>> 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.
>
> Again. This is doing a marathon to get a pizza when your just plain  
> hungry
> on a Sunday ;)
>
>> 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, don't get me wrong. I really appreciate your loud thinking,  
> but I do
> feel that your solution is based on some very modern methods and  
> maybe to
> fresh methods, which leaves me with concerns. Mine is still pretty  
> simple
> (but maybe not very elegant) and working without any surprises.

Like I said, I was just thinking out load... That sometimes helps to  
refresh others
brains and get there ideas (or not).
I don't use that banner system so I cannot tell how it uses the DB  
and I didn't
take a lok at the code. I am sure that of the 3000 extensions we now  
have we have
more of these.


>
> My primary goal is to decrease the possibility of modifying some very
> central database tables such as be_users, because I have learned  
> that this
> method is the most desired way of getting the major access of the  
> website
> one wishes to gain control of.
I hope it will not lock anybody out in some way...

But no worries...
Do what you think that needs to be done.

Ries

>
> A login is done not very often, so the overhead of doing the  
> evaluation
> through PHP is IMHO not any concern at all.
>
> - Lars
>
> _______________________________________________
> TYPO3-dev mailing list
> TYPO3-dev at lists.netfielders.de
> http://lists.netfielders.de/cgi-bin/mailman/listinfo/typo3-dev