Comment by jrpelkonen
Comment by jrpelkonen a day ago
I know next to nothing about .net, but this seems like the classic “you’re holding it wrong” excuse to me. If there’s a way to call an api the wrong way and the right way, and both appear to work, large number of developers will implement the insecure api. Why can’t the incorrect api be removed? I understand there’s pressure to support old client code but vulnerabilities should trump backwards compatibility.
The incorrect api would be using GetXml and looking at the raw XmlElement and using select nodes or something vs using the GetIdElement on the SignedXML object itself, its not going to prevent you from looking at the xml document directly and do something incorrect but it gives you a correct helper method right next to CheckSignature to do the right thing.
I mean at some point you do have to understand the difference between xml and a specific schema of it and how its used in SAML, its not like xml elements are required to have a unique id attribute.
This isn't something you would call directly anyway unless you were writing your own SAML client, which isn't that hard but there are existing ones, here is a simple one that works well:
https://github.com/jitbit/AspNetSaml