Post

Filippo Valsorda
@filippo.abyssdomain.expert

encoding/xml is not a place of honor, and I am still hunting for someone to pay out of Geomys to make a SAML-oriented parser that doesn't suck. For encoding/json, sounds like /v2 fixes most of them, leaving json:"-,…" and json:"omitempty" for which I opened github.com/dominikh/go-...

github.comstaticcheck: detect unlikely encoding field names · Issue #1655 · dominikh/go-toolshttps://blog.trailofbits.com/2025/06/17/unexpected-security-footguns-in-gos-parsers/ reports that they found a number of mistakes like type User struct { Username string `json:"username,omitempty"`...
ahacker1.bsky.social
@ahacker1.bsky.social

I don't think that writing a new parser will ensure that SAML will be secure. The right approach is to refactor libraries to use only the signed contents, like you mentioned previously: bsky.app/profile/fili... bsky.app/profile/fili...

github.comRefactor to help eliminate potential vulnerabilities: · russellhaering/goxmldsig@e1c8a5b- Obtain references from only the verified signed info bytes - Return the actual bytes that were verified, but reparsed into a new etree document
Filippo Valsorda@filippo.abyssdomain.expert

This writeup on a signature bypass vulnerability does a good job of calling out some design red flags, but I want to point out a major one. If you need to extract a signature out of a message, you MUST NEVER then operate on the original message. Many applications and protocols get this wrong.

wiz.ioA Signature Verification Bypass in Nuclei (CVE-2024-43405) | Wiz BlogWiz's engineering team discovered a high-severity signature verification bypass in Nuclei which could potentially lead to arbitrary code execution.
rst.bsky.social
@rst.bsky.social

SAML certainly does have a lot of footguns, and I'd love an alternative. But what should people who need SSO that crosses organizational boundaries (e.g., clients of multiple SaaS providers who want to centrally administer access to all of them) be using instead?