[TYPO3-dev] RFC #11120: stdWrap for TypoScript-select parameters

[Jigal van Hemert]

> Von:        Jigal van Hemert <jigal at xs4all.nl>
>>>> TypoScript requires that values keep untouched referring quotes
>>>> because stWrap and other Options can be inherited - Quoting could
>>>> breakdown the concept.
>>
>> Can't we take a different approach?
>> If there would be a new type of select function which functions like a
>> PDO prepare() function [1]?
>> [1] http://www.php.net/manual/en/pdo.prepare.php
> I never worked with PDO::prepare but as far as I understand the manual
> you linked, each allowed variable has to be binded which means it has to
> be defined and a prepare-statement has to be build.
> SQL-Statements from TS aren't known to the core, so there had to be
> build a completley new function or class that handles these statements.

I just used the prepare() function as an example how escaping could be
handled by "the core" to make the whole process (if all is well) immune to
SQL-injection problems.
Because it is very hard to interpret all kinds of SQL statements easily to
quote the things after the query is built it's easier to provide a
mechanism to force the integrator to use a syntax for inserting external
(= anything that is not literary data) data and still maintain certain
safety levels.

plaap = CONTENTS
plaap {
  table = tt_news
  selectNEW {
    selectFields = title
    join = tt_news_cat_mm ON tt_news.uid=tt_news_cat_mm.uid_local
    where = tt_news_cat_mm.uid_foreign={%catuid}
    markers {
      catuid = GPvar:tt_news|cat
    }
  }
}

This is just an idea (and the query may not be valid) and most likely the
markers part needs a lot of changes :-)

The properties of the selectNEW (just a dummy name) can now be stripped
from stdWrap functionality. This forces integrators to use markers ( demo
syntax: {%markername} ) which can easily be quoted/escaped by the core.

> Another point: Well done SQL-Injection has a sense for the database and
> is calling existing tables and fields. Sending Statements to the core
> you have to determine if the statement has to be interpreted or not
> anyway. It's not possible for a abstract class to verify which
> statements are guilty from administrative view.

True, that's why I propose to use markers for variable data (just like the
PHP PDO prepare() function). If you use unsafe data through such a marker
the core routines can quote/escape the data before injecting it in the
query.

> Other points are:
> 1) The code shouldn't be so hard to read (that's not from me but from a
> core-developer, nevertheless I agree ;-) )
The TS is not harder to read than when you use constants or other data.

> 2) The normal t3lib_db.php-file is or should be only a wrapper-function
> and we've to keep in mind that there are also other databases than mySql.
There are no changes needed to t3lib_DB. The escaping is handled in the TS
handling routines.

> 3) when the PDO-library is really used (instead of rebuilding some
> funtions like I understood you) the question occures if it's available
> for different combinations of Servers (Apache, MySQL, ... - Hardware
> doesn't matter I think) and Operating-Systems.
No need to use the PDO-library. I just used it as an example for using
markers instead of the actual data in a query (or part of a query).

> 4) I've the impression that your proposition does change a lot and is
> able to brake down functionality of core-parts and extensions.
Yes, it does change a part of TypoScript; the 'old' TS select-function
will become deprecated.

> 5) Creating new markers wouldn't be backward-compatible I think or the
> work to integrate it compatible would be quite huge.
I don't see a way to force security in quoting data inside a query and not
limiting current functionality.
Maybe enabling the new select-function and disabling the old functionality
can become part of the compatibility mode in the install tool? That way
the site owner can decide whether to enable the security mode or not.

> Question is: who will integrate your idea?
> When you're sure it works perhaps you should do that?
hehe :-) Well, when a core developer is willing to discuss a few things
and help and check my implementation, I'm not totally against the idea :-)

-- 
Jigal van Hemert.