Archive for the AJAX Category

Looks like my follow up to Gareth Heyes’ Twitter Hack produced two effects:

  1. Twitter guys closed their hole by requiring an additional basic HTTP authentication step to retrieve the friends timeline JSON feed. Well done, albeit still lacking as an anti-CSRF countermeasure, because if user already performed basic authentication for any reason during this session, the hack still works flawlessly (not sure about how likely this is, though).
  2. Some readers complained about me slightly criticizing Adblock Plus’ new 3rd party blocking, by calling it “rather inconvenient” (especially if compared with the new NoScript 1.8.8.95’s anti-hijacking protection which doesn’t require any script blocking), although I was actually praising the famous ad blocker as a countermeasure against this attack.
    Yesterday evening, when I wrote that post, I was overly tired from a very stressful week, so I fell in the trap of suggesting to use Adblock Plus for a security purpose. After some sleep, a bit more in my mind, I recalled why I always recommend Adblock Plus as a wonderful annoyance blocker, but not to be relied upon for security: there are too many easy ways to circumvent it.
    More in general, Adblock Plus and FlashBlock, despite a popular superstition, can’t be considered security tools because they’re not conceived nor developed with the necessary defensive and proactive paranoid mindset.

I updated my PoC to reflect both these events.
Now it “hijacks” Twitter’s public listings feed which, as the adjective “public” suggests, has no reason to be protected.
And this time Adblock Plus’ 3rd party blocking won’t help :)

Are you logged in Twitter?

Some days ago my friend Gareth Heyes exposed an authorization bug in Twitter’s JSON interface, by writing a short post titled I Know What Your Friends Did Last Summer. Do not click on his PoC with JavaScript enabled, unless you want to find yourself bombed by a lot of alert boxes showing some interesting Twitter data about you and your friends.

For your convenience, I’ve reproduced a less annoying PoC here:

Are you logged in Twitter?

Notice/update: after some hours this article was out, Twitter secured its “friends timeline” feed. Therefore I updated this PoC to consume the “public” feed, still demonstrating the hijacking technique, albeit on a non-sensitive data set.


Twitter’s JSON feed is spied upon using __defineSetter__, a useful JavaScript extension introduced by Mozilla and now implemented in all the modern browsers (i.e. all the popular ones except IE). After redefining a property setter on Object.prototype, we can read the values being set when the feed is loaded through a <SCRIPT> element:

Object.prototype.__defineSetter__("user",
  function(value) { // do something with user's value }
);
<script src="https://twitter.com/statuses/friends_timeline/"></script>

The main problem here is, obviously, Twitter leaving this feed unsecured against cross-site requests, under the wrong assumption that it could be read only through XMLHttpRequest (which actually does not work cross-site). We can expect errors like this to be quite widespread, since so-called “AJAX security” is still in its infancy: consider that Twitter guys are not exactly newbies…

This JSON-hijacking technique won’t work if any of the following conditions applies:

  • The feed provider (Twitter) secures its JSON to ensure 3rd party sites can’t access it (i.e. implementing any anti-CSRF countermeasure).
  • The JSON payload is not enclosed in square brackets. If the JSON starts directly with curly braces, it gets intepreted as a code block, rather than an object initializer, and nothing happens.
  • You’re using an antiquated browser (like IE).
  • JavaScript execution is disabled on the attacker’s site (e.g. by using NoScript in its default configuration).
  • You’re preventing 3rd party scripts from loading (e.g. by using Adblock Plus with its rather inconvenient 3rd party script blocking feature enabled). Forget it, too much easy to work-around :(
  • You’re using NoScript 1.8.8.95 or above, even if you’re allowing scripts everywhere!

Yes, that’s right: in the best NoScript tradition, while there’s some ongoing work to prevent this kind of leakage from happening in next major version of Firefox, NoScript already provides a specific protection feature. Even better, this works even in Allow Scripts Globally mode, just like anti-XSS filters and the ClearClick anti-clickjacking technology, so you’ve got no excuse to stay unsafe.

P.S.:
another thing you can do for your Twitter security, especially if you use public wifi, is adding twitter.com to your HTTPS behavior forced list and enabling automatic secure cookies management, to defeat cookie hijacking attacks.

Update

Twitter fixed this issue by requiring HTTP authentication in order to retrieve the https://twitter.com/statuses/friends_timeline.json feed.
I’ll post a new innocuous didactic PoC fetching the public feed and circumventing Adblock Plus as soon as I’m done with breakfast.

What is Database Connectivity for JavaScript?

IBM® Database Connectivity for JavaScript™ is middleware that enables Web clients to directly access server-side relational data without compromising enterprise security.

“Directly access” without compromising “enterprise security”, yeah…

On the client, IBM Database Connectivity for JavaScript consists of a JavaScript API and library that can be used by Web applications without special browser plug-ins. On the server, the IBM Database Connectivity for JavaScript gateway, written in PHP, is an adaptor layer that mediates between IBM Database Connectivity for JavaScript and relational databases and provides functions such as operation forwarding and security. Web 2.0 applications can thus use IBM Database Connectivity for JavaScript to access relational data as a first-class construct instead of through ad hoc protocols.

Before you start wondering (like I did) what “operation forwarding” and “security” mean in this context, I’ll tell you since I bothered to read the source code: it’s just a thin layer with a JDBC-like API which allows JavaScript code to compose and submit SQL statements from the client side!
Security, if any, needs to be enforced at the database level, and access credentials are sent from the client side as well.

IBM Database Connectivity for JavaScript supports the trend for Web applications to be dynamically composed in a Web browser — so-called “Web 2.0″ applications — instead of being completely composed on the server (”Web 1.0″).

First “enterprise”, now “Web 2.0″…

IBM Database Connectivity for JavaScript is specifically geared toward enabling the potential Web 2.0 benefits of increased application responsiveness and the ability to flexibly combine information from various sources on the client. Web 2.0 access to server-side data, however, is currently characterized by Representational State Transfer (REST)-like APIs, which are typically application specific.

Bah, those old-fashioned resource mappings which (try to) expose only the data subsets relevant to the application front-end…
But now we can unleash the full power of SQL: free queries to all our databases for everyone in the fantastic world of Web 2.0!

ODBC is powerful — allowing any SQL statement to be executed — and simple, in the sense that developers are required to understand only a few abstractions. IBM Database Connectivity for JavaScript can be thought of as an “ODBC for Web clients,” enabling Web developers to benefit from a general-purpose API for accessing relational data.

Great work IBM! Now please convince some of your many banking customers to deploy this fantastic technology on their Internet-facing web servers, and we’ll be happy to “benefit from a general purpose API for accessing relational data” directly from Firebug, thanks!

Did you know crossdomain.xml, introduced by Adobe Flash to allow cross-domain requests, is now supported by Java?

A similar mechanism is being standardized for XMLHttpRequest, and had been implemented in an early Firefox 3 beta (some extra work for your friendly neighborhood NS-Man), but ultimately dropped later in the development cycle…

Rhino VS BeanEven if I’m the NoScript guy, I write a lot of JavaScript all the day. As you probably know, even the JavaScript Annihilator is mostly written in JavaScript. Like Crock, I love the language, despite its current browser-bound shortcomings.

So far, my favourite editor for JS coding has been JEdit with its JavaScript plugin, providing syntax highlighting (of course!), on the fly syntax checking via Rhino and optional code completion with configurable scopes, including Mozilla “chrome window” and XPCOM.

But today I’ve watched a presentation of the new NetBeans 6.1 JavaScript capabilities, and I’m impressed.
Dynamic type guessing, browser-specific contextual help and DOM-aware AJAX library support (John, guess which they show in their demo?) may be really worth the switch.

Bad Behavior has blocked 7218 access attempts in the last 7 days.