I agree, roadrunnertwice has done a really nice job thinking this through.
[LJ::CleanHTML] does a lot of work to try to block things like scripts, but possibly we can just use CSP or such to block those by policy and then simplify?
It might just be my age and remembering a time before CSP, but I'd pretty strongly recommend against relying on CSP alone. CSP is great as a backup for when something gets through, but there are a number of cases where even a perfectly-specified CSP is not going to work very well:
Any browser that doesn't understand CSP. (Older browsers, at least.)
Cross-posting. Gotta clean stuff before shipping it off, both so DW doesn't look like an attacker to any automated systems, and because relying on the other end to be secure seems like a not-great idea.
Non-HTML contexts. Presumably you'd still want to clean things before they end up in RSS, for instance, so JS doesn't end up in somebody's feed reader.
More generally, I'd argue that relying on CSP would move security issues from DW's control to third-party control (browser vendors, cross-post targets, e-mail clients, feed readers), which is a lot of faith to put in other people getting security right. Yes, use CSP! But in conjunction with existing security measures, not as a replacement.
It might be possible to simplify things by layering them—one layer to do input transformations, and another for security transformations, say—but that would require very careful design if input transformations need to produce things that would be rejected by the security layer (so no reserved HTML classes or ids, at least without shenanigans like using a random nonce or signed token that gets replaced with the reserved value).
no subject
I agree,![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png)
roadrunnertwice has done a really nice job thinking this through.
It might just be my age and remembering a time before CSP, but I'd pretty strongly recommend against relying on CSP alone. CSP is great as a backup for when something gets through, but there are a number of cases where even a perfectly-specified CSP is not going to work very well:
More generally, I'd argue that relying on CSP would move security issues from DW's control to third-party control (browser vendors, cross-post targets, e-mail clients, feed readers), which is a lot of faith to put in other people getting security right. Yes, use CSP! But in conjunction with existing security measures, not as a replacement.
It might be possible to simplify things by layering them—one layer to do input transformations, and another for security transformations, say—but that would require very careful design if input transformations need to produce things that would be rejected by the security layer (so no reserved HTML classes or ids, at least without shenanigans like using a random nonce or signed token that gets replaced with the reserved value).