OAT and JS Hijacking

There has been some recent buzz regarding security issues of Web 2.0 sites. I decided to thoroughly study and analyze how this works, manifests and influences JS toolkits.

The best approach here is to study whitepaper located at  http://comparitech.net/websecuritytools . One can find a typical attack scenario, some defense suggestions and security considerations. While the paper is (in my opinion) oversized, telling rather small amount of facts on large amount of pages, it contains some interesting information. Let me share how all this relates to OAT.

First of all, I must conclude that none of OAT-based apps is vulnerable to mentioned attacks, for two reasons:

1. attacks are only appliable in JSON documents, fetched via GET method. Our OAT apps use XML format, requested with POST (via XML/A - SOAP).
2. attacks are only appliable when security tokens (i.e. user name, password) are passed via browser cookie. This is not our case, since we pass these in POST request's body.

However, we might take into consideration the fact that OAT can be used for building different applications. So I added some low-level support for security countermeasures mentioned in the PDF document. Specifically (as a client-side only toolkit), the following two methods:

  a) cookie-based secret, passed as URL parameter in GET requests. So every OAT.AJAX.GET invocation will

• set a cookie called 'oatSecurityCookie' to some random value
• add 'oatSecurityCookie=xxx' to URL string, where xxx equals to the random value mentioned above. 

  b) enhanced JSON parser with smarter text analysis, effectively filtering out

• comments (at the beginning and end of JSONified text)
• the 'while(1);' trap, situated at the beginning of received text

Both methods are now mentioned in the OAT documentation. Of course, applying OAT eqipped with these countermeasures doesn't make (yet) your app secure: one must explicitely use one (or both) methods on server side, to complement OAT's security features.

To sum this up - OAT is now providing a maximum support for securing GETting JSONified data. It is up to user whether he wants to take advantage of this. We are - as (nearly) always - ready :)