3 ms·
In fact, this is actually an issue that can only be properly solved in the browser, hence the need for security projects like DOMPurify in the past. The reason
by _vvhw 5y ago
In fact, this is actually an issue that can only be properly solved in the browser, hence the need for security projects like DOMPurify in the past.
The reason being that all browsers parse potential XSS (and mXSS) content slightly differently so that a server side sanitizer by definition will never parse content in exactly the same way as a specific version of a given browser, since it's not sharing exactly the same runtime.
This semantic gap between browser rendering quirks and server side approximations can be exploited by an attacker to slip content past the server side sanitizer.
And that's why the browser vendors are actively working with Cure53, the author of DOMPurify, in order to ship Sanitizer API.
I'm just surprised this has taken so long.
- cxr 5y agoA reminder: people, please don't take your cues on language theoretic security (or anything security-related) from internet comments containing unverified claims, even if those comments aren't nameless/faceless and are moderately-to-highly upvoted. The parent comment is an example, appearing to have the approval of the community, but there are several subtle things wrong (or just odd) with it. It's short of misleading people into doing anything harmful, though, so stopping the world to hash them out here isn't critical, and would be tedious besides. Aside from that, a subset of people using DOMPurify—maybe even a plurality—seem to treat it as a talisman and can't explain how or if they've configured it correctly to provide the kind of protections they need for their use case. Security is not a separable concern.
- _vvhw 5y agoIt would be better for your comment to provide reasonable objections as to why DOMPurify should not be considered state of the art, without spreading fear, uncertainty or doubt.
- mcherm 5y ago> The parent comment is an example, appearing to have the approval of the community, but there are several subtle things wrong (or just odd) with it. It's short of misleading people into doing anything harmful, though, so stopping the world to hash them out here isn't critical, and would be tedious besides. It is not clear to me what subtle things are wrong with the parent comment. But I'm pretty sure I can see the flaw in claiming that something is wrong without saying how. It's an impossible-to-disprove accusation which therefore does not advance the conversation.
- deleted 5y ago[deleted]
- acdha 5y ago> please don't take your cues on language theoretic security (or anything security-related) from internet comments containing unverified claims Your comment is nothing but vague, unverified claims. Why do should you be given the benefit of the doubt but not the person you're replying to? If you have a real concern, share it so that it can be evaluated and everyone, including the original poster, can learn from it.
- nawgz 5y agoWhat a useless comment. “Shite bad but I won’t say a thing about what or how” And then you proceed to imply developers who have UIs susceptible to XSS are to blame, even though this is a known attack vector where browsers parse adversarial trees in an exploitable way that is completely opaque to everyone? This is silly. Hold your tongue or speak clearly, don’t jeer from a high horse