Improve security against maliciously constructed data

Problem xmltodict is Expat-based, which is not secure against maliciously constructed data (it’s even mentioned on the package docs: https://docs.python.org/3.4/library/pyexpat.html).

Possible Solution There is a project that improves Expat security: defusedexpat (PyPI: https://pypi.python.org/pypi/defusedexpat/ Bitbucket: https://bitbucket.org/tiran/defusedexpat). Using it instead of regular Expat could resolve security issues.

Potential problems with implementation At this point I haven’t researched compatibility issues that may arise if xmltodict were to use defusedexpat. Will do this in the next few days.

More information https://docs.python.org/3.4/library/xml.html https://pypi.python.org/pypi/defusedxml/ https://pypi.python.org/pypi/defusedexpat/ https://en.wikipedia.org/wiki/Billion_laughs https://msdn.microsoft.com/en-us/magazine/ee335713.aspx

Let me know if there’s interest in solving this problem. Is somebody interested in forking the repo and implementing the solution or should I do this (I won’t be able to work on this until next week)?

[iyn]

Sadly, I still didn’t hear back from the defusedexpat author/maintainer. And it seems that he didn’t enable issues on Bitbucket.

I would suggest, that semi-solution could be just adding more visible info about defusedexpat in README and a note that it probably won’t work on Python 3.4 for some time.

[iyn]

@martinblech Yeah, I think that would be good solution. Although I have a problem compiling defusedexpat for Python 3.4 (it works after commenting out some parts of the code, but it’s ‘hacky’ and not a proper way) - I contacted the author with the question if he plans to officially support Python 3.4.

So, I’m in favor for using defusedexpat as a default, but I’d wait for Python 3.4 support.