[TYPO3-dev] Proposal: Sanitize GET/POST parameters
Helmut Hummel
helmut at typo3.org
Thu Jul 8 22:56:59 CEST 2010
Hi Reinhard,
thanks for bringing this into discussion.
On 06.07.10 17:04, Dmitry Dulepov wrote:
>
> Reinhard Führicht wrote:
>> TYPO3 doesn't sanitize the values submitted in GET or POST and leaves it
>> to the extension authors or the writers of TypoScript to care about XSS
>> and SQLI.
>
> I recognize the danger but I think that leaving it up to developers what to
> do with data is a good idea. We'd better educate the developers instead of
> trying to make workarounds. Just an opinion...
I agree with Dmitry here.
The problem is that you cannot do generic "sanitizing" for GET or POST
vars. Here's why:
A basic security rule for untrusted data is: FIEO (Filter/validate
Input, Escape Output).
For your application to be secure, you must by all means do both.
The problem is, that escaping has to be done specifically for the target.
So if you e.g. "sanitize" a GET value by applying htmlspecialchars(),
using this value in a HTML context might be fine, using it in a SQL
context leaves your application still vulnerable. Besides that you will
have something like "My friend & me" in the database.
The other way around, if you "sanitize" a GET value with fullQuoteStr(),
using it for the database might be secure, but using it in a HTML
context makes your application susceptible to XSS. Besides that, if
you'd output it as HTML you'd get something like "'O\'Reilly'"; not so nice.
But if we clearly distinguish between validation, filtering and
escaping, we could probably improve the current situation.
In extbase it is possible to define validation rules for each property
of an object. Probably we could use this validation framework to be able
to define validation rules for arbitrary GET or POST parameters.
Same applies for filtering.
While beeing a nice feature (and it would be quite secure e.g. for
integer values), this would of course have an impact on performance and
we must decide if it is worth to do so.
Because this would still not be enough. Escaping is still missing.
With the current flexibility of TypoScript and the need of proper
escaping depending on the context, this might be a difficult task:
lib.test = TEXT
lib.test.dataWrap = foo bar | {GP:test}
How should the TEXT object "know", if the output it produces is used as
HTML output or as part of a SQL query in a TypoScript select function?
So e.g. htmlSpecialChars = 1 as default would be wrong.
Last but not least, a "positive security model" should always be used
(whitelist approach: deny all, allow some). This means that using a
filter that removes "bad words", might leave your application to be
insecure if you do not escape the value properly afterwards (see above).
To sum it up. I would welcome any improvements in regard of TypoScript
or Extensions beeing "secure by default", but this is at least a
difficult if not an impossible task.
Regards Helmut
More information about the TYPO3-dev
mailing list