4 ms·

XML is to authentication bypasses what C is to buffer overflow attacks

by oncallthrow 2y ago

deleted 2y ago
[deleted]
dietr1ch 2y ago
Sad that XML has too many features for an otherwise somewhat nice, but verbose markup language.
- treve 2y ago
  Feature are kind of a negative for security. Imagine if yaml was used!
  - alexchamberlain 2y ago
    I think there is a "safe" subset of both XML and YAML that 80% of people actually use.
    - bawolff 2y ago
      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.
      - alexchamberlain 2y ago
        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.
        bawolff 2y ago
        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.
    - Muromec 2y ago
      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.
- bawolff 2y ago
  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.
pvg 2y ago
You're selling XML short here, it had its own share of straight up RCEs too.
thayne 2y ago
XML could really benefit from a standardized subset that cuts out all the unnecessary features and security footguns.
- Nextgrid 2y ago
  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).
  - dralley 2y ago
    Or something like RON https://github.com/ron-rs/ron https://github.com/ron-rs/ron
  - thayne 2y ago
    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.
- thayne 2y ago
  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 https://docs.gtk.org/glib/markup.html

XML is to authentication bypasses what C is to buffer overflow attacks

deleted 2y ago

[deleted]

dietr1ch 2y ago

Sad that XML has too many features for an otherwise somewhat nice, but verbose markup language.

treve 2y ago
Feature are kind of a negative for security. Imagine if yaml was used!
- alexchamberlain 2y ago
  I think there is a "safe" subset of both XML and YAML that 80% of people actually use.
  - bawolff 2y ago
    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.
    - alexchamberlain 2y ago
      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.
      - bawolff 2y ago
        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.
  - Muromec 2y ago
    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.
bawolff 2y ago
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.

pvg 2y ago

You're selling XML short here, it had its own share of straight up RCEs too.

thayne 2y ago

XML could really benefit from a standardized subset that cuts out all the unnecessary features and security footguns.

Nextgrid 2y ago
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).
- dralley 2y ago
  Or something like RON https://github.com/ron-rs/ron https://github.com/ron-rs/ron
- thayne 2y ago
  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.
thayne 2y ago
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 https://docs.gtk.org/glib/markup.html