Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Twitter 'onmouseover' security flaw widely exploited

sophos.com

Post reply on HN
Print view View original

61–70 of 77 posts

Re: Twitter 'onmouseover' security flaw widely exploited

#61

Post by user24 »

robryan wrote: post #34
bl4k wrote: post #14

Earlier quoted context omitted.

not harmless at all? this can do so much damage because you can run javascript in the context of the users session. some ideas for payloads: * login as that user by sending yourself their session token * scrape email addresses * follow a spam account * popup an affiliate site * trigger a download or one of the new flash exploits to gain access to the local system your code has to fit within 140 chars, but you can use…

Will the session token work just like that? Each session might be tied to a specific IP address or something.

tying things to specific IP address isn't a good idea. Some ISPs rotate outbound IP addresses on a per-connection basis. As in, when you refresh, you might be coming from a different IP. I think AOL first did this some years ago. It's a real shame.

Re: Twitter 'onmouseover' security flaw widely exploited

#62

Post by Tichy »

jerf wrote: post #58
tomafro wrote: post #26

It looks like twitter have fixed the issue in their own tweet parsing library, but not deployed the fix (to old twitter at least). Here's the relevant commit: http://github.com/mzsanford/twitter-text-rb/commit/cffce8e60... (thanks to Paul Battley for finding it).

That's still the wrong approach (if it's the only part of the solution) and I wouldn't be surprised that there's still a problem in there somewhere. That's the entirely wrong place to deal with this. The correct solution is the moral equivalent of " ", where "html_escape" converts the URL into a properly encoded HTML string regardless of contents, and for simplicitly I'm assuming some other cleansing process has run…

I don't understand what they are doing? I don't recall @ having special significance in a URL?

I can only guess that they have two separate steps for transforming URLs into links and transforming @replies into links. Then they first run the URL transformer and then the @replies transformer, which would of course mess up the URL.

I have solved that problem in one of my Twitter apps (transforming both in one go), maybe I should send them a code snippet...

Re: Twitter 'onmouseover' security flaw widely exploited

#63

Post by TomasSedovic »

paraschopra wrote: post #20
mike-cardwell wrote: post #13

If you get caught, just log into twitter via http://www.accessibletwitter.com/ to delete the item it posts.

Nice social engineering trick :) [PS: Just kidding]

At the risk of being too literal:

You don't give the site your username & password. It uses OAuth to log in to Twitter.

Re: Twitter 'onmouseover' security flaw widely exploited

#65

Post by jasonkester »

pornel wrote: post #57
jasonkester wrote: post #54

Earlier quoted context omitted.

No, it's just why developers should HTML-escape all user-contributed content before displaying it. Building it into the templating engine just punishes all the devs who know what they're doing. Look at the history of things like MAGIC_QUOTES_RUNTIME to see what happens if you go down that route.

Clearly relying on developers to remember to escape didn't work (it's not first XSS and not last). I don't think it's anything like magic quotes. It's more like prepared statements. Magic quotes was enormous failure because it worked on input rather than output. In HTML-specific output code having HTML-escaping is just fine. Lack of escaping enables worms and error isn't immediately visible. Double escaping is quickl…

As soon as you start auto-escaping everything, you need to introduce a dontEscapeThis() method that you can use to actually render the HTML you intended.

Having to do that would be enough to make me ditch any framework in favor of one that treats me like a grownup.

Re: Twitter 'onmouseover' security flaw widely exploited

#66

Post by thenduks »

vanschelven wrote: post #24
Swizec wrote: post #5

This is what it posts " http://a.no/@onmouseover=;$(textarea:first).val(this.innerHT... style="color:#000;background:#000;/" class="tweet-url web" rel="nofollow" target="_blank"> http://a.no/@onmouseover=;$(textarea:first).val(this.innerHT... style="color:#000;background:#000;/ " It's not a huge security flaw, just some (this time) harmless javascript injection. What it does is it fires a mouseover event, then fills…

How is JavaScript injection not a huge security flaw? JavaScript injection -> acquire session -> basically anything (within the context of twitter)

It's clearly a huge security flaw, but as you say -- only within the context of twitter. Looking at the big picture of my life something like this doesn't even register. What's the worst thing that could happen, really? A popup? Maybe my account gets stolen somehow? Some garbage tweets in my timeline that I delete later with a non-web client? All of the sudden I'm following some spammers... I'd get over it.

Re: Twitter 'onmouseover' security flaw widely exploited

#67

Post by points »

jasonkester wrote: post #65
pornel wrote: post #57

Earlier quoted context omitted.

Clearly relying on developers to remember to escape didn't work (it's not first XSS and not last). I don't think it's anything like magic quotes. It's more like prepared statements. Magic quotes was enormous failure because it worked on input rather than output. In HTML-specific output code having HTML-escaping is just fine. Lack of escaping enables worms and error isn't immediately visible. Double escaping is quickl…

As soon as you start auto-escaping everything, you need to introduce a dontEscapeThis() method that you can use to actually render the HTML you intended. Having to do that would be enough to make me ditch any framework in favor of one that treats me like a grownup.

It's depressing to see your comment at -1. I guess there are lots of framework lovers here :/

Re: Twitter 'onmouseover' security flaw widely exploited

#68

Post by sbov »

jasonkester wrote: post #65
pornel wrote: post #57

Earlier quoted context omitted.

Clearly relying on developers to remember to escape didn't work (it's not first XSS and not last). I don't think it's anything like magic quotes. It's more like prepared statements. Magic quotes was enormous failure because it worked on input rather than output. In HTML-specific output code having HTML-escaping is just fine. Lack of escaping enables worms and error isn't immediately visible. Double escaping is quickl…

As soon as you start auto-escaping everything, you need to introduce a dontEscapeThis() method that you can use to actually render the HTML you intended. Having to do that would be enough to make me ditch any framework in favor of one that treats me like a grownup.

Yes, lets needlessly make something harder and less secure in 99% of the cases because people want to be treated like a "grownup".

How many times have you written code that actually required raw, dynamic, unescaped html output in a template engine? I think I have... 2 times? And for 2 times I still had to escape the output 50% of the time - when displaying it in a form for the user to edit.

Re: Twitter 'onmouseover' security flaw widely exploited

#69

Post by marcinw »

jerf wrote: post #58
tomafro wrote: post #26

It looks like twitter have fixed the issue in their own tweet parsing library, but not deployed the fix (to old twitter at least). Here's the relevant commit: http://github.com/mzsanford/twitter-text-rb/commit/cffce8e60... (thanks to Paul Battley for finding it).

That's still the wrong approach (if it's the only part of the solution) and I wouldn't be surprised that there's still a problem in there somewhere. That's the entirely wrong place to deal with this. The correct solution is the moral equivalent of " ", where "html_escape" converts the URL into a properly encoded HTML string regardless of contents, and for simplicitly I'm assuming some other cleansing process has run…

Actually, you want to perform URL encoding in such example, as "javascript:alert(1)" when escaping HTML entities will slip past un-encoded.

See http://www.owasp.org/index.php/XSS_%28Cross_Site_Scripting%2... for more information.

Re: Twitter 'onmouseover' security flaw widely exploited

#70

Post by jerf »

marcinw wrote: post #69
jerf wrote: post #58

Earlier quoted context omitted.

That's still the wrong approach (if it's the only part of the solution) and I wouldn't be surprised that there's still a problem in there somewhere. That's the entirely wrong place to deal with this. The correct solution is the moral equivalent of " ", where "html_escape" converts the URL into a properly encoded HTML string regardless of contents, and for simplicitly I'm assuming some other cleansing process has run…

Actually, you want to perform URL encoding in such example, as "javascript:alert(1)" when escaping HTML entities will slip past un-encoded. See http://www.owasp.org/index.php/XSS_%28Cross_Site_Scripting%2... for more information.

As Rule #5 of your own link states: "WARNING: Do not encode complete or relative URL's with URL encoding! URL's should be encoded based on the context of display like any other piece of data. For example, user driven URL's in HREF links should be attribute encoded."

URL encoding is for querystring parameters. The HTML escaping is for the inside of attributes. You need to do both, in the proper place; I assumed you already had a URL with the proper escaping at the time that I was discussing, again, for simplicity, because the full story doesn't really fit in an HN comment: http://www.jerf.org/iri/post/2548

That's also why I mention you need a separate phase specially for URLs, where you will for instance immediately reject any URL that does not start with one of your whitelisted protocols, which "javascript:" won't be on. "javascript:" is far from the only protocol that can get you in trouble, it's just the most obvious.

Post reply on HN