NoScript creates vulnerability w/ twitter.com logout

[aladin235]

First, kudos to all involved for a great add-on -- y'all rock. I wanted to give back by reporting an issue:

Using FF 3.0.10 under Win, with NoScript 1.9.3.3, and not allowing scripts on twitter.com makes for an interesting wrinkle when logged into twitter.com: signing out lands you on some clever bloke's new twitter profile page (and doesn't sign you out). [Edit: and no, this doesn't seem to be due to any flaw with twitter.com's code, NoScript is adding a GET request it shouldn't]

By virtue of the NoScript's sanitization somewhere, I just noticed today that attempting to click the Sign Out button to log off of twitter.com, you end up on http://twitter.com/sign_out_form which some clever person either created today, or just started using earlier today. This unfortunately makes using twitter.com with NoScript actually a little less safe than having js enabled.

The twitter.com html for logout is:

Code: Select all

<a id="sign_out_link" href="#" onclick="document.getElementById('sign_out_form').submit(); return false;" 
              accesskey="l">Sign out</a>

and the sign_out_form element is:

Code: Select all

<form method="post" id="sign_out_form" action="/sessions/destroy" style="display:none;">
<input name="authenticity_token" value="[redacted]" type="hidden" />
</form>

which twitter intends to simply POST a single value POST to http://twitter.com/sessions/destroy With NoSCript enabled however, what I see is that in addition to the POST to /sessions/destroy (good) NoScript takes it upon itself to generate a GET request that we don't want:

Code: Select all

GET http://twitter.com:80/sign_out_form HTTP/1.1

Sometimes this GET is a HEAD instead of a GET with the same URI. In either case, you end up on the twitter page of some clever guy who chose a username of sign_out_form (presumably a NoScript user who spotted the vulnerability NoScript seems to have created here).

For whatever reason, I just noticed this behavior today, so I'm not sure if there's something new in twitter.com's code, whther the account was just created and the issue now evidences itself, or if noscript changed somehow. It's all rather interesting.

I did some testing with and without Options>dvanced>XSS "Sanitize cross-site suspicious requests" and "Turn cross-site POST requests into data-less GET requests" and didn't see the undesired GET request go away. Only "allow scripts globally" or disabling NoScript seemed to make the issue go away.

Opera, Firefox and IE's behavior with javascript turned off simply make the Sign Out button not work at all, as you might expect from the code since the sign out link's href= clause is just href="#" [Edit: And all 3 of those browsers with JavaScript on behave as designed: they sign you out with the signout button, and do NOT redirect you to the clever user's new profile page. ]

Curious if this has been reported elsewhere or what the real timeline was on this.

Keep up the good work!

[Tom T.]

Without even reading the code, it sounds like the umpteenth time that twitter's been hacked. They never learn. Guess that's why they're called "twits".
http://xkcd.com/327/

[aladin235]

Without even reading the code, it sounds like the umpteenth time that twitter's been hacked. They never learn. Guess that's why they're called "twits".
http://xkcd.com/327/

Hi Tom, Unfortunately you'd be wrong though. This isn't a twitter issue. All signs point to this being a vulnerability NoScript introduces that isn't there without NoScript.

I've edited my original posts a few times to highlight that a bit. Thanks for pointing out where I wasn't clear!

[Giorgio Maone]

Hi Aladin,
I'm not sure why you keep calling it "a vulnerability": you just land on the updates page of this "sign_out_form" Twitter user.

However, if you're curious about what's causing this redirection to happnen, it's the NoScript Options|Advanced|Untrusted|Attempt to fix JavaScript links feature, which tries to emulate JavaScript navigation whenever possible.
The "Head" request you can see sometimes just checks if the landing page exists before moving.
This is obviously speculative, but usually works for "javascript:" URLs and even drop-down navigation menus.
There's even code which tries to detect a form to be submitted (like in this case): it works with Youtube's login, but not with the Twitter logout.
I'm investigating the reason (bug) for the different behavior, but not a vulnerability IMO.

[aladin235]

Hi Aladin,
I'm not sure why you keep calling it "a vulnerability": you just land on the updates page of this "sign_out_form" Twitter user.

However, if you're curious about what's causing this redirection to happnen, it's the NoScript Options|Advanced|Untrusted|Attempt to fix JavaScript links feature, which tries to emulate JavaScript navigation whenever possible.
The "Head" request you can see sometimes just checks if the landing page exists before moving.
This is obviously speculative, but usually works for "javascript:" URLs and even drop-down navigation menus.
There's even code which tries to detect a form to be submitted (like in this case): it works with Youtube's login, but not with the Twitter logout.
I'm investigating the reason (bug) for the different behavior, but not a vulnerability IMO.

Hi Giorgio,

First, thanks personally for all your work on NoScript, your prompt answer, and investigation of the issue.

A bug that can be leveraged to augment signout functionality with browser redirection to a user-created page ... well, I have to stick by my verbiage. I am glad it calls attention to the ways attackers could envision using this functionality to target NoScript users uniquely though. We all love NoScript for the attack vectors it takes away via JS, but this appears to be one instance where a preserving-of-functionality feature can create a possible new/interesting means of attack.

Semantics aside, I think we can agree that in this case the bug/vuln's impact was very small other than possibly panicking folks about browser 0wnage. Combine this with a site code injection issue though (i.e. if the crafty user could put arbitrary code on that profile page), and there might be some fun for the bad guys to be had.

Thanks again for your work!

[Giorgio Maone]

Fixed in 1.9.4 RC1

[GµårÐïåñ]

Vulnerability, it is not. Bug, its pushing it. Undesired effect is more like it. Nothing bad is allowed or is happening and simply unchecking the attempt to fix links will fix the issue. When you ask ANYONE or ANYTHING to attempt to automatically do something based on logic, it may not be the logic you are looking for, so disable it and that way nothing is attempted for you. Semantics aside of course, the fix has been attempted in the latest dev build, give it a spin.