On Wed, Aug 31, 2011 at 1:41 AM, Peter Saint-Andre <stpe...@stpeter.im> wrote: > Replying to myself before I reply to the latest message from Waqas. :) > > On 8/30/11 12:37 PM, Peter Saint-Andre wrote: > >> So far, two of the attacks (#3 and #4) that you have described (via >> examples only) depend on violations of the XML spec and XEP-0030. >> >> Another of the attacks (#1) depends on converting the literal string >> "<" to "<", which we've said for years now is incorrect. >
Err, while we may have said '<' is bad in disco response text and attribute values, you have phrased it wrong here. XML attribute node and text node values are the unescaped '<', not the escaped '<' which is just the serialization of the actual value. Past the XML parser, all code sees '<'. What you are saying is it be re-escaped at that level. > Can we agree that attacks #1, #3, and #4 are easily overcome by proper > handling of inputs? > Those examples, yes. The attack, no. Read my response to your other email for a description of the general attack. Presented below are variations of these attacks which the new 'proper handling of inputs' doesn't catch. Let's assume we have entirely disallowed '<'. And we validate <identity/> attributes to be valid. <identity category='a' type='b' name='c'/> is the same as <feature var='a/b//c'/> <feature var='http://jabber.org/a/b/c'/> is the same as <identity category='http://jabber.org' type='a' xml:lang='b' name='c'/> <identity category='http://jabber.org' type='a' xml:lang='b' name='c/d'/> is the same as <identity category='http://jabber.org' type='a/b' xml:lang='c' name='d'/> >> Attack #2 can be mitigated by forbidding forms without fields in >> XEP-0068 and XEP-0128. > > Regarding attack #2, one approach, which some folks on the formerly evil > former Jabber team in Denver just discussed IRL, is to simply ban > XEP-0128 forms from computation of the caps hash. The only legitimate > use of XEP-0128 that anyone has ever tried to standardize was XEP-0232, > but we were never able to reach consensus on that spec and it has been > in the Deferred state for over two years. This is a fundamental change in the algorithm. By fundamental change I mean entities using the older and newer versions will not be able to interoperate. This is a new algorithm pretending to be the old one. There are probably a lot of deployed clients which include disco extensions in their disco results. Now I have to ask, what is the motivation for going this far in keeping the same XEP that you are willing to update the algorithm in a non-backwards compatible way? It doesn't seem to be to not force developers to write more code. All these fixes are going to lead to more code. Next thing we know, we'll be validating xml:lang is following the large BNF specified in RFC 4646. It doesn't seem to be interop, or you wouldn't suggest this change. What is it then? > Peter -- Waqas Hussain
