Stefan Walk wrote:
Rasmus Lerdorf schrieb:
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.
As I said, when the backend does the escaping, you don't have to
remember it.
filtering would fix, or they stem from people applying the wrong
filters in the wrong situations which again would happen under any
system. What
If the backend picked the escaping mechanism, *that* wouldn't happen (if
the backend isn't buggy, but that can happen for any way)
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.
"Some" is the right word here. That insecure app could leak information
from your server, write or read data to/from locations it shouldn't,
etc. Also, I don't think it would be just 2 or 3 places. It'll be more
like every point where it's real user input (and not form ids, hidden
values etc), because then you have to expect almost any char that your
filter has to strip to be safe - Mr. O'Reilly won't be amused if he's
called OReilly, O''Reilly, O'Reilly or O\'Reilly.
Well, I actually have years of experience taking apps and making them
run under my strict default filter. And it tends to not be very many
changes, if any at all. In the O'Reilly case it gets changed to
O'Reilly which for a pure web app is fine. If all input
consistently gets changed the same way then you can store O'Reilly
in the backend and a search will still find it since the search query
itself will be encoded the same way. If you have non web tools working
with the same backend data, then you may have a requirement to store it
raw, in which case you'd need to poke a hole in your data firewall.
-Rasmus
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
