RIA Data and Security, 2007
1 like330 views
This document discusses several technologies for data transactions in rich internet applications (RIAs), including REST, AMF, Flex-Ajax Bridge, JSON, and JSONRequest. REST uses XML, URIs and HTTP to enable distributed computing on the web. AMF is a proprietary data format used in Flash applications. The Flex-Ajax Bridge allows exposing ActionScript classes to JavaScript. JSON is a lightweight data interchange format used for transmitting data between client and server. JSONRequest proposes a new browser service for two-way data exchange using JSON.
RIA Data and Security, 2007
- 1. 1 RIA Implementation RIA Data and Security Data Transactions This section describes couple of technologies that can be used for data transactions within client/server RIA application REST REST is an acronym standing for Representational State Transfer. REST is a model for distributed computing. It is the one used by the world's biggest distributed computing application, the Web. When applied to web services technologies, it usually depends on a trio of technologies designed to be extremely extensible: XML, URIs, and HTTP. XML's extensibility should be obvious to most, but the other two may not be. URIs are also extensible: there are an infinite number of possible URIs. More importantly, they can apply to an infinite number of logical entities called "resources." URIs are just the names and addresses of resources. Some REST advocates call the process of bringing your applications into this model "resource modeling." This process is not yet as formal as object oriented modeling or entity-‐relation modeling, but it is related. The strength and flexibility of REST comes from the pervasive use of URIs. This point cannot be over-‐ emphasized. When the Web was invented it had three components: HTML, which was about the worst markup language of its day (other than being simple); HTTP, which was the most primitive protocol of its day (other than being simple), and URIs (then called URLs), which were the only generalized, universal naming and addressing mechanism in use on the Internet. Why did the Web succeed? Not because of HTML and not because of HTTP. Those standards were merely shells for URIs. HTTP's extensibility stems primarily from the ability to distribute any payload with headers, using predefined or (occasionally) new methods. What makes HTTP really special among all protocols, however, is its built-‐in support for URIs and resources. URIs are the defining characteristic of the Web: F e b r u a r y 1 6 , 2 0 0 7 the mojo that makes it work and scale. HTTP as a protocol keeps them front and center by defining all methods as operations on URI-‐addressed resources. AMF AMF is the Action Message Format. AMF is a proprietary data format created by Macromedia and used by different mediums: Flash Remoting, FlashComm, LocalConnection and Shared Objects. Skitsanos Inc.
- 2. 2 RIA Implementation All of these mediums share the same core data types and ActionScript data types. Each medium uses its own exclusive envelope. Any AMF-‐related project should implement reading and writing core data types, relevant ActionScript types, as well as providing support for its envelope type. Flex-‐Ajax Bridge The Flex™ AJAX Bridge (FABridge) is a small, unobtrusive code library that you can insert into an Adobe® Flex™ application, a Flex component, or even an empty SWF file to expose it to scripting in the browser. To humbly borrow a page from the Ruby on Rails community, FABridge is built with the “don’t repeat yourself” principle in mind. Rather than having to define new, simplified APIs to expose a graph of ActionScript objects to JavaScript, with FABridge you can make your ActionScript classes available to JavaScript without any additional coding. After you insert the library, essentially anything you can do with ActionScript, you can do with JavaScript. JSON JSON (JavaScript Object Notation) is a lightweight computer data interchange format. It is a text-‐based, human-‐readable format for representing objects and other data structures and is mainly used to transmit such structured data over a network connection (in a process called serialization). JSON finds its main application in Ajax web application programming, as a simple alternative to using XML for asynchronously transmitting structured information between client and server. JSONRequest XMLHttpRequest has a security model which is inadequate for supporting the next generation of web applications. JSONRequest is proposed as a new browser service that allows for two-‐way data exchange with any JSON data server without exposing users or organization to harm. It exchanges data between scripts on pages with JSON servers in the web. It is hoped that browser makers will build this feature into their products in order to enable the next advance in web application development. JSONRequest.post does an HTTP POST of a serialization of a JavaScript object or array, gets the response, and parses the response into a JavaScript value. If the parse is successful, it returns the value to the requesting script. In making the request, no HTTP authentication or cookies are sent. Any cookies returned by the server cause the request to fail. The JSONRequest service can only be used to send and receive JSON-‐encoded values. JSONRequest cannot be used to retrieve other text formats. BISON F e b r u a r y 1 6 , 2 0 0 7 Binary Interchange Standard and Object Notation (BISON) is a new binary format created by Kai Jäger. Essentially, you can now serialize any JavaScript variable into a string that holds a binary representation of whatever you had in that variable. This string may then be sent over XMLHTTPRequest to a script running on a web server. SOAP SOAP (originally Simple Object Access Protocol) is a protocol for exchanging XML-‐based messages over computer networks, normally using HTTP. SOAP forms the foundation layer of the Web services stack, Skitsanos Inc.
- 3. 3 RIA Implementation providing a basic messaging framework that more abstract layers can build on. The original acronym was dropped with Version 1.2 of the standard, which became a W3C Recommendation on June 24, 2003, as it was considered to be misleading. There are several different types of messaging patterns in SOAP, but by far the most common is the Remote Procedure Call (RPC) pattern, in which one network node (the client) sends a request message to another node (the server), and the server immediately sends a response message to the client. SOAP is the successor of XML-‐RPC, though it borrows its transport and interaction neutrality and the envelope/header/body from elsewhere. F e b r u a r y 1 6 , 2 0 0 7 Skitsanos Inc.
- 4. 4 RIA Implementation The security risks in Web 2.0 This technological transformation is bringing in new security concerns and attack vectors into existence. Yamanner, Samy and Spaceflash type worms are exploiting “client-‐side” AJAX frameworks, providing new avenues of attack and compromising some of the confidential information. On the “server-‐side”, XML based Web services are replacing some of the key functionalities and providing distributed application access through Web services interfaces. These remote capabilities to invoke methods over GET, POST or SOAP from the Web browser itself provide new openings to applications. On other side, RIA frameworks running on XML, XUL, Flash, Applets and JavaScripts are adding new possible sets of vectors. RIA, AJAX and Web services are adding new dimensions to Web application security. Here is the list of 10 attack vectors along with a brief overview of each: 1. Cross-‐site scripting in AJAX In the last few months, several cross-‐site scripting attacks have been observed, where malicious JavaScript code from a particular Web site gets executed on the victim’s browser thereby compromising information. A recent example is the Yamanner worm that exploited cross-‐site scripting opportunities in Yahoo mail’s AJAX call. Another recent example is the Samy worm that exploited MySpace.com’s cross-‐ site scripting flaw. AJAX gets executed on the client-‐side by allowing an incorrectly written script to be exploited by an attacker. The attacker is only required to craft a malicious link to coax unsuspecting users to visit a certain page from their Web browsers. This vulnerability existed in traditional applications as well but AJAX has added a new dimension to it. 2. XML poisoning XML traffic goes back and forth between server and browser in many of the WEB 2.0 applications. Web applications consume XML blocks coming from AJAX clients. It is possible to poison this XML block. Not uncommon is the technique to apply recursive payloads to similar-‐producing XML nodes multiple times. If the engine’s handling is poor this may result in a denial of services on the server. Many attackers also produce malformed XML documents that can disrupt logic depending on parsing mechanisms in use on the server. There are two types of parsing mechanisms available on the server side – SAX and DOM. This same attack vector is also used with Web services since they consume SOAP messages and SOAP messages are nothing but XML messages. Large-‐scale adaptation of XMLs at the application layer opens F e b r u a r y 1 6 , 2 0 0 7 up new opportunities to use this new attack vector. XML external entity reference is an XML property which can be manipulated by an attacker. This can lead to arbitrary file or TCP connection openings that can be leveraged by an attacker. XML schema poisoning is another XML poisoning attack vector which can change execution flow. This vulnerability can help an attacker to compromise confidential information. Skitsanos Inc.
- 5. 5 RIA Implementation 3. Malicious AJAX code execution AJAX calls are very silent and end-‐users would not be able to determine whether or not the browser is making silent calls using the XMLHTTPRequest object. When the browser makes an AJAX call to any Web site it replays cookies for each request. This can lead to potential opportunities for compromise. For example, John has logged in to his bank and authenticated on the server. After completing the authentication process he gets a session cookie. His bank’s page has a lot of critical information. Now he browses other pages while still logged in to his bank’s account Web page and lands at an attacker’s Web page. On this page the attacker has written silent AJAX code which makes backend calls to his bank without John’s consent, fetches critical information from the pages and sends this information to the attacker’s Web site. This leads to a security breach and leakage of confidential information. 4. RSS / Atom injection This is a new WEB 2.0 attack. RSS feeds are common means of sharing information on portals and Web applications. These feeds are consumed by Web applications and sent to the browser on the client-‐side. One can inject literal JavaScripts into the RSS feeds to generate attacks on the client browser. An end user visits this particular Web site loads the page with the RSS feed and the malicious script – a script that can install software or steal cookies – gets executed. This is a lethal client-‐side attack. Worse, it can be mutated. With RSS and ATOM feeds becoming integral part of Web applications, it is important to filter out certain characters on the server-‐side before pushing the data out to the end user. 5. WSDL scanning and enumeration WSDL (Web Services Definition Language) is an interface to Web services. This file provides key information about technologies, exposed methods, invocation patterns, etc. This is very sensitive information and can help in defining exploitation methods. Unnecessary functions or methods kept open can cause potential disaster for Web services. It is important to protect WSDL file or provide limited access to it. In real case scenarios, it is possible to discover several vulnerabilities using WSDL scanning. 6. Client side validation in AJAX routines WEB 2.0 based applications use AJAX routines to do a lot of work on the client-‐side, such as client-‐side validations for data type, content-‐checking, date fields, etc. Normally, these client-‐side checks must be backed up by server-‐side checks as well. Most developers fail to do so; their reasoning being the assumption that validation is taken care of in AJAX routines. It is possible to bypass AJAX-‐based validations and to make POST or GET requests directly to the application – a major source for input F e b r u a r y 1 6 , 2 0 0 7 validation based attacks such as SQL injection, LDAP injection, etc. that can compromise a Web application’s key resources. This expands the list of potential attack vectors that attackers can add to their existing arsenal. AJAX routines are: 7. Web services routing issues Web services security protocols have WS-‐Routing services. WS-‐Routing allows SOAP messages to travel in specific sequence from various different nodes on the Internet. Often encrypted messages traverse these nodes. A compromise of any of the intermediate nodes results in possible access to the SOAP Skitsanos Inc.
- 6. 6 RIA Implementation messages traveling between two end points. This can be a serious security breach for SOAP messages. As Web applications move to adopt the Web services framework, focus shifts to these new protocols and new attack vectors are generated. 8. Parameter manipulation with SOAP Web services consume information and variables from SOAP messages. It is possible to manipulate these variables. For example, “10” is one of the nodes in SOAP messages. An attacker can start manipulating this node and try different injections – SQL, LDAP, XPATH, command shell – and explore possible attack vectors to get a hold of internal machines. Incorrect or insufficient input validation in Web services code leaves the Web services application open to compromise. This is a new available attack vector to target Web applications running with Web services. 9. XPATH injection in SOAP message XPATH is a language for querying XML documents and is similar to SQL statements where we can supply certain information (parameters) and fetch rows from the database. XPATH parsing capabilities are supported by many languages. Web applications consume large XML documents and many times these applications take inputs from the end user and form XPATH statements. These sections of code are vulnerable to XPATH injection. If XPATH injection gets executed successfully, an attacker can bypass authentication mechanisms or cause the loss of confidential information. There are few known flaws in XPATH that can be leverage by an attacker. The only way to block this attack vector is by providing proper input validation before passing values to an XPATH statement. 10. RIA thick client binary manipulation Rich Internet Applications (RIA) use very rich UI features such as Flash, ActiveX Controls or Applets as their primary interfaces to Web applications. There are a few security issues with this framework. One of the major issues is with session management since it is running in browser and sharing same session. At the same time since the entire binary component is downloaded to the client location, an attacker can reverse engineer the binary file and decompile the code. It is possible to patch these binaries and bypass some of the authentication logic contained in the code. This is another interesting attack vector for WEB 2.0 frameworks. F e b r u a r y 1 6 , 2 0 0 7 Skitsanos Inc.
- 7. 7 RIA Implementation Securing Application A key problem with JavaScript is that it was designed so that its scripts can do anything the user can do. For example, it can pretend the user clicked on a particular link, or typed in some text into a Web page. There are a lot of things we might like to allow a user to do that it's not a good idea to let a JavaScript script of unknown provenance do. Unfortunately, JavaScript doesn't provide any good way to enforce such a distinction. What should AJAX developers do? As a Web 2.0 programmer, a RIA programmer, you need to both protect the user and not trust the user, it might seem counterintuitive, but think about it; the user can be both an attacker and a victim. Doing both of those things at once is a bit of a juggling act, but necessary from a security standpoint. Developers need to be aware of security and take responsibility for their applications. One of the benefits of new Web technologies has been to make Web programming accessible to a much broader interface, -‐ but that is a double-‐edged sword, because many of these new Web developers aren't necessarily trained in or fully aware of security issues. As software developers, it behooves us to think proactively about how our code might be misused. Below you can find couple of options that can be used for client/server data transmission security implementation. Combining some of them together might lead you into pretty safe application construction. Cross-‐site request forgery prevention Cross-‐site request forgery, also known as one click attack, or session riding, and abbreviated as CSRF or XSRF, is a kind of malicious exploit of websites. Although similar-‐sounding in name to cross-‐site scripting (XSS), it is a very different and almost opposite form of attack. Whereas cross-‐site scripting exploits the trust a user has in a website, a cross-‐site request forgery exploits the trust a Web site has in a user by forging a request from a trusted user. Compared to XSS attacks, CSRF attacks are often less popular (so there are fewer defense resources available) and more difficult to defend against, and thus are considered to be more dangerous. For the web site, switching from a persistent authentication method (e.g. a cookie or HTTP authentication) to a transient authentication method (e.g. a hidden field provided on every form) will help prevent these attacks. A similar approach is to include a secret, user-‐specific token in forms that is F e b r u a r y 1 6 , 2 0 0 7 verified in addition to the cookie. An alternate method is to "double submit" cookies. This method only works with Ajax based requests, but it can be applied as a global fix without needing to alter a large number of forms. If an authentication cookie is read using JavaScript before the post is made, the stricter (and more correct) cross-‐domain rules will be applied. If the server requires requests to contain the value of the authentication cookie in the body of POST requests or the URL of GET requests, then the request must have come from a trusted domain, since other domains are unable to read cookies from the trusting domain. Skitsanos Inc.
- 8. 8 RIA Implementation Contrary to popular belief, using POST instead of GET does not offer sufficient protection. JavaScript can be used to forge POST requests with ease. Nonetheless, requests that cause side effects should always use POST. Also, POST does not leave a trail of variable data in web server and proxy server logs, while GET does leave such a trail. It is still clearly best to use POST when coding in a defense-‐in-‐depth approach. Although cross-‐site request forgery is fundamentally a problem with the web application, not the user, users can help protect their accounts at poorly designed sites by logging off the site before visiting another, or clearing their browser's cookies at the end of each browser session. AJAX Secure Service Layer AJAX Secure Service Layer – aSSL, is a library distributed under MIT License that implements a technology similar to SSL without HTTPS. aSSL enables the client to negotiate a secret random 128-‐bit key with the server using the RSA algorithm. Once the connection has been established, the data will be sent and received using AES algorithm. aSSL is composed of some JavaScript files and a server side component. Because I have recently changed the negotiation algorithm from RC4 to RSA, only a pure JavaScript (ASP) server component is currently available. I will do a porting for the main web languages (PHP, Java, Perl, Python, TKL, etc.) as soon as possible once the library has passed the beta phase. Is aSSL secure as SSL? No. SSL is secure because it is a technology implemented at browser level so that when an HTTPS connection has been established, the browser checks the SSL Certificate before continuing. Suppose that a hacker were to attack you with a man-‐in-‐the-‐middle (MiTM) attack. With an SSL connection, the attack would be successful only should the user click Ok when the browser alerts him saying that the certificate doesn't correspond to the connected server (the alert may also appear if some file is transferred over HTTP instead of HTTPS because in this file a hacker could inject malicious code). If a hacker were to attack you with a MiTM attack during an aSSL connection, he could be successful. But MiTM attacks require great skill and a lot of organization. They are rare and a hacker would only be F e b r u a r y 1 6 , 2 0 0 7 worth while to the hacker if he has a lot to gain for is efforts. aSSL is designed for non-‐critical sites as chats, blogs, etc. where the potential payoff for hackers would be low, and therefore they would not be targeted by such attacks. Password sniffing is much more diffuse because it is much easier. In fact, there are specific software that sniff the traffic, recognize user id and passwords, and register them. Skitsanos Inc.
- 9. 9 RIA Implementation aSSL protects against these sniffers. When a server exchanges account information in clear HTTP, a sniffer can simply intercept all the data, but if the server exchanges the data via aSSL it is not possible to decode the passed data and so the level of security of the site is notably better. F e b r u a r y 1 6 , 2 0 0 7 Skitsanos Inc.
- 10. 10 RIA Implementation References REST Links • http://en.wikipedia.org/wiki/Representational_State_Transfer • http://webservices.xml.com/pub/a/ws/2002/02/20/rest.html • http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm • http://www.xfront.com/REST-‐Web-‐Services.html AMF Links • http://www.adobe.com/devnet/flex/articles/intro_fms_08.html • http://livedocs.adobe.com/flashremoting/mx/Using_Flash_Remoting_MX/intro2.htm • http://web.archive.org/web/20040603100453/chattyfig.figleaf.com/flashcoders-‐ wiki/index.php?SharedObjectFile FLEX-‐AJAX Bridge • http://labs.adobe.com/wiki/index.php/Flex_Framework:FABridge • http://www.flex.org/ • http://www.adobe.com/devnet/flex/articles/flex_security_wp/flex_security_wp.html • http://www.adobe.com/devnet/security/ • http://www.adobe.com/cfusion/exchange/index.cfm?view=sn610 JSON • http://www.softwaresecretweapons.com/jspwiki/Wiki.jsp?page=AJAXWithoutXML JSONRequest • http://json.org/JSONRequest.html BISON • http://www.kaijaeger.com/articles/introducing-‐bison-‐binary-‐interchange-‐standard.html SOAP Links • http://en.wikipedia.org/wiki/SOAP Security F e b r u a r y 1 6 , 2 0 0 7 • http://news.com.com/The+security+risk+in+Web+2.0/2100-‐1002_3-‐6099228.html • http://www.spidynamics.com/assets/documents/HackingFeeds.pdf • http://www.net-‐security.org/article.php?id=949&p=1 • http://assl.sullof.com/assl/ Skitsanos Inc.