In Firefox 3.5 ...

Everything I read about javascript hijacking seems to be out of date (or was always wrong). Everything is saying overwrite the Object or Array constructor, but the object and array constructors don't get executed for literal object/array syntax.

JSON: [["one","two],["a","b","c"]]

<script src="page_returning_json" />

This does NOT cause the Array constructor to execute, so overwriting it is useless. Has this exploit been solved by the browsers? Is there something I'm not getting?

-clayfox

I was checking into this recently too. As far as I can tell, all modern browsers have implemented some sort of fix for this. I suspect flash may still have related issues though I haven't confirmed.

Like you, I was surprised that most all online documentation is outdated so I'm glad you brought it up.

The reason is it's been fixed. __defineSetter__ attacks still works in some browsers and they don't consider it a vuln like Opera whoo hoo. UTF-7 attacks still work in Firefox and maybe other browsers.

See my twitter attack:-
http://www.thespanner.co.uk/2009/01/07/i-know-what-your-friends-did-last-summer/

also my csp attack for utf-7:-
http://www.thespanner.co.uk/2009/11/23/bypassing-csp-for-fun-no-profit/

------------------------------------------------------------------------------------------------------------
"People who say it cannot be done should not interrupt those who are doing it.";
labs : [www.businessinfo.co.uk]
blog : [www.thespanner.co.uk]
Hackvertor : [hackvertor.co.uk]

I looked at the two links you provided. The twitter attack seems outdated (except in Opera), and I didn't follow the CSP/UTF-7 attack (mainly because I don't know what CSP stands for).

What is CSP? Can you explain the UTF-7 attack which still works in firefox?

-clayfox

CSP stands for content security policy and is the new security feature in Firefox that prevents XSS by defining what a site allows to be executed.

The attack uses a UTF-7 encoded string as the injection inside a JSON feed. When the external attack site includes the feed it uses UTF-7 as the script charset decoding the encoded string and therefore getting access to the full JSON data. The blog post makes the attack very clear if you ignore the CSP part.

------------------------------------------------------------------------------------------------------------
"People who say it cannot be done should not interrupt those who are doing it.";
labs : [www.businessinfo.co.uk]
blog : [www.thespanner.co.uk]
Hackvertor : [hackvertor.co.uk]

Either I am still not getting it, or the UTF-7 issue has nothing to do with javascript hijacking.

Javascript hijacking is an attack to steal the data returned as pure JSON. The UTF-7 issue is an XSS attack.

While the CSP workaround is cool, I don't think it is pertinent here.

Opera being vulnerable is very pertinent. Does anyone know what versions of firefox and IE this is unpatched in? Are we talking IE 6 and the like, or newer?

-clayfox

Quote

Either I am still not getting it, or the UTF-7 issue has nothing to do with javascript hijacking.

You're not getting it :|

If you can inject your data into a json string you can steal the data. I dunno what else to explain

------------------------------------------------------------------------------------------------------------
"People who say it cannot be done should not interrupt those who are doing it.";
labs : [www.businessinfo.co.uk]
blog : [www.thespanner.co.uk]
Hackvertor : [hackvertor.co.uk]

http://www.businessinfo.co.uk/images/draw_you_a_picture.jpg

------------------------------------------------------------------------------------------------------------
"People who say it cannot be done should not interrupt those who are doing it.";
labs : [www.businessinfo.co.uk]
blog : [www.thespanner.co.uk]
Hackvertor : [hackvertor.co.uk]

Let me clarify my understanding of the attack.

There is some JSON created which contains some data under the attacker's control and some other sensitive info.

Somewhere <script src="json_location" charset="utf-7" /> exists. When it is hit, the XSS payload in the JSON will execute.

I have to assume that the script tag is on a malicious site which a valid user has gone to while still able to access the JSON.

1. Is this correct?
2. If so, how is this used to get the other JSON data?

I could imagine that you could insert js that ends (roughly) in ";var name=". Then other js on the malicious page would be able to reference all of the JSON data after the attacker controlled portion by referencing 'name'.

-clayfox

Technically it isn't a XSS attack, you are using the victim to include the remote JSON but serve it as UTF-7. Then the injection can get the data before and after the injection. Here's how to set the data after the inject:-

'}];/*This is all UTF-7 encoded*/setTimeout(function() { alert(obj); },500);obj=[{'abc

You can get the data before too but I'm not gonna tell you how, you'll just have to work it out

------------------------------------------------------------------------------------------------------------
"People who say it cannot be done should not interrupt those who are doing it.";
labs : [www.businessinfo.co.uk]
blog : [www.thespanner.co.uk]
Hackvertor : [hackvertor.co.uk]

For the injected utf-7 encoded javascript to execute, the JSON returned (or really anything that is returned) must be valid js statements up to the injection point.

So, other than in Opera, there aren't "known" javascript hijacking attacks in current browsers when the data returned is a js literal object (ie starts with '{') or when there isn't an injection point into the data returned.

I say "known", because this seems like something where there should be another js environment changing based exploit sitting out there.

-clayfox



Edited 1 time(s). Last edit at 03/18/2010 10:12AM by clayfox.

Huh?

All JSON attacks work assuming that the JSON is valid JavaScript. Otherwise you'd get a syntax error as this isn't required as a first statement:-

{'syntax error':'Because a literal cant be first'}

------------------------------------------------------------------------------------------------------------
"People who say it cannot be done should not interrupt those who are doing it.";
labs : [www.businessinfo.co.uk]
blog : [www.thespanner.co.uk]
Hackvertor : [hackvertor.co.uk]



Edited 1 time(s). Last edit at 03/18/2010 10:50AM by Gareth Heyes.

Now I don't think you are understanding me. These JSON attacks are only related to responses that contain only JSON. JSON comes in two flavors for our purposes: either it starts with '{' or it starts with '['. Only the latter will be a valid js statement, so only the latter is attackable.

The old attacks of overwriting the constructor are no longer valid since modern browsers don't use those constructors for literal objects.

All I'm saying is that the attack surface has greatly diminished from when this attack was published.

-clayfox

You're wrong you can still attack statements beginning with "{" providing you have control over the first name property of the JSON element. They may have been reduced slightly but UTF-7 and defineSetter are two attacks available still

------------------------------------------------------------------------------------------------------------
"People who say it cannot be done should not interrupt those who are doing it.";
labs : [www.businessinfo.co.uk]
blog : [www.thespanner.co.uk]
Hackvertor : [hackvertor.co.uk]

FYI Safari, Chrome and Opera still support:-
Object.prototype.__defineSetter__('a',function(val) { alert(val) });
;[{a:123}]

They didn't consider it a bug when I reported it. Firefox is patched because of ma1 and "I know what your friends did last summer"

------------------------------------------------------------------------------------------------------------
"People who say it cannot be done should not interrupt those who are doing it.";
labs : [www.businessinfo.co.uk]
blog : [www.thespanner.co.uk]
Hackvertor : [hackvertor.co.uk]



Edited 1 time(s). Last edit at 03/19/2010 11:32AM by Gareth Heyes.

@Gareth Yep, the __defineSetter__ trick still works for me in those 3 browsers. Good to know it's still a viable attack.

Simple PoC here: http://p42.us/json.html

A simple fix for anyone currently responding with vulnerable JSON would be to wrap it in {"data":original_JSON}.

This way it will always cause a SyntaxError when pulled in via a <script> tag.

Anyone know any attacks on SyntaxError?

-clayfox

Yes valid JSON can still be stolen

------------------------------------------------------------------------------------------------------------
"People who say it cannot be done should not interrupt those who are doing it.";
labs : [www.businessinfo.co.uk]
blog : [www.thespanner.co.uk]
Hackvertor : [hackvertor.co.uk]