how to use with defusedxml builders

[graingert]

defusedxml is a library that provides safe defaults for xml library configuration.

It would be useful to include documentation on how to use html5lib with a parser that has been configured with defusedxml.

Also is this even necessary? Does html5lib already take the precautions listed in defusedxml?

see also mozilla/bleach#158

[gsnedders]

Also is this even necessary? Does html5lib already take the precautions listed in defusedxml?

They simply aren't applicable to HTML as a language.

The vectors defusedxml deals with:

• billion laughs / exponential entity expansion: relies on <!ENTITY…> which doesn't exist in HTML
• quadratic blowup entity expansion: relies on <!ENTITY…> which doesn't exist in HTML
• external entity expansion (remote): relies on <!ENTITY…> which doesn't exist in HTML
• external entity expansion (local file): relies on <!ENTITY…> which doesn't exist in HTML
• DTD retrieval: HTML has no notion of retrieving a DTD (<!DOCTYPE…> is essentially a talisman use to select quirks mode and nothing else).

So none of those apply.

The "Other things to consider" include:

• attribute blowup / hash collision attack: this is possibly an issue, though should be fine provided you have hash randomisation turned on (and you need that to defend against similar HTTP Header attacks if you're using this in a web context anyway) which it is by default in 3.3 and above (it exists as an option from 2.6.8, 2.7.3, 3.2.3 if I'm not mistaken)
• decompression bomb: this is obviously an issue for anything that takes compressed input, but html5lib doesn't directly deal with it (though you obviously can pass in a gzip.GzipFile object or similar).
• Processing Instruction: they're just comments in HTML, so don't apply
• Other DTD features: again doesn't apply (see above)
• XPath: if you're running XPath on any arbitrary tree you can end up with pretty bad (unbounded?) performance, especially if the user controls both the tree and the XPath query, so any XPath implementation has this limitation, but we don't have an XPath implementation ourselves
• XPath injection attacks: Any XPath implementation needs to deal with this, but again we don't have an impl
• XInclude: doesn't exist in HTML
• XMLSchema location: xsi:schemaLocation doesn't exist in HTML
• XSL Transformation: as that says, if you're running XSLT on a tree be careful because it's Turing complete.

So essentially the only things that can affect HTML are hash collision attacks (needs to be defeated by the Python implementation, which it is in CPython), decompression bombs (because they can affect anything using compression), and XPath and XSLT which are really matters that you need to worry about algorithmic complexity with any code processing an arbitrary tree.

[gsnedders]

So no, there's nothing to do here. Maybe we should document this somewhere.