5 ms·

Seriously, their response was to disable spaces in the form? There is no legitimate reason for anything other than \w to be in there... how about a real filter

Seriously, their response was to disable spaces in the form? There is no legitimate reason for anything other than \w to be in there... how about a real filter? Twitter has been lazy and generally pathetic in just about every area since they began... talk about getting lucky with a good idea.

mattmaroon 17y ago
Shocker, the people who can't stop their website from going down all the time aren't very good coders.
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.
kwamenum86 17y ago
On the YC submission thread created when this vulnerability was first noticed there were several good solutions suggested for this problem. al3x from Twitter responded to several of the comments and if memory serves he thought several of the solutions would work. For a halfway decent coder this could be solved in minutes. This has nothing to do with maintaining a huge website as some users have commented. Stuff like this should probably break less when your website is huge.

mattmaroon 17y ago

Shocker, the people who can't stop their website from going down all the time aren't very good coders.

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.

kwamenum86 17y ago

On the YC submission thread created when this vulnerability was first noticed there were several good solutions suggested for this problem. al3x from Twitter responded to several of the comments and if memory serves he thought several of the solutions would work. For a halfway decent coder this could be solved in minutes. This has nothing to do with maintaining a huge website as some users have commented. Stuff like this should probably break less when your website is huge.