[TYPO3-core] RFC #13940 Preventing SQL injections in CONTENT object

[Jigal van Hemert]

Martin Holtz wrote:
> I think it is good to provide a solution to build secure SQL without the 
> need for an own userfunc, but i totally disagree with marking andWhere as 
> deprecated.

andWhere's only purpose must have been to supply a property with stdWrap 
support. This introduced the SQL injection problems.
Anyhow, without deprecating this property we only provide a mechanism to 
bypass SQL injection problems, but still leave the route open to 
introduce your own SQL injection security problem.

> Why not just add andWhere to the list of supported markers? 

Marker handling is only provided for the (string) value part of each 
property. It's not used in stdWrap, simply because it's specific for 
safely injecting values in queries. So your example below with markers 
in properties of a TEXT object won't work that way.

> To make it clear: Admin and Developers are responsible for their code, so 
> don't break existing code without need. 

Maybe they are legally responsible, but if a major website you made was 
hacked the news messages about it would not say that a Martin Holtz 
website was hacked, but that a TYPO3 website was hacked.

And when a client complains to the developer of the site, that developer 
may very likely claim that there is a bug in TYPO3 which caused this. He 
can point to several bug reports which are not solved and can claim that 
"TYPO3" knew about the problem and did not fix it. So much for 
responsibility...

> Add the marker solution to andWhere, 
> add stdWrap to where and everything would be fine.

Adding stdWrap to 'where' is superfluous, because andWhere already has 
stdWrap. Adding the marker solution to andWhere is no problem, but is 
pointless because you can use 'where' with markers.
If adding andWhere to the list of fields which support the markers makes 
the patch acceptable then that is no problem for me :-)

> How could such simple statement be implemented without stdWrap?
> 
> andWhere.cObject = COA
> andWhere.cObject {
>    10 = TEXT
>    10.value = AND title = ###title###
>    10.if.isTrue.data = GP:title
>    20 = TEXT
>    20.value = AND name = ###name###
>    20.if.isTrue.data = GP:name
>    30 = TEXT
>    30.value = AND whatever = ###whatever###
>    30.if.isTrue.data = GP:whatever
> }

This is an example of a dynamically constructed query. In fact you're 
building three different queries and this could also be a solution: 
build a COA of CONTENT elements, make 2 and 3 copies of the first and 
only change the andWhere/where parts.
Fortunately there almost always 2-3 ways to do something similar

-- 
Jigal van Hemert.