4 ms·

Most of those problems are specific to JavaScript. Just strip out JavaScript.

by _bxg1 8y ago

untog 8y ago
Then you strip out interactivity. Which is a pretty huge component of making the internet interesting and weird. For its many sins, Flash was actually a pretty great sandbox for people to play with that way (as long as it didn't have one of its many security issues at the time)
- roywiggins 8y ago
  There was a period when you could use Flash to invoke a javascript: protocol link and it would be executed in the containing page! They fixed it eventually but it was a great way to escape the Flash sandbox.
- jandrese 8y ago
  Flash seems like a good example of how it's incredibly difficult to secure a system like that, even with a sandbox. How many security updates did Flash have over the course of its life? Back in the heyday I remember it having to update multiple times a week.
  - lazyjones 8y ago
    > How many security updates did Flash have over the course of its life? One. When they finally killed it. All other updates were more or less security sidegrades.
jerf 8y ago
I never claimed the problems were hard to solve. (It's probably harder than you think, but there's off-the-shelf solutions for them now, as long as you've got a developer smart enough to reach for them, or one skilled and experienced enough to know how to build them in a pinch.) But by the time you've solved them all, you're pretty much back to where Reddit, HN, Facebook, etc. are. I assume the author does not consider those "fun and weird". I mean, I remember when Slashdot was having trouble with user abuse of <pre> tags. A simple <pre> tag of all things! When you scale up, you have to close all the little holes, and what's left is not "fun and weird". You can have fun and weird. It's out there, if you look, and worst case, you can always deploy your own site and do anything you want. But you can't have fun and weird at scale.
roywiggins 8y ago
The other problem that bedeviled sites that allowed arbitrary HTML back in the day was crude phishing attempts: convert your user profile into a fake login page with CSS and HTML. Blocking this entirely is probably impossible. I suppose some machine learning could be used to detect pages styled as phishing attempts. There were also all sorts of ways to sneak JavaScript back in. I remember embedding a javascript: protocol link inside a Flash applet would do it (flash eventually blocked that though).
- _bxg1 8y ago
  Pretty sure if there's no JS you could just block iframes and maybe form tags and then people would have no way to submit anything. They could click a malicious link, sure, but they can do that on today's social networks.
  - roywiggins 8y ago
    Then you can replace the website "chrome"- the headers, the links back to the rest of the site- with doppelgangers that take you to a phishing page that makes it look like you've been logged out. All of those you'd expect to be internal links, so when they show you a "please log in again" screen you will have no reason for suspicion. You can't do that on Facebook today. Alternatively, you don't need a form tag. Just show a login set of text inputs and an image that looks like a submit button. That button links you to a phishing site that says "oops! try again" and then you put your password in a second time and this time it's a real form. So you'd have to get rid of text inputs entirely.
    - hawski 8y ago
      If I understand you correctly those "you are leaving example.com" interstitial pages with a redirect are a solution to this problem. Although they are not so pleasant.
yoz-y 8y ago
Is it technically possible to completely strip out javascript but still retain full html + css compatibility? I had the impression that somebody always finds a way to outsmart any filter using UTF arcanes or some other method.
- _bxg1 8y ago
  Hmm. I can't say for absolute sure, but if the root document is HTML and there are no <script> tags (or <iframe>s, I guess), I don't see how you'd get JavaScript to execute. I think those are strictly the only entry-points JS can have, and it's not like HTML or CSS could mutate the document to create one after the fact. EDIT: I brainfarted and totally forgot about inline event handlers. Go easy on the downvotes please.
  - johnsoft 8y ago
    <div onclick="alert(0)">whoops</div> If you want to dive down the rabbit hole, here's a good place to start: https://www.owasp.org/index.php/XSS_Filter_Evasion_Cheat_Sheet https://www.owasp.org/index.php/XSS_Filter_Evasion_Cheat_She...
    - _bxg1 8y ago
      Ah right, duh. Still, I feel like there would be an enumerable set of properties that can execute JS.
      - marcosdumay 8y ago
        There is an enumerable set of HTML and CSS properties, so yeah. That document is scary! There are 70 different ways to encode an opening angle bracket, what is just a tiny side note...
- the8472 8y ago
  Content-Security-Policy: sandbox allow-same-origin allow-top-navigation allow-forms; That gives you HTML + CSS - JS for the whole page.

Most of those problems are specific to JavaScript. Just strip out JavaScript.

by _bxg1 8y ago

Most of those problems are specific to JavaScript. Just strip out JavaScript.

Then you strip out interactivity. Which is a pretty huge component of making the internet interesting and weird. For its many sins, Flash was actually a pretty great sandbox for people to play with that way (as long as it didn't have one of its many security issues at the time)

roywiggins 8y ago
There was a period when you could use Flash to invoke a javascript: protocol link and it would be executed in the containing page! They fixed it eventually but it was a great way to escape the Flash sandbox.
jandrese 8y ago
Flash seems like a good example of how it's incredibly difficult to secure a system like that, even with a sandbox. How many security updates did Flash have over the course of its life? Back in the heyday I remember it having to update multiple times a week.
- lazyjones 8y ago
  > How many security updates did Flash have over the course of its life? One. When they finally killed it. All other updates were more or less security sidegrades.

jerf 8y ago

I never claimed the problems were hard to solve. (It's probably harder than you think, but there's off-the-shelf solutions for them now, as long as you've got a developer smart enough to reach for them, or one skilled and experienced enough to know how to build them in a pinch.) But by the time you've solved them all, you're pretty much back to where Reddit, HN, Facebook, etc. are. I assume the author does not consider those "fun and weird". I mean, I remember when Slashdot was having trouble with user abuse of <pre> tags. A simple <pre> tag of all things! When you scale up, you have to close all the little holes, and what's left is not "fun and weird". You can have fun and weird. It's out there, if you look, and worst case, you can always deploy your own site and do anything you want. But you can't have fun and weird at scale.

roywiggins 8y ago

The other problem that bedeviled sites that allowed arbitrary HTML back in the day was crude phishing attempts: convert your user profile into a fake login page with CSS and HTML. Blocking this entirely is probably impossible. I suppose some machine learning could be used to detect pages styled as phishing attempts. There were also all sorts of ways to sneak JavaScript back in. I remember embedding a javascript: protocol link inside a Flash applet would do it (flash eventually blocked that though).

_bxg1 8y ago
Pretty sure if there's no JS you could just block iframes and maybe form tags and then people would have no way to submit anything. They could click a malicious link, sure, but they can do that on today's social networks.
- roywiggins 8y ago
  Then you can replace the website "chrome"- the headers, the links back to the rest of the site- with doppelgangers that take you to a phishing page that makes it look like you've been logged out. All of those you'd expect to be internal links, so when they show you a "please log in again" screen you will have no reason for suspicion. You can't do that on Facebook today. Alternatively, you don't need a form tag. Just show a login set of text inputs and an image that looks like a submit button. That button links you to a phishing site that says "oops! try again" and then you put your password in a second time and this time it's a real form. So you'd have to get rid of text inputs entirely.
  - hawski 8y ago
    If I understand you correctly those "you are leaving example.com" interstitial pages with a redirect are a solution to this problem. Although they are not so pleasant.

yoz-y 8y ago

Is it technically possible to completely strip out javascript but still retain full html + css compatibility? I had the impression that somebody always finds a way to outsmart any filter using UTF arcanes or some other method.

_bxg1 8y ago
Hmm. I can't say for absolute sure, but if the root document is HTML and there are no <script> tags (or <iframe>s, I guess), I don't see how you'd get JavaScript to execute. I think those are strictly the only entry-points JS can have, and it's not like HTML or CSS could mutate the document to create one after the fact. EDIT: I brainfarted and totally forgot about inline event handlers. Go easy on the downvotes please.
- johnsoft 8y ago
  <div onclick="alert(0)">whoops</div> If you want to dive down the rabbit hole, here's a good place to start: https://www.owasp.org/index.php/XSS_Filter_Evasion_Cheat_Sheet https://www.owasp.org/index.php/XSS_Filter_Evasion_Cheat_She...
  - _bxg1 8y ago
    Ah right, duh. Still, I feel like there would be an enumerable set of properties that can execute JS.
    - marcosdumay 8y ago
      There is an enumerable set of HTML and CSS properties, so yeah. That document is scary! There are 70 different ways to encode an opening angle bracket, what is just a tiny side note...
the8472 8y ago
Content-Security-Policy: sandbox allow-same-origin allow-top-navigation allow-forms; That gives you HTML + CSS - JS for the whole page.