The Blessing of the Strings(bkardell.com)
bkardell.com
The Blessing of the Strings
https://bkardell.com/blog/blessing-strings.html
16 comments
I recall many moons ago, I used OpenSuse in my local language, and "Untrusted" had been translated as though it meant "Untrustworthy". Hilarity ensued.
Well, the string can be trusted to not have a working XSS attack, because it's been sanitized.
Looks correct to me. You must specially mark data that is trusted as trusted. All other daya is not trusted.
I agree "sanitized" is the only accurate term for this.
I think the reason they bother using any other word is the assumption that some web developers aren't familiar with the term, or maybe to score points with pointy haired bosses that absolutely should not be working in the industry in 2024.
I think the reason they bother using any other word is the assumption that some web developers aren't familiar with the term, or maybe to score points with pointy haired bosses that absolutely should not be working in the industry in 2024.
But it may not have been sanitized. It may be the output of a source that we trust not to be malicious (for example, a string generated by a server)
Good point. I didn't read that far and if you're right that's terrible even if it follows the same origin policy.
I'm not quite sure I follow the theat model here?
> But wait... can't someone come along then and just create a more lenient policy called default? No! That will throw an exception!
Who is "someone" in this situation? And why are they able to execute arbitrary JavaScript code in the user's browser, yet the user is somehow protected by a string sanitization policy?
> But wait... can't someone come along then and just create a more lenient policy called default? No! That will throw an exception!
Who is "someone" in this situation? And why are they able to execute arbitrary JavaScript code in the user's browser, yet the user is somehow protected by a string sanitization policy?
"someone" is probably a dependency you include that, for one reason or another tries to revert the policy to a lower level of enforcement. Might be because the dependency needs the lower security policy to work, or because it's a framework that comes with an insecure default, or might be because it accepted a couple PRs from JiaT75.
I think it's a sensible choice: try lowering the policy and everything blows up. Much better than the alternative of silently ignoring the call or, even worse, silently lowering the policy
I think it's a sensible choice: try lowering the policy and everything blows up. Much better than the alternative of silently ignoring the call or, even worse, silently lowering the policy
It's a defense-in-depth measure.
If your whole codebase is written without anyone making mistakes then the new policy won't change anything for you. But if not - particularly if your codebase is large and written by many different people over time - then you should probably not assume it's free of all bugs and vulnerabilities. A policy that can be applied centrally to all pages by configuring headers gives you an extra runtime protection against certain kinds of high risk coding errors.
This is just like programs deliberately dropping privileges when they start - they don't use those privileges anyway so dropping them doesn't do anything, right? But of course dropping privileges is worthwhile because programs have bugs and some of those bugs are security vulnerabilities and dropping privileges can reduce the severity of exploits.
If your whole codebase is written without anyone making mistakes then the new policy won't change anything for you. But if not - particularly if your codebase is large and written by many different people over time - then you should probably not assume it's free of all bugs and vulnerabilities. A policy that can be applied centrally to all pages by configuring headers gives you an extra runtime protection against certain kinds of high risk coding errors.
This is just like programs deliberately dropping privileges when they start - they don't use those privileges anyway so dropping them doesn't do anything, right? But of course dropping privileges is worthwhile because programs have bugs and some of those bugs are security vulnerabilities and dropping privileges can reduce the severity of exploits.
Coming back to this after a couple of days, I now realize I probably misunderstood the original question.
'xanathar provided a more useful answer.
'xanathar provided a more useful answer.
TL;DR: Perl's taint mode is coming to JavaScript.
While the idea is similar, the main difference is that Perl assigns the taint tag to input strings and requires you to do a special operation to cast it away (and also you can just print a tainted string!, and Perl does several additional checks, e.g. on other-writable directories), while this new Javascript system requires you to specially bless all output strings, even ones you generate without involving any input data.
Not sure why you’re getting downvoted. That was my first thought too (a tongue in cheek one, so maybe that’s part that’s missing?)
Taint mode is one of the concepts I’ve been thinking about a lot (Rust can implement it nicely with type wrapping and it’s great for working with user input).
There was an old joke that can be paraphrased into another one: so supposedly you either die a loved language or live long enough to become a Perl?
Taint mode is one of the concepts I’ve been thinking about a lot (Rust can implement it nicely with type wrapping and it’s great for working with user input).
There was an old joke that can be paraphrased into another one: so supposedly you either die a loved language or live long enough to become a Perl?
Unfortunate naming. "Trusted" is one of those words which has taken on its own opposite as a meaning. Like "redundant" or "cope".
This feature would be Checked/Validated/Trustworthy/Safe. Values would end up in this state if you did not trust them and needed to check them.