6 ms·

The Blessing of the Strings

31 points by lumpa 3y ago

mrkeen 3y ago
> You can think of TrustedHTML as an interface indicating that a string has been somehow specially "blessed" as safe... Sanitized. 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.
- semi-extrinsic 3y ago
  I recall many moons ago, I used OpenSuse in my local language, and "Untrusted" had been translated as though it meant "Untrustworthy". Hilarity ensued.
- sublinear 3y ago
  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.
  - semiquaver 3y ago
    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)
    - sublinear 3y ago
      Good point. I didn't read that far and if you're right that's terrible even if it follows the same origin policy.
- Thorrez 3y ago
  Well, the string can be trusted to not have a working XSS attack, because it's been sanitized.
- dwheeler 3y ago
  Looks correct to me. You must specially mark data that is trusted as trusted. All other daya is not trusted.
oasisaimlessly 3y ago
TL;DR: Perl's taint mode is coming to JavaScript.
- xlii 3y ago
  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?
- gpvos 3y ago
  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.
wavemode 3y ago
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?
- rhaps0dy 3y ago
  I think “someone” is inexperienced or lazy developers that want to just use APIs insecurely.
  - dullcrisp 3y ago
    then I still have the same question
- azornathogron 3y ago
  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.
  - azornathogron 3y ago
    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 3y ago

31 points by lumpa 3y ago

> You can think of TrustedHTML as an interface indicating that a string has been somehow specially "blessed" as safe... Sanitized. 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.

semi-extrinsic 3y ago
I recall many moons ago, I used OpenSuse in my local language, and "Untrusted" had been translated as though it meant "Untrustworthy". Hilarity ensued.
sublinear 3y ago
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.
- semiquaver 3y ago
  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)
  - sublinear 3y ago
    Good point. I didn't read that far and if you're right that's terrible even if it follows the same origin policy.
Thorrez 3y ago
Well, the string can be trusted to not have a working XSS attack, because it's been sanitized.
dwheeler 3y ago
Looks correct to me. You must specially mark data that is trusted as trusted. All other daya is not trusted.

oasisaimlessly 3y ago

TL;DR: Perl's taint mode is coming to JavaScript.

xlii 3y ago
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?
gpvos 3y ago
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.

wavemode 3y ago

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?

rhaps0dy 3y ago
I think “someone” is inexperienced or lazy developers that want to just use APIs insecurely.
- dullcrisp 3y ago
  then I still have the same question
azornathogron 3y ago
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.
- azornathogron 3y ago
  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 3y ago