Lukas Kahwe Smith wrote:
To me some of Ilia's arguements do not make sense. Ext/filter has the
same danger of creating a false sense of security. The arguements that
did make sense to me are about the issue of (un)tainting being directly
tied to the context in which the variable is being used.
This is a problem that many escaping frameworks face. The classic is
defining a javascript variable versus html inside a template. Johannes
mentioned the database versus logging etc.
The only "solution" I was able to think about quickly was to define a
best practice so to teach people to do the untainting as close to the
variable use as possible. Actually it might even be wise to not even
store the untainted version of the variable at all.
$query = "select * FROM foo where bar
='".mysqli_real_escape_string($lala)."'"
echo magic_escaper($lala);
However I guess a lot of people love an ultra layered approach, which
does tend to result in black box code, where nobody knows what is
actually being escaped or not. So I guess this development style is
likely dangerous anyways.
Of cause many of us never go near the raw database calls anyway, since
we are using frameworks that carry out lot of the security checks at a
generic level - so I see little point adding more checks at a level that
major projects do not use anyway?
--
Lester Caine - G8HFL
-----------------------------
L.S.Caine Electronic Services - http://home.lsces.co.uk
Model Engineers Digital Workshop -
http://home.lsces.co.uk/ModelEngineersDigitalWorkshop/
Treasurer - Firebird Foundation Inc. - http://www.firebirdsql.org/index.php
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
