> -----Original Message----- > From: [email protected] [mailto:[email protected]] On > Behalf Of Peter Saint-Andre > Sent: 24 June 2009 12:24 AM > To: XMPP Security > Subject: [Security] upcoming DEFCON talk > > I take a look at how those issues > play out in IM clients and open source servers.
Do we have any recommendations on how to avoid things like this? A few things that come to mind (given that stanzas SHOULD NOT be more than 64kb IIRC). All of these should be configurable and removable (XML/DB configuration). They only deal with the XMPP side of things (e.g. excluding Jingle RTP servers etc.) Memory consumption: - QNames should not exceed e.g. 64 chars - Attribute values should not exceed e.g. 1024 chars - Element text (and CDATA if supported by the parser) should not exceed e.g. 30720 chars - PI (if supported) should not exceed 1024 chars - DOCTYPE (if supported) should not exceed 1024 chars - Node nesting depth should not exceed e.g. 100 nodes 'Strobing' the server with excessive stanzas: - Up/down speed may only exceed e.g. 10kbps for e.g. 10 seconds. - Client may request a grace period, and can only continue with high bandwidth usage when the server sends the 'go ahead' stanza. Undefined behaviour: - Server should immediately disconnect client if the document root element is not recognised. General DOS: - Client has e.g. 10 seconds grace between individual stream features. - A single account may not have more than e.g. 10 active connections. - No more than e.g. 3 S2S connections can be made from one source (do not ban server, rather just immediately close any further connections). Any other ideas? > > Peter > > - -- > Peter Saint-Andre > https://stpeter.im/ Jonathan http://jonathan.dickinsons.co.za/blog
