Parsing JSON Is a Minefield (2016)

Re:Parsing JSON Is a Minefield (2016) by maple3142 on Monday October 11, 2021 @10:27AM (#28828687)

I am not sure if parsing XML is better than parsing JSON. Many languages or libraries' XML parser are dangerous by default. You usually need to manually configure your XML parser to be secure from XML-related attacks. Fortunately, some languages and libraries are going to make XML have a securer defaults, this is a good change. IMO, I think XML shouldn't have include many questionable features from security perspective.

[ Parent | on HN ]

Re:Parsing JSON Is a Minefield (2016) by ievans on Monday October 11, 2021 @11:07AM (#28829169)

For those unfamiliar with these attack vectors, there code injection and denial-of-service issues that in previous version of Python, were exploitable by default. Projects like https://pypi.org/project/defusedxml/ were designed to be secure against these issues by default, rather than requiring the library user to opt in.

The defusedxml project has an excellent matrix showing viability of the attack types against various python XML implementations: https://pypi.org/project/defusedxml/#python-xml-libraries

[ Parent | on HN ]

Re:Parsing JSON Is a Minefield (2016) by pdimitar on Monday October 11, 2021 @10:59AM (#28829059)

Agreed, and I like the libraries I saw in the past that deliberately only support a small subset of all XML extensions (sadly now I can't remember the names). Reducing attack surface and increasing sanity in one stroke is a policy that much more open-source software has to adopt.

[ Parent | on HN ]

Re:Parsing JSON Is a Minefield (2016) by Sohcahtoa82 on Monday October 11, 2021 @12:06PM (#28829853)

> Many languages or libraries' XML parser are dangerous by default.

Seriously, XML External Entities is an incredibly dumb feature. To have it enabled by default makes it even worse.

[ Parent | on HN ]

Re:Parsing JSON Is a Minefield (2016) by makeitdouble on Monday October 11, 2021 @11:18AM (#28829316)

You are right, and XML parsers can have a very large attack surface due to the sheer amount of specs to adhere to.

I see XML as better in the expressiveness it has, and more mature out of the box options to validate and transform it. Security and bugs remain an issue, but at the scale it can be used, there is a fighting chance to have experts dealing with the hardening of it all.

Swagger like format definitions are still pretty lax in my option in comparison. Now I wouldn't want to get back to XML land, I just think it occupies a pretty solid niche that is hard to match with anything more simple.

[ Parent | on HN ]

Re:Parsing JSON Is a Minefield (2016) by tannhaeuser on Monday October 11, 2021 @11:26AM (#28829414)

To be fair, XML wasn't intended as a data exchange format but as simplified SGML subset for use as delivery format on the web. While that largely hasn't happened, XML with XSD (sans rarely used feats) remains a strong exchange format for coarsely-grained inter-party traffic such as payment systems, taxes and other public/private data, etc.

I'm guessing the security deficits you mention are XML entity attacks. Well, SGML has CAPACITY ENTLVL in the SGML declaration to limit expansion depth. And a markup authoring or delivery format without entities/text macros is quite useless, even though HTML, when seen as a stand-alone markup language rather than SGML vocabulary, lacks it.

[ Parent | on HN ]

Re:Parsing JSON Is a Minefield (2016) by goodpoint on Monday October 11, 2021 @11:45AM (#28829632)

> XML wasn't intended as a data exchange format but as simplified SGML subset for use as delivery format on the web

You cannot deliver web content without... exchanging data.

And you cannot trust servers not to attack browsers.

[ Parent | on HN ]

Re:Parsing JSON Is a Minefield (2016) by HWR_14 on Monday October 11, 2021 @05:19PM (#28833219)

> And you cannot trust servers not to attack browsers.

Interesting. I normally see it expressed the other way (trusting the server and not the client). Obviously, both are important.

[ Parent | on HN ]

Re:Parsing JSON Is a Minefield (2016) by josefx on Tuesday October 12, 2021 @04:52AM (#28837527)

There was a time when every browser hack made headlines, now it has to involve something big like specter to get even noticed. Browsers and browser based applications still feature heavily at Pwn2Own style competitions, but YOLO lets add more pointless features with bug ridden APIs with every browser update.

[ Parent | on HN ]

Re:Parsing JSON Is a Minefield (2016) by HWR_14 on Tuesday October 12, 2021 @10:50AM (#28840444)

This is true and I remember when they were big headlines. I guess since I'm not in browser development, I'm used to the idea of contacting a known good server from my code, but my known good server being accessible from anyone on the internet.

Both are important, it's just interesting to see it written only from the other point of view.

[ Parent | on HN ]

Re:Parsing JSON Is a Minefield (2016) by tannhaeuser on Tuesday October 12, 2021 @12:47PM (#28841909)

Not wanting to disturb your browser sec discussion, but tbh I don't know what that has to with my GP post. If anything, SGML/XML allows hard validation of document data like basically no other mainstream tech.

[ Parent | on HN ]

Re:Parsing JSON Is a Minefield (2016) by mcv on Monday October 11, 2021 @06:42PM (#28833926)

I guess trust needs to be a two-way street. Even between computers.

[ Parent | on HN ]

Re:Parsing JSON Is a Minefield (2016) by HWR_14 on Monday October 11, 2021 @10:59PM (#28835598)

Or lack-of-trust. Sanitize your inputs, because the other side is always an evil actor.

[ Parent | on HN ]