Edward Z. Yang wrote:
Rasmus Lerdorf wrote:
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, I'm sure these techniques work very well in practice. However,
it's important to note that it's still an optimization, a step down from
an "ideal" standard which would involve keeping raw data in the
database. In theory, the data in its purest form, with no extraneous
escaping, would be stored. In practice, most data will be used in a web
context and thus, as you note, escaping it as ' is perfectly acceptable.
I've always advocated storing both the pure data and the escaped version
(in a kind of cache) in the database, because if you store just the
escaped version you don't have any easy way (besides decoding) to get
the raw version back. Of course, this doubles the storage requirement.
Sure, although if you are going to store the raw, I think it is
pointless to store the escaped version. But this is not the point. I
am not advocating storing it either way, I am simply saying that by
default you should never work with raw user data. You should limit the
scope in your code where raw data is used. So if you need to store the
raw data, fetch it just before storing it or just before sending a query
to the backend. Everywhere else that same piece of data is a very
strictly escaped piece of information. If you forget to fetch the raw
or if you forget to re-filter it through the appropriate filter for
whatever backend, then chances are your application won't work, or the
user will see strange output, but at least you will be failing safe,
instead of failing insecure.
There are so many places where one missed filter has been the downfall
of a web app. Think of an age or state select dropdown. It's very easy
to forget to filter such an innocent-looking field in a web app, and
even a very strict default filter isn't likely to mess up a 2-letter
state name or a 2-digit number so running such an app with a couple of
missing filters isn't going to affect it at all. It will simply make
something that wasn't safe before, safe.
By the way, if anybody on the list has a web app they'd like me to
check, you have probably heard of the tool I wrote for this purpose
called Scanmus. If you send me a note privately, I'd be happy to scan
it for you, if for nothing else, to illustrate just how many web apps
written by otherwise competent developers are insecure.
-Rasmus
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
