Re: XML_Feed_Parser and HTML security

I'd personally add an argument boolean at the end of the affected methods. $object->someMethod($args... , $safe) function someMethod($args...., $safe = null) { if ($safe === null) { trigger_error(E_WARNING, __CLASS__.'::'.__FUNCTION__.' You should specify if you want the data treated as safe or not') } - in much the same way that PHP treats non-critical, but missing argument.. Regards Alan James Stewart wrote: > There has been quite a bit of discussion in the syndication community > lately about potential security vulnerabilities in feed parsers and > aggregators caused by the HTML content of some feeds. Sam Ruby is one > of those who has blogged about it: > > > http://www.intertwingly.net/blog/2006/08/09/Attack-Delivery-TestSuite > > As I'm preparing the first stable release of XML_Feed_Parser I'd > appreciate some input on how proactive that package should be in > 'cleaning' HTML. At present it simply returns any HTML delivered in > the feed and the expectation is that the user of the package will > escape any output they get, but I'm wondering if it should be more > proactive, even at the risk of a slight BC break. > > What I'm considering is an extra parameter to all of the methods that > could potentially return infected data. By default it would process > the HTML to remove potential exploits (and hence probably all > javascript) but if a user passed false it would return the content as > found in the feed. > > Alternatively that could be optional, or it could be left out entirely > and kept back for a 1.1 release. Whichever way, I want there to be a > clear statement about security in the docs. > > On a related note, I'd like to use HTML_Safe to do any parsing. Is > there any word on when we can expect a stable release of that package? > > thanks. James. > > --PEAR Development Mailing List (http://pear.php.net/) > To unsubscribe, visit: http://www.php.net/unsub.php >