Re: short_open_tag

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