170 Hacking Exposed Web 2.0 5. Click the SessionID Analysis button at the top of WebScarab. In the Previous Requests drop down menu, select the request idea number noted in step 4. Click the Test button at the bottom to ensure that WebScarab is able to identify the Session ID in the request. If WebScarab identifi es the Session ID, a box will pop up confi rming this. 6. After confi rming that WebScarab can identify the Session ID, set the sample size fi eld to 1000 queries and click the Fetch button to begin testing. Chapter 6: AJAX Types, Discovery, and Parameter Manipulation 171 7. Once testing has begun, select the item in the Session Identifi er drop-down menu of the Analysis tab in the SessionID Analysis window. 172 Hacking Exposed Web 2.0 8. Finally, after selecting the Session ID, select the Visualisation tab of the SessionID Analysis window to view a graph of the predictability of session IDs in the target application. Chapter 6: AJAX Types, Discovery, and Parameter Manipulation 173 Cookie Flags In additional to the session ID component of cookies, several other factors can contribute significantly (or detract significantly) from a cookie’s security. These components include the Secure and HTTPOnly flags, the Domain and Path properties, and any extra site- specific items. Secure Flag The Secure flag restricts the browser from sending the cookie in the clear over HTTP. Instead, the cookie will be transmitted only when the communication is over HTTPS. This flag is supported by all major browsers and will prevent an attacker from being able to obtain the cookie by sniffing the network. HTTPOnly Flag The HTTPOnly flag is used to prevent attacks from stealing cookies via cross-site script- ing (XSS). The flag achieves this by disabling script in the browser from accessing any cookies. This flag is currently understood only in Microsoft Internet Explorer and Mozilla Firefox. 174 Hacking Exposed Web 2.0 Domain Property The Domain property of a cookie is used to limit the scope of servers allowed to access the cookie. If an application sets its domain property only to the web server on which it is running, for example, www.example.com, then only www.example.com will be able to access it. For additional security, the domain property should simply be set to blank ("domain=") to ensure that only the setting server can access the cookie. Attackers should check all cookies for the restrictiveness of the domain property, because if it is not restrictive, an attacker will be able to steal the cookie through attacks launched from other servers in the same domain. For example, consider the case of an attacker who wants to steal the cookie of a user logged in to www.example.com and the domain prop- erty is restricted only to the .example.com domain instead of www.example.com. If the attacker is able to perform a XSS attack from forums.example.com or joes-pc.example .com or any other system in the example.com domain, she will be able to steal a user’s cookie because any site from inside the example.com domain will be allowed to access the cookie. Path Property The Path property of a cookie is used to further limit the scope of what applications on a server are allowed to access a given cookie. Attackers will have to find a hole in the specific application to obtain a user’s cookie rather than using any application on the server. For example, consider the case where a server is running multiple applications, such as a store at www.example.com/store/ and a forum for customers at www.example .com/forum/. If the Path property is not set to www.example.com/store/, an attacker could perform a XSS attack via www.example.com/forum/ and still access cookies set by www.example.com/store/. Unfortunately, there are ways to circumvent the Path property. See Chapter 2 for details. Site-Specifi c Items Numerous custom items can be added to an application’s cookies on a site-by-site basis. While added items generally do not impact the security of the application, attackers can examine each item in a cookie for a potential security impact. Developers have been known to include items in cookies that have compromised the security of the entire application—for example, a cookie containing the item isAdmin=false. If an attacker set the item to isAdmin=true in a cookie, the attacker would obtain administrator access to the system. Example The following example shows how to use the iSEC Partners SecureCookies tool to analyze the security options used in cookies generated by a target web application. 1. Install the iSEC Partners SecureCookies tool available for free at www .isecpartners.com/tools.html. This tool analyzes a cookie’s fl ags and properties, as well as any site-specifi c items for common security misconfi gurations. Chapter 6: AJAX Types, Discovery, and Parameter Manipulation 175 2. Run SecureCookies by opening a Windows command prompt, changing to the SecureCookies directory, and executing the program with the target web site as an argument. 3. After SecureCookies has run, it will dump its results to an HTML fi le for review in a web browser. 176 Hacking Exposed Web 2.0 Cookie Wrap-Up Developers can be lulled into a false sense of security by using cookies that appear ran- dom for session identification, when in reality it is trivial for an attacker to compromise any user’s cookie after a small amount of analysis. Additionally, a number of flags can be appended to cookies to increase or decrease the security of the cookies an application generates. Several freely available tools allow attackers to analyze the predictability of session ID cookies, as well as automatically analyze a cookie’s flags. Despite being unaf- fected by the change from a Web 1.0 application to an AJAX application, cookies remain a critical component of web application security. SUMMARY As shown, numerous steps are involved in the information gathering process that occurs before successful attacks can be launched on an AJAX application. An attacker must cover areas such as what type of AJAX application is in use, what its methods are, and whether any of the methods appear to be unintentionally exposed. However, the attack- er’s job is made significantly easier by the availability of several free tools that can help at every stage of this process. Once the process is complete, targeted technical attacks such as XSS and cross-site request forgery can begin in earnest. 177 7 AJAX Framework Exposures Copyright © 2008 by The McGraw-Hill Companies. Click here for terms of use. 178 Hacking Exposed Web 2.0 E xposures of AJAX frameworks are generally quite similar and are often caused by developers’ lack of understanding of what information their application is sending to clients. This lack of understanding is easily compounded by the use of different AJAX frameworks. One style of framework might by default send only certain data to users of an application and another style of framework might send entirely different data. While this may not seem like a security issue in and of itself, web applications often contain functionality or information that developers expect to remain secret. Once exposed, functionality or information such as this can thoroughly compromise the security of the web application. In addition, each AJAX framework offers different levels of built-in protections for web applications that use it. For example, some AJAX frameworks offer built-in protection for cross-site request forgery (CSRF) attacks, while others require that developers build their own protections into their applications. Two different styles of AJAX frameworks can have significantly different impacts on the security of a web application. The first type of framework is known as a proxy or server framework. This style of framework is generally installed on the web server along with the web application. Once installed, it acts as a proxy between the web application on the server and the client. The proxy framework first creates JavaScript that describes the methods that the web application on the server contains. This JavaScript is then sent down to the client so that when the client wants to call methods on the server, the request is sent to the proxy first, which then reformats the request and passes on the method to the server. The data that results from the call is then passed from the server to the proxy, which reformats the data and sends it down to the JavaScript in the client. The other style of AJAX framework, a client framework, generally functions as an aide to a developer writing a new AJAX application. These frameworks focus on providing the developer with a number of prewritten widgets and effects that they can easily incorporate into their AJAX applications. The differences between the two styles of frameworks, including how they transfer data between the client and server and how you determine which framework is in use, are explored in more detail in Chapter 6. Due to the differences in functionality these two classes of AJAX frameworks provide, they will be analyzed in different ways in this chapter. This chapter covers several AJAX frameworks of both the proxy and client types. For each server framework, information is provided about the framework, common installa- tion steps, and their potential effect on security. A discussion of common exposures that could lead to security issues is also included. While they will be marked with the “Attack” icon, these issues are not in and of themselves attacks but rather exposures that could easily lead to security issues. In the case of client frameworks, information is provided here about the framework as well as a discussion of a main attack surface, the serialization format. DIRECT WEB REMOTING Direct Web Remoting (http://getahead.org/dwr/) is a true proxy framework for web applications written in Java. DWR allows a developer to write his or her web application in Chapter 7: AJAX Framework Exposures 179 Java, and then use DWR dynamically to generate corresponding JavaScript. The generated JavaScript can then be sent down to clients, where it can be used to call methods in the Java web application. When a method is called, the data is sent to the DWR servlet on the application server. The DWR servlet acts to marshal the data back and forth between the JavaScript in the client and the Java methods in the web application. Installation Procedures The following steps are taken by the developer to install DWR: 1. First, ensure you have a correctly functioning Java Servlet container such as Apache Tomcat or IBM WebSphere. 2. Download the latest version of DWR from http://getahead.org/dwr/ download. Once downloaded, the dwr.jar fi le should be moved to the WEB- INF/lib directory of the web application. 3. Edit confi guration fi les to add DWR functionality. First, the WEB-INF/web.xml file should be edited to add new <servlet> and <severlet-mapping> sections for DWR, as described at http://getahead.org/dwr/getstarted. This step has the potential to affect the security of the application, as the configuration specified by the DWR web site enables debugging mode by default. Ensure that once testing is complete, debug mode is disabled. 4. Write a dwr.xml confi guration fi le, which should be placed in the WEB-INF directory. This step also has the potential to affect the security of the application, because this fi le will defi ne which classes DWR will generate into JavaScript that is sent to the client. 5. Finally, the DWR-generated JavaScript fi les are added to the HTML fi les of the web application to incorporate the newly created DWR functionality. Unintended Method Exposure Popularity: 4 Simplicity: 6 Impact: 3 Risk Rating: 4 Unintended method exposure can be an issue for developers using DWR. As discussed in the upcoming Case Study on exposures, web application developers may have previously relied on the fact that users of their web application would be aware of only methods about which they were explicitly informed. With Web 2.0 applications, however, the line of what functionality gets exposed to users has often shifted. This is partially the case with DWR applications. Although, by default, DWR doesn’t expose all classes in a web application, once a class has been marked to be exposed it will expose all methods in this class. If a class contains methods that should not be exposed to users, developers will need to use the include and exclude elements to perform finer grained access control. Fortunately for developers, testing for this exposure is far easier for them [...]... 180 Hacking Exposed Web 2.0 than for attackers For the developers, before each class is exposed, the included methods should be quickly reviewed to ensure that only approved methods are being exposed On the attacking side, attackers will need to obtain a full list of methods exposed by the application and then comb through this list to attempt to find any unintentionally exposed sensitive... come as a shock to web developers if their web applications were already considered secure For example, many developers might not know a shift to Web 2.0 style functionality will affect security Due to the nature of a Web 1.0 style web application, developers have a clearly defined idea of what information gets sent to the user and what doesn’t With the shift to a Web 2.0 style web application, the... practice, web applications often have numerous items such as internal methods and debug functionality that should not be exposed to clients—all of this makes migration to a Web 2.0 style web application a security concern This case study discusses the following: • The Web 2.0 migration process • Common exposures • Internal methods • Debug functionality • Hidden URLs • Full functionality WEB 2.0 MIGRATION... frameworks are available to developers These frameworks can vary wildly in the way they add Web 2.0 style functionality to an existing web application Some frameworks require a full rewrite of the application to use the framework’s Web 2.0 libraries, while others 189 simply take the existing web application and add Web 2.0 style functionality This functionality can be achieved in a number of ways, with some... technology in which a web application might be written, such as PHP or Java Serialization Security jQuery, by default, provides the user with four types of serialization formats: json, xml, html, and script If either the json or script type are used with the application, it will by default be vulnerable to JavaScript hijacking This is because the HTTP GET method is 187 188 Hacking Exposed Web 2.0 the default... Sun Java Software Development Kit (SDK) installed 2 Download the latest version of GWT from http://code.google.com/ webtoolkit/download.html 181 182 Hacking Exposed Web 2.0 3 Use the supplied applicationCreator script to generate the files needed to support the soon-to-be-created Java web application Write and debug the application in the Java integrated development environment (IDE) of choice until... other AJAX frameworks, Sajax offers web application developers no built-in protection against CSRF attacks With no built-in protection, developers need to build CSRF protection directly into their applications To determine whether a Sajax application is vulnerable to CSRF attacks, an attacker views the HTTP GET and POST requests to the 185 186 Hacking Exposed Web 2.0 application If the requests contain... section that follows 6 Once the desire methods have been exposed, two final operations are performed First, start Xajax and tell it to handle incoming clients by calling the processRequests() method Last, insert the dynamically generated JavaScript into the HTML sent to the client by invoking the printJavascript() Xajax method 183 184 Hacking Exposed Web 2.0 Unintended Method Exposure Popularity: 4 Simplicity:... CASE STUDY: WEB 2.0 MIGRATION EXPOSURES During a typical web technology migration, the traditional concerns that spring to mind are reliability and performance Developers will often hope that things will “just work,” although they may worry that the new technology will cause their web application to crash right from the start However, in the case of migrating a web application to Web 2.0 style functionality,... during a Web 2.0 migration to ensure that only methods that should truly be public are exposed to clients and anything dealing with internal functionality remains hidden Additionally, once a Web 2.0 application migration is complete, developers must verify that information that is sent to users is properly sanitized and that no private information is being leaked As with any new technology, Web 2.0 style . earnest. 177 7 AJAX Framework Exposures Copyright © 20 08 by The McGraw-Hill Companies. Click here for terms of use. 1 78 Hacking Exposed Web 2. 0 E xposures of AJAX frameworks are generally quite. Development Kit (SDK) installed. 2. Download the latest version of GWT from http://code.google.com/ webtoolkit/download.html. 1 82 Hacking Exposed Web 2. 0 3. Use the supplied applicationCreator. following: • The Web 2. 0 migration process • Common exposures • Internal methods • Debug functionality • Hidden URLs • Full functionality WEB 2. 0 MIGRATION PROCESS A Web 1 .0 style web application