Most active commenters
  • bawolff(3)
  • thayne(3)

←back to thread

312 points campuscodi | 16 comments | | HN request time: 0.443s | source | bottom
1. oncallthrow ◴[] No.43374582[source]
XML is to authentication bypasses what C is to buffer overflow attacks
replies(4): >>43374583 #>>43374813 #>>43375202 #>>43375808 #
2. ◴[] No.43374583[source]
3. dietr1ch ◴[] No.43374813[source]
Sad that XML has too many features for an otherwise somewhat nice, but verbose markup language.
replies(2): >>43374910 #>>43374941 #
4. treve ◴[] No.43374910[source]
Feature are kind of a negative for security. Imagine if yaml was used!
replies(1): >>43374958 #
5. bawolff ◴[] No.43374941[source]
Some of it isn't explicitly XML's fault (although it doesn't help). SAML and especially XMLSignature are terrible standards even in ways that dont involve xml.
6. alexchamberlain ◴[] No.43374958{3}[source]
I think there is a "safe" subset of both XML and YAML that 80% of people actually use.
replies(2): >>43374973 #>>43375111 #
7. bawolff ◴[] No.43374973{4}[source]
From a security perspective that's kind of useless, as your concern is not what the "good" people do, it's what the "bad" people do.
replies(1): >>43375093 #
8. alexchamberlain ◴[] No.43375093{5}[source]
Well, you can define such a subset and write or configure parsers to only use that; I've seen both XML and YAML libraries do just that, by disabling remote file loading or arbitrary code execution for example.
replies(1): >>43375465 #
9. Muromec ◴[] No.43375111{4}[source]
which is exactly the problem. if you have two parsers of the same format in a security context that show slightly different behavior (maybe in the rest 20% or maybe not) it's often enough.
10. pvg ◴[] No.43375202[source]
You're selling XML short here, it had its own share of straight up RCEs too.
11. bawolff ◴[] No.43375465{6}[source]
Disabling xml remote entities and billion laughs is a given.

In the context of saml that's hardly the least of it. Lots of the problems are things like allowing comments to sort of change the meaning of the document, allowing signatures to sign only part of the document. Allowing multiple signatures to sign different parts of the document, etc.

12. thayne ◴[] No.43375808[source]
XML could really benefit from a standardized subset that cuts out all the unnecessary features and security footguns.
replies(2): >>43376649 #>>43380061 #
13. Nextgrid ◴[] No.43376649[source]
I find that the "unnecessary features" and footguns are what makes XML, well, XML. I guess there must be some legitimate usage of those, or at least was back in the day. If you strip them out, you'd end up with a JSON-like (so you may as well use JSON).
replies(2): >>43376692 #>>43377295 #
14. dralley ◴[] No.43376692{3}[source]
Or something like RON

https://github.com/ron-rs/ron

15. thayne ◴[] No.43377295{3}[source]
No, you would have an extensible markup language. And json is not a good fit for markup.

Now, xml has also been used for a lot of things where a hierarchical format like json would have worked better than a markup format, of which SAML would be a good example. But there are also cases where a markup format makes more sense, like svg or docbook, or odf.

16. thayne ◴[] No.43380061[source]
GMarkup[1] is pretty close to what I had in mind. If only it was more prevalent and had an agreed upon standard.

[1]: https://docs.gtk.org/glib/markup.html