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 identiﬁes the Session ID, a box will pop up conﬁrming this.
6. After conﬁrming that WebScarab can identify the Session ID, set the sample size ﬁ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 Identiﬁ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
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.
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.
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
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.
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.
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.
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 ﬂags and properties, as well as any site-speciﬁc items for common security misconﬁgurations.
nguon tai.lieu . vn