Top 10 Ajax Security Holes and Driving Factors
by Shreeraj Shah - net square - Friday, 10 November 2006.
(9) Flash-based cross domain access

It is possible to make GET and POST requests from JavaScripts within a browser by using a Flash plugin’s Ajax interface. This also enables cross-domain calls to be made from any particular domain. To avoid security concerns, the Flash plugin has implemented policy-based access to other domains. This policy can be configured by placing the file crossdomain.xml at the root of the domain. If this file is left poorly configured – as is quite often the case – it opens up the possibility of cross-domain access. Here is a sample of a poorly configured XML file:



Now, it is possible to make cross-domain calls from within the browser itself. There are a few other security issues concerning this framework as well. Flash-based Rich Internet Applications (RIA) can be vulnerable to a cross-domain access bug over Ajax if deployment is incorrect.

(10) XSRF

Cross-Site Request Forgery is an old attack vector in which a browser can be forced to make HTTP GET or POST requests to cross-domains; requests that may trigger an event in the application logic running on the cross-domain. These can be requests for a change of password or email address. When the browser makes this call it replays the cookie and adopts an identity. This is the key aspect of the request. If an application makes a judgment on the basis of cookies alone, this attack will succeed.

In Web 2.0 applications Ajax talks with backend Web services over XML-RPC, SOAP or REST. It is possible to invoke them over GET and POST. In other words, it is also possible to make cross-site calls to these Web services. Doing so would end up compromising a victim’s profile interfaced with Web services. XSRF is an interesting attack vector and is getting a new dimension in this newly defined endpoints scenario. These endpoints may be for Ajax or Web services but can be invoked by cross-domain requests.

Exploitation of security holes and Countermeasures

Web 2.0 applications have several endpoints; each an entry point for threat modeling. To provide proper security it is imperative to guard each of these entry points. Third-party information must be processed thoroughly prior to sending it to the end-client.

To deal with Ajax serialization issues validation must be placed on incoming streams before they hit the DOM. XML parsing and cross-domain security issues need extra attention and better security controls. Follow the simple thumb rule of not implementing cross-domain information processing into the browser without proper validation. Interestingly, up until now, the use of client-side scripts for input validation was thoroughly discouraged by security professionals because they can be circumvented easily.

Web 2.0 opens up several new holes around browser security. Exploitation of these security holes is difficult but not impossible. Combinations of security issues and driving factors can open up exploitable holes that impact the sizeable Web community, such as those that can be leveraged by attackers, worms and viruses. Identity compromise may be the final outcome.

Conclusion

This article has briefly touched upon a few likely security holes around Ajax. There are a few more lurking around, such as the ones leveraging cross-domain proxies to establish a one-way communication channel or memory variable access in the browser.

With Web 2.0, a lot of the logic is shifting to the client-side. This may expose the entire application to some serious threats. The urge for data integration from multiple parties and untrusted sources can increase the overall risk factor as well: XSS, XSRF, cross-domain issues and serialization on the client-side and insecure Web services, XML-RPC and REST access on the server-side. Conversely, Ajax can be used to build graceful applications with seamless data integration. However, one insecure call or information stream can backfire and end up opening up an exploitable security hole.

These new technology vectors are promising and exciting to many, but even more interesting to attack, virus and worm writers. To stay secure, this is all the more reason for developers to paying attention to implementation detail.

Spotlight

Operation Pawn Storm: Varied targets and attack vectors, next-level spear-phishing tactics

Posted on 23 October 2014.  |  Targets of the spear phishing emails included staff at the Ministry of Defense in France, in the Vatican Embassy in Iraq, military officials from a number of countries, and more.


Weekly newsletter

Reading our newsletter every Monday will keep you up-to-date with security news.
  



Daily digest

Receive a daily digest of the latest security news.
  

DON'T
MISS

Fri, Oct 24th
    COPYRIGHT 1998-2014 BY HELP NET SECURITY.   // READ OUR PRIVACY POLICY // ABOUT US // ADVERTISE //