News for hackers. Stuff that matters.
Re:Sign in as anyone: Bypassing SAML SSO authentication with... by tptacek on Saturday March 15, 2025 @05:11PM (#43375191)
SAML (more broadly XML-DSIG) is literally the worst security protocol in common use. I think you should generally be taking whatever hits you need to take to transition from it to OAuth. Certainly, I would refuse to bring a new product to market that relied on it. It's incredibly dangerous. Unless there's some breakthrough in practical formal verification, I can't imagine that this will be the last or the worst DSIG vulnerability.
Re:Sign in as anyone: Bypassing SAML SSO authentication with... by nimish on Saturday March 15, 2025 @07:30PM (#43375862)
One day I will write an essay on all of the incredibly stupid things XML DSig does, and that's not even touching the cryptography. It's peak enterprise software brain.

Someone should go deep on the mailing list and standards body horrors of WS-* and OASIS/XACML and all that crap

Re:Sign in as anyone: Bypassing SAML SSO authentication with... by pushkar2911 on Sunday March 16, 2025 @12:38PM (#43380286)
Please write about this. I would love to read it.
Re:Sign in as anyone: Bypassing SAML SSO authentication with... by shellcromancer on Saturday March 15, 2025 @05:22PM (#43375239)
Security Cryptography Whatever’s take on this week SAML non-sense will be fun.
Re:Sign in as anyone: Bypassing SAML SSO authentication with... by tptacek on Saturday March 15, 2025 @05:28PM (#43375276)
Honestly, hadn't thought of it, but of course we should do that. Thanks!
Re:Sign in as anyone: Bypassing SAML SSO authentication with... by janderson215 on Saturday March 15, 2025 @08:01PM (#43376014)
I’d sub to infosec rant podcasts. $5/mo Patreon sub for a non-vtuber version.
Re:Sign in as anyone: Bypassing SAML SSO authentication with... by akdor1154 on Saturday March 15, 2025 @09:43PM (#43376397)
My (possibly misunderstood to the point of misphrasing) understanding, is that SAML still has the point-of-difference that your sso provider can cancel a session. Is that right?
Re:Sign in as anyone: Bypassing SAML SSO authentication with... by recursive on Sunday March 16, 2025 @12:14AM (#43376899)
There's an optional feature in the spec I think. But in my very limited experience, it is never implemented or working correctly.
Re:Sign in as anyone: Bypassing SAML SSO authentication with... by p_ing on Sunday March 16, 2025 @09:39AM (#43379009)
Microsoft implements this in Azure/M365.
Re:Sign in as anyone: Bypassing SAML SSO authentication with... by akerl_ on Saturday March 15, 2025 @11:18PM (#43376735)
Can it? In many SAML setups, there's not direct network interaction between the IDP and Service, other than at most sharing metadata via URL.
Re:Sign in as anyone: Bypassing SAML SSO authentication with... by Nextgrid on Saturday March 15, 2025 @10:51PM (#43376637)
OIDC has out-of-band backchannel logout.
Re:Sign in as anyone: Bypassing SAML SSO authentication with... by securesaml on Saturday March 15, 2025 @10:27PM (#43376552)
Agree that XML signatures is terrible. The main problem with XML signatures (and many message signatures) is that it makes it impossible to know which bytes are cryptographically authenticated.

For example, most libraries do something like: ``` valid = validate_xml_signature(xml_message, key) if valid: parse(xml_message) # note xml_message was not crytographically authenticated ```

It should be: ``` verified_bytes = validate_xml_signature(xml_message, key) def validate_xml_signature(message, key): signed_bytes, authenticated_tag = parse_signature(message) # cryptographic proof of signed_bytes if key.verify(signed_bytes, authenticated_tag): return signed_bytes

parse(verified_bytes) # parse into whatever you want i.e. SAML Assertion ```

Now this method is foolproof as you only use authenticated data. This is a rough description of how formal verification would apply to XML Signatures. Of course it wouldn't prevent processing vulnerabilities, say XML parsing (XXE) or XML signatures transforms (XSLT) which has its own set of footguns. Or vulnerabilities inside cryptographic primitives.

You do mention that companies should switch to something like OIDC/OAuth. Many large companies just don't have the resources to start switching when the current system just works, say a old company in healthcare. So they are stuck with a bad standard like SAML or XML signatures.

That's why I am securing libraries like ruby-saml to ensure that there are no more XML signature vulnerabilities. During the patch for ruby-saml, we redesigned the library to ensure that there are no more xml signature vulnerabilities https://github.com/SAML-Toolkits/ruby-saml/commit/e9c1cdbd0f... https://github.com/SAML-Toolkits/ruby-saml/blob/fbbedc978300...

I am trying to apply this to all the other libraries. The problem is that we are not getting funding at all. Ruby-SAML's maintainer never got any new sponsorships, despite asking for it: https://github.com/sponsors/SAML-Toolkits It disincentives any security redesigns like this: it just takes too long, and quite thankless.

If you want to join our efforts, feel free to contact me at secure[@]securesaml[.]com