On Wed, Sep 23, 2009 at 8:23 PM, Fabio Forno <fabio.fo...@gmail.com> wrote:
> AFAIK, since features must be sorted, the only thing you can replace > with an identity is the first feature with the last identity. If we > insert a dummy feature or identity between them the problem could be > avoided (besides possible implementation problems, but a dummy feature > preceding all the others doesn't seem dangerous) > That hack slightly reduces the attack surface, but does not eliminate it. If any of the <identity/> element's attributes have a '/' in them, they are open to attack despite the dummy feature. The thread on the security ML talks about several related attacks, of which this one is probably the most minor. On Wed, Sep 23, 2009 at 8:28 PM, Peter Saint-Andre <stpe...@stpeter.im>wrote: > On 9/23/09 8:05 AM, Waqas Hussain wrote: > > > Sure, but I see no point in implementations actually _failing_ on > > receiving them. If my code works correctly with valid implementations, > > and my code can also work with some broken implementations, I don't see > > much reason to add extra validation code just to stop working with > > broken implementations (unless Prosody is running in strict mode of > > course ;) ). > > This is a MUST on generation of service discovery identities in an IQ > result. There is no error to return on receipt of an IQ result. Yes, of course. I was referring to caching the verification string. It seems safe enough to cache even if the category and type are empty. -- Waqas Hussain
