[Typo3-dev] RFC: magic_quotes and TYPO3

["Kasper Skårhøj"]

>> 1) Always access GET and POST vars by a TYPO3 API function:
>>   1a) t3lib_div::_GET() : will return the current global HTTP_GET_VARS
>(unescaped recursively)
>>   1b) t3lib_div::_POST() : will return the current global HTTP_POST_VARS
>(unescaped recursively)
>>   1c) t3lib_div::_GP($var) : will return a POST or GET var by name $var,
>with priority to POST (unescaped recursively)
>
>So this would mean that all new code (or code converted to use those
>functions) will get unescaped stuff, code still using GPvar() would
>get the escaped values?

Well,

t3lib_div::GPvar() returns an unescaped value IF IT IS A STRING - and not if it is an array UNLESS the second argument is set... The function is fine etc, but I rather like to cut it clean and say ALWAYS unescaped values.

Further there are two important sideeffects of this new strategy apart from a cleaner API:
- For security it means that no-one can get away with inserting values from HTTP_GET_VARS into sql queires directly without addslashed()'ing them first. This is important for SQL injection. Yes, with HTTP_GET_VARS slashes by default this is kind of avoided already - but it is not that transparent and I want to enforce the guideline that values has to be addslashes()'ed right in the process of building the query - thus no-one can be in doubt when doing a code review.

Secondly; Having the addslashes() of content close to the query will also prepare the code better for future DBAL implementation since we will need to substitute all addslashes() functions then anyways...



>
>Fine with me, seems like a nice way to make the transition.
>
>
>> are always unescaped in the global space. That would be more clean
>> and faster.
>
>Right.
>
>> And when this is a reality we can begin to access _GET and _POST
>> directly without the above mentioned API functions (which is again
>> faster).
>
>Well, we could probably stick to using those functions (thus becoming
>independant of some changes that might appear in some distant future,
>like $_GET being renamed to $_WHOOP or something). I think the speed
>loss isn't that bad, and over time (as machines become faster) will
>become more and more insignificant. And caching (and LPE, and probably
>more) will solve speed problems better than switching to accessing
>those variables directly (IMHO).
>


You are absolutely right.
I'm just mentioning that as a possibility. But for now and the next few years, using t3lib_div::_POST and ..._GET and _GP will be required for "valid TYPO3 code"...


- kasper
- kasper

--------------------- o ---------------------
"Mange kokke fordærver maden."
"En fugl i hånden er bedre end ti på taget."