Greg Beaver:
[ Charset ISO-8859-1 unsupported, converting... ]
> (Wietse Venema) wrote:
> > Rasmus Lerdorf:
> >>> I don't think it's unreasonable to require scripts outputting content
> >>> other than HTML to include a line that modifies the default behaviour.
> >>> Surely the benefits far outweigh that cost.
> >> That's already there. They set the content-type. The problem becomes
> >> when they set it vs. when output goes out. It's also very common to
> >> turn on output buffering and buffer a bunch of stuff and then set the
> >> content-type just before flushing the buffer.
> >
> > That practice would be incompatible with taint checks. I suppose
> > having to specify the type first is not a burden for the application,
> > because the application knows what output it is going to produce,
> > before it produces it.
> >
> > Taint policy is applied to echo (and print, etc.) arguments. It
> > can't be applied to the contents of the output buffer, because that
> > would be prohibitively expensive. One would need to record that
> > byte A came from function B argument C at file D line E, and that
> > byte A had a particular set of taint labels.
>
> Hi,
>
> Would input from external files be considered tainted? In other words,
> a common approach is to create a cached page, write it to disk, and then
> readfile() it. In other words, is TC_SELF applied to stream data?
Not by default, but this is configurable.
Right now only data from the web is treated as hostile. That is,
not only must it be escaped when used as HTM/shell/SQL, it also
can't be used in file names or network destinations without
requiring an extra step that declares it as safe for such use.
This prevents not only HTML/shell/SQL injection attacks, but
also control hijacking with eval(). include(), etc.
External data that does NOT come from the web can be used in file
names or networks destinations without requiring a step to declare
it safe, but it still needs to be escaped when used as HTML/shell/SQL.
The latter is just to avoid surprising errors when a legitimate
user name like O'Reilly pops up in the data. This also prevents
stored-XSS exploits.
The current taint bits and marking policies are a first step to
find out what will be the most useful. I expect that these details
will change.
I'll put out some source code early next week.
Wietse
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
