Stefan Walk wrote:
Rasmus Lerdorf schrieb:
It is, but it is magic_quotes done right. You apply a really strict
filter that makes your data safe for display and your backend by
default. The only place you can reliably do this this is at the point
the data enters your system. Once it is in, having to remember to
apply a filter before you use the data will never work. You might
remember to do it 99.99% of the time, but that doesn't help you and
you might as well not do it at all. A bit like a condom with just one
little hole.
-Rasmus
No, it's not "done right". To work for all cases, your "default filter"
would basically have to return an empty string all the time (if you say
"nonsense", does the default filter strip "From" from the start of a
line so you can put it into an mbox?). And you don't need do do that to
be safe, because you don't have to remember to apply a filter, you use
the subsystem that needs the escaped data to escape the data itself. So,
when passing an arg to a MySQL query, it gets escaped the right way (by
using pepared statements, formatted query strings ... hundreds of
possibilities). If you pass data to the "HTML output subsection", it
gets escaped for use in HTML. Cause this is done implicitely, you never
ever call an escaping function yourself, so there is no way to forget it.
But you know which backends you use. I am not suggesting that PHP can
supply a default filter that works for everyone. But I am suggesting
that you can supply a default filter that works for the backends you
use. The vast majority of people need data to be safe from HTML and
MySQL/PostgreSQL. So having a default filter that makes data safe for
these uses and throw in Shell, CSS and Javascript as well, and you have
a really powerful default filter. Yes, there will always be other
subsystems out there that needs other filtering, in which case you
extend your default filter to cover those, or you wall off those
subsystems and have a secondary filter layer.
The alternative of relying on the developer remembering to filter simply
doesn't work. Wietse's taint mode is another approach, but it has
performance implications.
The data firewall approach is what I put in place at Yahoo 5+ years ago
now. We have hundreds of applications written by thousands of
developers and it works. Yes, there are still security issues from time
to time, but they end up being logical flow issues that no amount of
filtering would fix, or they stem from people applying the wrong filters
in the wrong situations which again would happen under any system. What
we don't see are security problems caused by developers forgetting to
filter a specific bit of user data.
The other thing this gives us is the ability to run 3rd-party untrusted
apps. You only need to find the 2 or 3 places where the app needs
something other than the default filtered data and even the most
insecure app can be run with some semblance of security.
-Rasmus
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
