Twitter Exploit Still Works(davidnaylor.co.uk)
davidnaylor.co.uk
Twitter Exploit Still Works
http://www.davidnaylor.co.uk/twitter-exploit-still-works.html
Twitter XSS exploit from yesterday still works. They haven't done a very good job of fixing it.
You only need to see an exploited tweet to be affected!
21 comments
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.
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.
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.
63 Employees. 55 Million dollars. And twice they fail to accomplish the trivial.
Well said. I cannot think of a solid reason why this would be a difficult fix. Totally incompetent.
And don't they use Rails, which presumably makes it very easy, if not the default, to escape HTML output?
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.
If you're allowing user-generated text into a html tag (ie. this case.) Escaping html tags won't help.
Why not?
The substitution they do is <a href="%s">, and you can "game that" by inserting 'http://foo.com> other stuff goes here <whatever foo="">' Fine. The literal HTML that the user sees becomes '<a href="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&quot;&gt; other stuff goes here &lt;whatever foo=&quot;">' 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
Edit: sigh, that is also broken! Bottom line; none of these things will happen to you if you replace every & with &amp;, every " with &quot;, every ' with &apos;, every < with &lt; and every > with &gt;.)
The substitution they do is <a href="%s">, and you can "game that" by inserting 'http://foo.com> other stuff goes here <whatever foo="">' Fine. The literal HTML that the user sees becomes '<a href="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&quot;&gt; other stuff goes here &lt;whatever foo=&quot;">' 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
Edit: sigh, that is also broken! Bottom line; none of these things will happen to you if you replace every & with &amp;, every " with &quot;, every ' with &apos;, every < with &lt; and every > with &gt;.)
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.
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.
Shocker, the people who can't stop their website from going down all the time aren't very good coders.
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.
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.
I generally take the view that people are too hard on Twitter, and that maintaining a gigantic network like this is a lot more difficult than it looks.
This, though, as a 'fix,' is just complete incompetence.
This, though, as a 'fix,' is just complete incompetence.
I used to give them the benefit of the doubt on that. I've now changed my view to: it's probably more difficult than it looks, but Twitter makes it look impossible.
To anyone with any level of web security experience, the real fix for this (proper escaping) should be obvious.
For every really trivial vulnerability like this that Twitter can't fix, there must be scores of slightly more subtle vulns that go undisclosed.
For every really trivial vulnerability like this that Twitter can't fix, there must be scores of slightly more subtle vulns that go undisclosed.
Semi-off-topic, but I found something seriously wrong with Craigslist.
https://post.craigslist.org/manage/1340717167/tkrju#tr231033
That link will allow you to edit that post. You don't even have to be logged in.
I've already alerted them, but let's see how long this lasts.
https://post.craigslist.org/manage/1340717167/tkrju#tr231033
That link will allow you to edit that post. You don't even have to be logged in.
I've already alerted them, but let's see how long this lasts.
The hashtag isn't necessary, ie https://post.craigslist.org/manage/1340717167/tkrju works too.
Actually, I think craigslist probably views this more as a feature than an exploit. Since you don't need an account to post on craigslist, they can't do normal cookie based authentication, so they just give you a secret url for editing your page. Unfortunately, the only thing secret about the url is a 5 character alpha-numeric string, which I suppose would be possible to brute force.
Actually, I think craigslist probably views this more as a feature than an exploit. Since you don't need an account to post on craigslist, they can't do normal cookie based authentication, so they just give you a secret url for editing your page. Unfortunately, the only thing secret about the url is a 5 character alpha-numeric string, which I suppose would be possible to brute force.
Wow... Did some brand new intern get assigned the responsibility to "fix" this?
Like the author said, I think I'll be off Twitter for a little while too.
Like the author said, I think I'll be off Twitter for a little while too.
This is unbelievable. Even more so that they would not just disable the displaying of the application until they are sure that thing is fixed. My guess is this was just the beginning of big time spam/phish/... problems for twitter...
If you still want to use the (scary) web interface, there is always NoScript.
Twitter should disable everything except registration through the web interface. If it is not a script injection vulnerability, it is a 404 error returned for the CSS file resulting in a linear layout, or the web interface not loading at all. The API on the other hand is usually up (and by extension so are third party apps.) If they focus their attention on supporting the API they could charge app developers a fee, which many would happily pay since they would be the exclusive interfaces used for Twitter (since the web interface would be gone) and they could build ads, charge for app use, and provide customized extended Twitter functionality.
I am completely half serious on this.
I am completely half serious on this.
does this mean that if I am using tweetdeck on a mac that i am vulnerable?