[HN Gopher] SAML Shield: Drop-in protection that works for any s...
___________________________________________________________________
SAML Shield: Drop-in protection that works for any stack
Author : CoffeeOnWrite
Score : 46 points
Date : 2025-08-05 16:05 UTC (6 hours ago)
(HTM) web link (samlshield.com)
(TXT) w3m dump (samlshield.com)
| jelambs wrote:
| thanks for sharing! excited to help make the SAML ecosystem more
| secure. would love to hear any feedback people have!
| mooreds wrote:
| Interesting approach! (Full disclosure, I work for a Stytch
| competitor.)
|
| Some initial thoughts:
|
| * nice to ship an OSS version and I appreciated that the OSS
| limits were clearly called out (only supports node, 1MB limit on
| XML payload size, you have to update it regularly)
|
| * the docs were helpful and it's great they provide a bad saml
| response to test with
| https://samlshield.com/examples/unsigned_saml_response.txt
|
| * critically important to understand that a solution like this
| isn't the whole enchilada (and they declare that a couple of
| places): "important to enforce critical checks such as strict
| Audience and Issuer validation" from
| https://samlshield.com/docs/get-started-open-source So this isn't
| a set -and-forget solution.
|
| * if you use the proxy ( https://samlshield.com/docs/get-started-
| proxy ), it won't be able to check encrypted SAML assertions (how
| could it, it won't have the key)
|
| * you should definitely read the security coverage page to see
| what it helps with and what it does not:
| https://samlshield.com/docs/security-coverage
|
| * replay attacks better protected against by using unique
| identifiers and invalidating when you've seen one before (they
| just check for time based validity). But I get that's hard to do
| with a proxy!
|
| * great to see a transparent pricing page!
| https://samlshield.com/pricing
|
| I'm all for improving security. SAML unfortunately is going to be
| around for a long long time and the protocol won't see any
| updates. This seems like a good step forward in examining SAML
| requests/responses, even if there are limits to the proxy
| approach.
| danthom wrote:
| Thanks for the thoughtful feedback! (Full disclosure, I work at
| Stytch and led the launch of SAML Shield.)
|
| > the docs were helpful and it's great they provide a bad saml
| response to test with
| https://samlshield.com/examples/unsigned_saml_response.txt
|
| Glad you noticed that! Including a bad SAML response was a
| small detail I hoped would make it easier for developers to
| validate their integration,
|
| > * if you use the proxy ( https://samlshield.com/docs/get-
| started-proxy ), it won't be able to check encrypted SAML
| assertions (how could it, it won't have the key)
|
| Absolutely and that's a key limitation of the proxy model.
| Since the proxy doesn't have the decryption keys, encrypted
| assertions need to be handled inside the app. I just updated
| the security coverage page to call that out explicitly!
|
| > * replay attacks better protected against by using unique
| identifiers and invalidating when you've seen one before (they
| just check for time based validity). But I get that's hard to
| do with a proxy!
|
| Totally fair. Today, we rely on timestamp-based validity
| checks, but we know that doesn't fully mitigate replay risk.
| For the managed version, we plan to track assertion IDs server-
| side to detect replays. It's trickier to solve for the OSS
| version since we don't manage state, but we're exploring
| lightweight approaches there too.
|
| Appreciate your support and agree, SAML isn't going anywhere
| anytime soon. Our hope is that SAML Shield makes it easier for
| teams to secure their stack without having to become SAML
| experts or wait on upstream patches!
| mooreds wrote:
| Cool, cool! Thanks for the thoughtful response. Will be
| interested to see your replay approach when you release it.
| We implemented it but have a different set of constraints
| than your service, of course.
|
| If you want to look at another SAML implementation (perhaps
| to gather additional CVEs or for testing), we've open sourced
| our SAML bindings for Java:
| https://github.com/FusionAuth/fusionauth-samlv2
| bklyn11201 wrote:
| Any opinions you can share re opensaml for Java?
| mooreds wrote:
| I'm not super close to that part of the code, so I don't
| have any opinions. I'll ask the team if they do.
| dudeinjapan wrote:
| RubySaml contributor here. What I'd like to see is a public repo
| of known SAML exploit test cases that every lib can validate
| itself against.
| securesaml wrote:
| I am working on an SAML Attacker (that basically tests web apps
| against all known SAML exploits). It includes all the test
| cases.
|
| I can share you the repository if you want to integrate it in
| RubySAML (or any other library). Email me
| [alex]@[securesaml.com] (without the [ ])
| aleksejs wrote:
| This is neat! We're building something similar at work, but
| instead of hand-rolling specific checks (like "first signature
| must be direct child of Response" in samlshield) we're
| fingerprinting the structure of the SAML response and checking if
| it matches what we've previously seen from that IdP. We figured
| that would be more likely to catch any exploitation attempts we
| didn't anticipate while giving us some flexibility to not have to
| hardcode specific IdP behaviors. Having specific hard checks
| seems really valuable too, though, especially for applications
| that might not have many SAML responses to backtest on. And kudos
| for sharing a great corpus of test cases!
|
| One thing that would worry me when deploying this in the Proxy
| mode is that you'll likely end up with two different XML parsers
| in play: xmldom in samlshield and then whatever the actual
| application is using. As we saw with CVE-2025-25292, it may be
| possible to exploit different parser behavior to construct a
| document that will be interpreted differently between the two
| applications, potentially bypassing the checks in samlshield.
___________________________________________________________________
(page generated 2025-08-05 23:01 UTC)