Not logged in : Login

About: OAT and JS Hijacking     Goto   Sponge   NotDistinct   Permalink

An Entity of Type : atom:Entry, within Data Space : www.openlinksw.com associated with source document(s)
QRcode icon
http://www.openlinksw.com/describe/?url=http%3A%2F%2Fwww.openlinksw.com%2Fdataspace%2Foat%2Fweblog%2FThe%2520OAT%2520Weblog%2F1176

AttributesValues
has container
Date Created
maker
Date Modified
link
id
  • 417cce87f8e485a3379f8c02d4a659ab
content
  • 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 :)

Title
  • OAT and JS Hijacking
is described using
atom:source
atom:updated
  • 2017-12-29T13:21:33Z
atom:title
  • OAT and JS Hijacking
links to
atom:author
label
  • OAT and JS Hijacking
topic
atom:published
  • 2007-04-04T04:18:00Z
http://rdfs.org/si...ices#has_services
type
is made of
is link of
is atom:contains of
is atom:entry of
is container of of
is skos:isSubjectOf of
is http://rdfs.org/si...vices#services_of of
is xhv:tag of
Faceted Search & Find service v1.17_git63 as of Apr 23 2021


Alternative Linked Data Documents: iSPARQL | ODE     Content Formats:       RDF       ODATA       Microdata      About   
This material is Open Knowledge   W3C Semantic Web Technology [RDF Data] Valid XHTML + RDFa
OpenLink Virtuoso version 08.03.3322 as of Jun 3 2021, on Linux (x86_64-generic-linux-glibc25), Single-Server Edition (30 GB total memory)
Data on this page belongs to its respective rights holders.
Virtuoso Faceted Browser Copyright © 2009-2021 OpenLink Software