4 ms·

There is no legitimate reason to not escape the damn output, either. Twitter has officially reached the level of satire, folks. 63 Employees. 55 Million dollar

by tdavis 17y ago

There is no legitimate reason to not escape the damn output, either. Twitter has officially reached the level of satire, folks. 63 Employees. 55 Million dollars. And twice they fail to accomplish the trivial.

jrockway 17y ago
And don't they use Rails, which presumably makes it very easy, if not the default, to escape HTML output?
- dnaquin 17y ago
  PSA. Escaping html only helps if you're allowing user-generated text outside of any tag. If you're allowing user-generated text into a html tag (ie. this case.) Escaping html tags won't help.
  - jrockway 17y ago
    Why not? The substitution they do is <a href="%s">, and you can "game that" by inserting 'http://foo.com&#62 http://foo.com> other stuff goes here <whatever foo="">' Fine. The literal HTML that the user sees becomes '<a href="http://foo.com>other http://foo.com>other stuff goes here <whatever foo="">'. That's bad. Now if you escape that properly, you get: '<a href="http://foo.com"&gt http://foo.com"> other stuff goes here <whatever foo="">' Garbage, but not a security problem. (BTW, news.arc fucks up the escaping too, so this example is garbage. Sorry. See nopaste here: http://scsys.co.uk:8001/33063 http://scsys.co.uk:8001/33063 Edit: sigh, that is also broken! Bottom line; none of these things will happen to you if you replace every & with &, every " with ", every ' with ', every < with < and every > with >.)
    - dnaquin 17y ago
      Congratulations, you've just stopped one particular attack. There'll be something you forget. Blacklisting is only a good idea if whitelisting isn't possible. (see the \w above) eg. You forgot. javascript:alert(document.cookie) Which depends on click and in and of itself isn't dangerous but a symptom of a greater problem. edit: except you need to allow more than \w.
devin 17y ago
Well said. I cannot think of a solid reason why this would be a difficult fix. Totally incompetent.

by tdavis 17y ago

jrockway 17y ago

And don't they use Rails, which presumably makes it very easy, if not the default, to escape HTML output?

dnaquin 17y ago
PSA. Escaping html only helps if you're allowing user-generated text outside of any tag. If you're allowing user-generated text into a html tag (ie. this case.) Escaping html tags won't help.
- jrockway 17y ago
  Why not? The substitution they do is <a href="%s">, and you can "game that" by inserting 'http://foo.com&#62 http://foo.com> other stuff goes here <whatever foo="">' Fine. The literal HTML that the user sees becomes '<a href="http://foo.com>other http://foo.com>other stuff goes here <whatever foo="">'. That's bad. Now if you escape that properly, you get: '<a href="http://foo.com"&gt http://foo.com"> other stuff goes here <whatever foo="">' Garbage, but not a security problem. (BTW, news.arc fucks up the escaping too, so this example is garbage. Sorry. See nopaste here: http://scsys.co.uk:8001/33063 http://scsys.co.uk:8001/33063 Edit: sigh, that is also broken! Bottom line; none of these things will happen to you if you replace every & with &, every " with ", every ' with ', every < with < and every > with >.)
  - dnaquin 17y ago
    Congratulations, you've just stopped one particular attack. There'll be something you forget. Blacklisting is only a good idea if whitelisting isn't possible. (see the \w above) eg. You forgot. javascript:alert(document.cookie) Which depends on click and in and of itself isn't dangerous but a symptom of a greater problem. edit: except you need to allow more than \w.

devin 17y ago

Well said. I cannot think of a solid reason why this would be a difficult fix. Totally incompetent.