(BQ) Part 2 book Ajax security has contents: Attacking client side storage, offline ajax applications, request origin issues, web mashups and aggregators, web mashups and aggregators, javascript worms, testing ajax applications, analysis of ajax frameworks.
8 Attacking Client-Side Storage Myth: The client’s machine is a safe place to store data There are several security issues when Ajax applications store data on the client Not only is client-side storage easily viewed or modified by an attacker, client-side storage methods can also leak access to these storage spaces to untrusted third parties This can allow an attacker to remotely read all offline data stored on the client by an Ajax application Even security-conscious developers who explicitly avoid putting sensitive data in client-side storage systems can inadvertently so when they use client-side storage to cache data tables or trees Only by fully understanding the access methods of each clientside storage method and implementing expiration policies and proper access control can a developer truly secure an Ajax application that utilizes client-side storage OVERVIEW OF CLIENT-SIDE STORAGE SYSTEMS The client-side portions of Web applications have been hobbled from fully participating as major components of an application by four roadblocks: • • • Sufficient penetration of (semi-) standards compliant browsers allowing developers to easily write cross-platform client-side programs Sufficient penetration of personal computers fast enough to parse and interpret large and complex client-side programs A means to transmit data back and forth between the client and server without interrupting the user’s experience 201 CHAPTER • ATTACKING CLIENT-SIDE STORAGE A large, persistent data storage system on the client to persist the input and output of our computations between different pages The first requirement was satisfied by time as Web standards matured and Web developers and users pressured the browser manufactures to conform to standards It is now far easier to write cross-browser JavaScript than in the Web dark ages of the 1990s Moore’s Law, which states computing power doubles every 18 months, took care of the second requirement Modern computers run complex interpreted programs inside a browser much faster than before Remember how long Java applets took to run in the mid 1990s on a Pentium 90 with 32MB of RAM? The third requirement was handled by the pillar of Ajax: the XMLHttpRequest object Ajax applications seamlessly move data without the long, full page refreshes of yesteryear The final requirement has recently been met with the rise of JavaScript-accessible client-side storage systems Offline Ajax is a perfect example Offline Ajax allows users to access Web applications without being connected to the Internet We discuss offline Ajax application in depth in Chapter 9, “Offline Ajax Applications.” However, client-side storage is essential for this capability The benefits of client-side storage include reducing Ajax traffic by storing data on the client, improving a slow network connection, or persisting data across domains or browser instances In this chapter we examine several different client-side storage methods and discuss how to use them securely Specifically, we examine HTTP cookies, Flash Local Shared Objects, Mozilla’s DOM storage, and Internet Explorer’s userData Before we dive into the different implementations for client-side storage, we should examine how long the data is stored on the client There are two classifications, persistent and nonpersistent, which denote how long data is stored in a system Nonpersistent data is stored temporarily on the client and is discarded when the user closes the Web browser Persistent data is stored on the client in a more permanent capacity It survives if the user closes and reopens the browser, or even if she reboots her machine Data stored persistently usually has an expiration date Much like a jug of milk in your fridge, once the expiration date for the persistent data has passed, the Web browser deletes it When developers are selecting a data storage system it is important to know whether the data stored in the system will be stored persistently GENERAL CLIENT-SIDE STORAGE SECURITY As we learned in the myth at the start of this chapter, there are several significant security concerns related to storing data on the client When we examine each method for storing data on the client, readers should keep several questions in mind Knowing the answers will help you pick the most appropriate and secure client-side storage method for your application These questions include: 202 OVERVIEW • • • • • • • • • OF CLIENT-SIDE STORAGE SYSTEMS What browsers are supported? While there are some frameworks like Dojo.Storage that attempt to abstract away the differences between storage methods, you could end up with a poorly implemented feature depending on which browser your users access your application with Does the storage method offer persistent, nonpersistent, or both forms of data storage? If you can only store data persistently, it is up to you to implement code to delete and purge data when appropriate How much data can you store? What is the default capacity? What is the maximum capacity? It does not matter how appealing the other features of a storage method are if it cannot offer enough space for your application What data types can you store? If a storage method can only save strings, then you will have to handle serialization and deserialization of other data types As mentioned earlier, this is a step that attackers like to focus on because it is very easy to cause Denial of Service attacks in custom serialization and deserialization code Be aware of which storage methods force you to some heavy lifting What are the access policies for the storage method? What other domains, services, and Web pages can access the data by default? What features does the storage method have that allow you to limit who can access the data? How you clean up or remove old data? Leaving unnecessary data around isn’t just sloppy, it can also be a security vulnerability While no secret can be protected on the client, leaving the sensitive data scattered all around for long periods of time isn’t going to help matters Pay attention to which methods automatically delete data for you or allow you to set an expiration date for the data How easy is it for the user to delete the data? If you pick a volatile storage method, your application will need to handle situations in which the client-side data disappears You did write your application to handle errors gracefully, right? How easy is it to read the data stored on the machine? Attackers can definitely read any data you store on the client, regardless of the method you pick The real question is, how much work must an attacker perform to read what is stored? Never, never, never store anything secret in client-side storage! How easy is it to modify the data stored on the machine? Attackers can definitely modify any data you store on the client, regardless of the method you pick The real question is, how much work must an attacker perform to write over the stored data? This is an excellent vector to launch attacks and is another example of input that requires validation 203 CHAPTER ATTACKING CLIENT-SIDE STORAGE HTTP COOKIES HTTP cookies are one of the most basic forms of client-side storage To fully appreciate the limitations and security issues of using cookies as a storage mechanism, we must explorer the history of cookies In case you missed the memo, HTTP is a stateless protocol This means that the server treats each request as an isolated transaction that is not related to any previous request Cookies were created in 1994 by Netscape as a means to impose a state-keeping mechanism on top of the HTTP Fundamentally, cookies are a mechanism to allow the Web server to store a small amount of data on a user’s machine A user’s Web browser attaches this cookie data to outgoing requests back to the Web server that set the data.1 Figure 8-1 shows the browser’s cookie jar—where cookies the Web browser has received are stored Figure 8-1 The browser’s cookie jar displays a list of cookies the browser has and all of their properties To impose state-keeping, a Web server can store a unique identifier for each visitor inside a cookie and send the cookie to the visitor’s Web browser Every time that visitor requests a page from that Web server, their Web browser attaches the cookie containing the unique identifier to the outgoing HTTP request This allows the Web server to differentiate between different, distinct users accessing their resources Remember, each user has a This is actually a simplification We discuss how developers can control which cookies get sent to which Web servers later in this section 204 HTTP COOKIES different unique identifier This differentiation allows Web applications on the Web server to store session information about each user.2 Some common uses of session data include keeping the contents of a shopping cart or a user’s language preference The following are the HTTP headers of a Web server’s response where a cookie is set HTTP/1.1 200 OK Server: Microsoft-IIS/5.1 Date: Wed, 06 Jun 2007 00:05:42 GMT X-Powered-By: ASP.NET Cache-Control: private Content-Type: text/html; charset=utf-8 Content-Length: 909 Connection: Keep-Alive Set-Cookie: shoppingCart=51349,90381,7744; Expires=Tue, 03-Jun-2008 05:00:00 GMT; Path=/Assign/Shop/ The Set-Cookie header is what tells the Web browser to store a cookie In the preceding code it appears that the cookie represents some kind of online shopping cart Notice that in addition to a name/value of data to store, the Web application is able to specify other attributes of the cookie For example, this cookie declaration sets an expiration date for the cookie This means the cookie is stored persistently on the client’s machine until that expiration date Once the expiration data has passed, the Web browser will automatically delete that cookie There is no real limit on how far in the future the expiration date of a cookie can be set Sharp-eyed readers will notice in Figure 8-1 that the PREF cookie that Google sets does not expire until 2038! If a cookie is set, but is not given an expiration date, it is considered a nonpersistent cookie and will be discarded when the user closes the Web browser Thus, the use of the Expires directive allows Web applications to store arbitrary data persistently on the client inside a cookie, while excluding the Expires directive provides nonpersistent client-side data storage It’s paramount to remember that cookies were designed to store small amounts of data on the client’s machine to impose state on top of HTTP They weren’t intended to be a general client-side storage mechanism This has profound consequences For example, the Web browser sends the appropriate cookies to the Web server on each and every request There is no way to change this behavior In fact, it makes sense that the Web browser would send the appropriate cookies on every request Without a cookie containing a unique identifier allowing the Web to differentiate incoming requests for the same As we saw in the “Session Hijacking” section of Chapter 3, if an attacker gains access to a user’s unique identifier he can impersonate that user by making fraudulent requests with the stolen unique identifier 205 CHAPTER ATTACKING CLIENT-SIDE STORAGE resource, all requests would revert to being stateless.3 The Web browser sends the appropriate cookies to each and every page because the Web browser has no idea which Web pages on the server actually use the data and which don’t So, the browser simply sends all appropriate cookies all the time for all pages, regardless of whether the server-side code of the Web application actually uses cookies or not We discuss the security problems of this design later in this section COOKIE ACCESS CONTROL RULES Surely we aren’t transmitting every cookie we have to every Web site we visit, are we? The answer is: No Only the cookies that are appropriate when requesting a given Web page are added to the outgoing request What we mean by appropriate cookies? Well, cookies can have access control rules that tell the Web browser which pages should get the cookie For example, a cookie can tell the browser what domains, what protocols, or what paths it is valid for When a browser wants to request a page from a Web server, it checks the URL of the resource against all the cookies in the browser’s cookie jar If the URL passes all the access control rules for a cookie, then that cookie is added to the outgoing request In Figure 8-1, we can see that the PREF cookie used by Google should only be sent with requests to URLs ending in google.com, regardless of the URLs path or use of SSL Cookie access control rules form the basis for the access control rules used by all other client-side storage methods We will examine these rules in fine detail now, and note any differences from these ground rules in the specific sections covering the other client-side storage methods Cookies can define access rules using three different properties These rules determine which cookies are attached to an outgoing request These properties are: which domain names can access the cookie; which path or folder structure is needed to access the cookie; and whether the cookie must be sent over a secured connection or not By default, cookies will be sent with all requests to the same domain that set the cookie, regardless of the path and regardless of whether the channel is secure or not Figures 8-2 through 8-4 illustrate the access control of a default cookie Technically, there are other methods of differentiating users between requests other than cookies, such as using URL session state, but cookies are the most commonly used method 206 HTTP COOKIES GET/Items/Buy.php HTTP/1.1 Host: www.store.com … Cookie: item=8441 HTTP/1.1 200 Ok … Figure 8-2 www.store.com:80 Normal HTTP transaction where www.store.com sets a cookie with default access control GET/Shopping.php HTTP/1.1 Host: www.store.com … HTTP/1.1 200 Ok … Set-Cookie: item=8441 Figure 8-3 www.store.com:80 The Web browser sends this cookie to all pages on www.store.com regardless of the page’s path GET/Checkout/ HTTP/1.1 Host: www.store.com … Cookie: item=8441 HTTP/1.1 200 Ok … www.store.com:443 Figure 8-4 The cookie is also sent to an SSL-enabled Web server running on a different port of same domain that issued the cookie Figure 8-2 shows www.store.com setting a cookie (item=8441) As you can see from the Set-Cookie header, this cookie has no special attributes limiting its domain or path Because there is no Expires attribute, the cookie that is created is a nonpersistent cookie named item containing the value 8441 with default access control Figure 8-3 shows that this cookie is sent in all Web page requests to www.store.com, regardless of the path to that Web page The item cookie is even sent to other HTTP services running on other 207 CHAPTER ATTACKING CLIENT-SIDE STORAGE ports on www.store.com Figure 8-4 shows the Web browser sending the item cookie to an SSL-enabled Web server running on port 443 of www.store.com The flip side of this is that any cookies set in the SSL version of the Web site at www.store.com:443 will also be sent in requests for pages on the non-SSL Web server at www.store.com:80 As expected, Figure 8-5 shows that the item cookie assigned by www.store.com is not transmitted to other domains such as www.other.com This prevents a malicious Web site such as evil.com from reading the cookies stored for bank.com Figure 8-6 shows us that using the default access control restrictions, cookies assigned in the www subdomain of store.com are not transmitted to other subdomains of store.com such as support This applies to domain names that are below (i.e., domain names that are subdomains of) the domain that set the cookie For example, cookies set by www.store.com will not be sent to subdomains of www.store.com such as test.www.store.com GET/faq.html HTTP/1.1 Host: www.other.com … HTTP/1.1 200 Ok … Figure 8-5 www.other.com:80 The item cookie from www.store.com is not sent to other domains GET/Contact.aspx HTTP/1.1 Host: support.store.com … HTTP/1.1 200 Ok … Figure 8-6 support.store.com:80 By default, cookies are not transmitted to other subdomains So what happens if Web sites in two different domains want to access each others’ cookies? Consider a company where Web applications on the press relations department’s Web site (pr.company.com) need to read cookie data from Web applications on the sales department’s Web site (sales.company.com) This can be accomplished with the Domain attribute for a cookie This allows a Web application to specify what other domains can 208 HTTP COOKIES access a cookie Figure 8-7 shows a page on sales.company.com that sets a cookie using the Domain attribute Figure 8-7 The Sales department’s Web site can set a cookie that can be read by other Web sites in the *.company.com domain hierarchy The Set-Cookie header for this response is Set-Cookie: sessionid=901-42-1861; Domain=.company.com; Expires=Fri, 06-Jun-2008 02:41:25 GMT; Path=/ The Domain attribute tells the Web browser that this cookie should be sent for any Web site whose domain ends with company.com Figure 8-8 shows the PR department’s Web site reflecting the value of the sessionid cookie that was set in the sales.company.com domain and received from the Web browser There is one major limitation of the Domain attribute: The domain name must contain at least two periods This is sometimes referred to as the Two Dots Rule.4 For example company.com is a valid Domain attribute value but com or net are not This rule exists to limit cookie sharing to within subdomains of a subdomain of a top-level domain This means that subdomains of company.com can share cookies but company.com and store.com cannot share cookies If this rule didn’t exist, Web sites could set cookies that would get transmitted to every com or org Web site the There is an exception to the Two Dots Rule: country code top-level domains (ccTLDs) such as co.uk or co.jp Even though these contain two dots, they define domain access that allows all the Web sites in co.uk or co.jp to read each others’ cookies For ccTLDs you much specify three dots like store.co.uk In the past, many Web browsers had bugs that allowed setting cookies for entire ccTLDs For the most part these bugs have been fixed 209 CHAPTER ATTACKING CLIENT-SIDE STORAGE user visits! Sharing between high level Web sites would almost never be a good idea from a security and privacy perspective, and the browsers not allow it If you are designing applications that need to this, you probably need to rethink your architecture Figure 8-8 pr.company.com is able to access cookies from sales.company.com that have the appropriate Domain attribute The access control for cookies also permits a developer to specify which folders inside of a domain have access to the cookie This is accomplished with the Path attribute Whereas the Domain attribute tells the Web browser, “Only send this cookie to Web pages whose domain ends in X,” the Path parameter tells the Web browser, “Only send this cookie to Web pages whose path starts with X.” For example, consider the situation in which http://www.store.com/Products/OldStock/index.php sets a cookie with an attribute Path=/Products/ Table 8-1 explains the reasons different Web pages will or will not receive this cookie Table 8-1 URLs on store.com and whether they can access a cookie whose path is restricted to /Products/ URL Can access cookie? Reason http://www.store.com/Products/ Yes In allowed path http://www.store.com/Products/Specials/ Yes In allowed path https://www.store.com/Products/Specials/ Yes In allowed path, SSL version of site in same domain 210 INDEX LSOs (Local Shared Objects), 218-225 overview, 225-226 security, 202-203 client-side synchronization, 144 clobbering functions, 178-180, 183-184 accidental function clobbering, 176-178 Clover, Andrew, 370 CNN.com, 288-289 code comments, multiple languages, 129-130 code injection attacks, 168 ColdFusion, array indexing, 127 command execution, 63-66 comments code comments, multiple languages, 129-130 security mistakes when writing client-side code, 166-167 computer viruses, traditional viruses, 356-358 configuring ASP.NET, 426-427 Confused Deputy Problem, 311 constructing JavaScript worms, 361-363 mashups, 304-306 Ajax, 306-307 Content, 330-333 cookies, 87 attack surfaces, 84-85 HTTP Cookies, 204-206 access control rules, 206-211 lifetime of cookies, 215 overview, 216-217 security, 216-217 storage capacity, 211-215 security, 211 coupon systems, hacking, 26-32 crawlers, 400 cross-directory attacks, client-side storage, 242 cross-domain attacks, client-side storage, 241 cross-domain permissions, 224 cross-domain scripting, 222 cross-domain scripting permissions, 222 cross-port attacks, client-side storage, 243 Cross-Site Scripting (XSS), 67-72, 280 DOM-based XSS, 71 reflected XSS, 71 stored XSS, 71 CSRF (Cross-Site Request Forgery), 75-76, 284, 430-431 Sajax and, 430-431 CSS (Cascading Style Sheet), 332 data mining, 334-336 embedded program logic, 345-346 vectors, 347-348 modifying browser caches, 348-351 CSS pseudoclasses, 370 D dangers of client-side SQL injection, 262-264 data protecting (Dojo.Offline), 266-267 revealing sensitive data to users, security mistakes when writing client-side code, 165-166 serialized data, validating, 120-122 data mining, CSS, 334-336 457 INDEX data transformation, raw data to HTML (security mistakes when writing client-side code), 167-172 data types, web applications as APIs, 158 Database, Google Gears, 247 accessing, 257 deadlocks, asynchronicity, 139-144 debug(), 176 debugging ASP.NET, 426-427 defects, security defects, 394 testing for, 396 defense-in-depth, 131 degraded security, aggregate sites, 325 delayed loading, hijacking, 184-189 Denial-of-Service (DoS), 77 detecting dynamic code execution, regular expressions, 118 vulnerabilities, 401-403 DHTML (dynamic HTML), 11 Direct Web Remoting (DWR), 432-433 document.createElement(), 283 documentation, security mistakes when writing client-side code, 166-167 Dojo.Offline, offline Ajax applications, 264-265 passwords and keys, 268 protecting data, 266-267 protecting keys, 265-266 Dojo toolkit, 309 DOM-based XSS, 71 DOM storage, 226-227, 231-233 Firefox, 232 global storage, 229-231 458 overview, 234 security, 233 session storage, 227-229 Dos (Denial-of-Service), 77 DWR (Direct Web Remoting), 432-433 dynamic code execution, JavaScript source code, 115 dynamic HTML (DHTML), 11 E email, HTML, 380 embedded program logic, 345-346 encryption, 264 asymmetric key encryption, 326 Dojo.Offline, 264-265 passwords and keys, 268 protecting data, 266-267 protecting keys, 265-266 public key encryption, 326 trivial encryption algorithm, 30 ethical hackers, 91 EXECUTE statement, 103 execution infectors, 356 F Fiddler, 397 file enumeration, 66-67 file extraction, 66-67 Firebug, attaching breakpoints to JavaScript, 162 Firebug extension (Firefox), 27 INDEX Firefox DOM storage, 232 Firebug extension, 27 HTTP, User-Agent, 275 style information, viewing, 347 Flash JavaScript worms, 361 LSOs (Local Shared Objects), 218-226 Flickr, 317 form inputs, attack surfaces, 83-84 function clobbering, 178-180, 183-184 accidental function clobbering, 176-178 function scope, 134 functional defects, 393-394 functional information, 330-333 functions, shimming, 179-182 fuzzing, 72, 402 G Garrett, Jesse James, GetUsageStatistics, 160 global CSS, embedded program logic, 345-346 global scope, 134 global storage, 229-231 Gmail widgets, 324 Google, 325 Google Gears, offline Ajax applications, 247 Database, accessing, 257 LocalServer, 253-256 security features, 248-251 SQL Injection, 258-262 dangers of, 262-264 WorkerPool, 251-252 Google Sitemap Protocol, 298 Google Suggest, 276-278 granular server APIs, security mistakes when writing client-side code, 161-164 H hacking, 399 HighTechVacations.net, 26 Ajax API, 36-42 client-side data binding, 32-36 coupon system, 26-32 headers, attack surfaces, 85-86 hex editors, viewing XML files, 237 hidden form inputs, attack surfaces, 86 HighTechVacations.net, 26 Ajax API, attacking, 36-42 client-side data binding, attacking, 32-36 coupon system, hacking, 26-32 hijacking Ajax frameworks, 176 accidental function clobbering, 176-178 function clobbering, 178-180, 183-184 JSON APIs, 190-195 defending against, 196-199 object literals, 195 root of, 195-196 459 INDEX on-demand Ajax, 184-187, 189 session hijacking, 72-74 HOOK, 187-189 HousingMaps.com, 295, 303 Ajax proxies, attacking, 312-314 HTML, 5, 26 transforming raw data to, security mistakes when writing client-side code, 167-172 HTML email, 380 HTTP (Hyper Text Transfer Protocol), 273-274 sending requests with JavaScript, 282-284 User-Agent, 275-276 HTTP attacks prior to Ajax, JavaScript, 284-285 HTTP Cookies, client-side storage, 204-206 access control rules, 206-211 lifetime of cookies, 215 overview, 216-217 security, 216-217 storage capacity, 211-212, 214-215 HTTP Response Splitting, 216 human requests, 280-281 human Web, 296-297 Hyper Text Transfer Protocol (HTTP), 273-274 sending requests with JavaScript, 282-284 User-Agent, 275-276 460 I Identifiers, unique identifiers, 74 IDS (intrusion detection systems), 63, 313 integrated IDS, 313 IFrame jails, 320-323 IFrame remoting, 286-287 incrementing integers, 74 indexing, array indexing, 126-128 information theft, JavaScript, 365-366 injection advanced injection techniques for Ajax, 62-63 SQL Injection, 51-56, 59-61, 168-170 blind SQL Injection, 56-59 client-side SQL Injection, dangers of, 262-264 Google Gears, 258-262 XPath Injection, 60-62 XPath Injection, 60-61, 170 input validation, 98-99 apostrophes, 109 blacklisting, 99-102 client-side input validation, 268-269 mashups, 314-316 regular expressions, 109 special considerations, 109-111 treating the symptoms instead of the disease, 102-105 user-supplied content, 122-123 whitelisting, 105-108 integrated IDS, 313 INDEX Internet, history of 2000s, 298-299 beginning of, 296-297 mid 90s, 297-298 Web services, 299-301 Internet Explorer, hijacking on-demand Ajax, 186 Internet Explorer userData, 235-239 Security, 240 interpreted language, 18 intranets, JavaScript, 366-369 intrusion detection system (IDS), 63, 313 IPS (intrusion prevention system), 313-314 J Java EE, 431 DWR (Direct Web Remoting), 432-433 JavaScript, 6-9 attaching breakpoints with Firebug, 162 monitors, 185 namespaces, 178 quirks, 132 interpreted languages, 132-133 runtime errors, 133 weakly typed, 133-135 request origin uncertainty and, 276 Ajax requests from the Web server’s point of view, 276-279 HTTP attacks pre-Ajax, 284-285 human requests, 280-281 hunting content with XMLHttpRequest, 286-290 sending HTTP requests, 282-284 XSS/XHR attacks, 290-292 Same Origin Policy, 10-11 session states, security mistakes when writing client-side code, 164-165 JavaScript framework client-side code, 435 prototypes, 435-437 JavaScript frameworks, 434 JavaScript Object Notation (JSON), 32, 304 hijacking, 190-195 defending against, 196-199 object literals, 195 root of, 195-196 mashups, 307 JavaScript Reverser, 27 JavaScript source code, validating, 114-120 JavaScript URLs, 345 JavaScript worms, 355, 359-361 constructing, 361-363 Flash, 361 lessons learned from, 387-388 limitations of, 363-364 overview, 355-356 payloads, 364 browser history theft, 370-371 exploring intranets, 366-369 information theft, 365-366 stealing search engine queries, 371-372 propagating, 364 461 INDEX Samy worm, 373-374 conclusions, 379-380 how it worked, 374-377 payloads, 377-378 traditional computer viruses, 356-358 Yamanner worm, 380-383 conclusion, 384-387 payload, 383-384 John the Ripper, 36 JSON (JavaScript Object Notation), 32, 304 hijacking, 190-195 defending against, 196-199 object literals, 195 root of, 195-196 mashups, 307 K–L keys (Dojo.Offline) passwords, 268 protecting, 265-266 knowledge-based resource enumeration, 48 known plaintext attack, 267 languages interpreted language, 18 multiple languages, 125-126 array indexing, 126-128 code comments, 129-130 developers, 130-131 string operations, 128-129 LAPSE (Lightweight Analysis for Program Security in Eclipse), 408-409 lastdata.com, 386 462 Layer Zero attack, 76 lazy loading, hijacking, 184-189 lifetime of HTTP Cookies, 215 limitations of JavaScript worms, 363-364 List Mania, 258 listening to traffic, 72 livelocks, 142 local scope, 134 Local Shared Objects (LSOs), 218-225 local XSS, 71 LocalServer, Google Gears, 247, 253-255 poisoning, 255 security, 256 look and feel hacks, 337-340 advanced look and feel hacks, 341-345 low-level tools for browsing the Web, 397-398 LSOs (Local Shared Objects), 218-225 overview, 225-226 Lycos, 298 M machine Web, 297-299 MapQuest, 12 markup languages, validating, 111-113 mashups, 295, 301, 304 Ajax proxies, attacking, 310-314 ChicagoCrime.org, 302-303 Constructing, 304-306 with Ajax, 306-307 HousingMaps.com, 303 input validation, 314-316 META tags, 297 INDEX method signatures, web applications as APIs, 158 Microsoft Windows Metafile (.wmf), 90 modifying browser caches, 348-351 monitors, JavaScript, 185 Moore’s Law, 202 Mozilla-derived browsers, JSON hijacking, 195 MyLocalWeatherForecast.com Ajax version, 152-156 comparing both versions, 156 standard, non-Ajax version, 150-152 MySpace look and feel hacks, 337 Samy worm, 373-374 conclusions, 379-380 how it worked, 374-377 payloads, 377-378 offline Ajax applications, 245-247 client-side input validation, 268-269 copying applications to user’s local machine, 270 Dojo.Offline, 264-265 passwords and keys, 268 protecting data, 266-267 protecting keys, 265-266 Google Gears, 247 accessing Database, 257 LocalServer, 253-256 security features, 248-251 SQL Injection, 258-264 WorkerPool, 251-252 pushing part of the application to local Web servers, 270 on-demand Ajax, hijacking, 184-189 operations, string operations, 128-129 origin of Ajax application attack surfaces, 96-97 N–O namespaces, JavaScript, 178 Ned’s Networking Catalog, 127 Netcat, 397 NetVibes, 324-325 network traffic analyzers, 151 non-shrinkwrapped applications, 91 obfuscate code, 149 obfuscation, 173-174 object literals, hijacking, 195 obscurity, security through, 172-173 obfuscation, 173-174 P P3P (Platform for Privacy Preferences Project protocol), 298 page lifecycle events, ASP.NET AJAX, 414-415 PageFlakes, 326 parameter manipulation, 50-51 blind SQL Injection, 56-59 command execution, 63-66 file extraction/file enumeration, 66-67 protecting Web applications from, 77-78 session hijacking, 72-74 463 INDEX SQL Injection, 51-56, 59-60 XPath Injection, 60-62 XSS (Cross-Site Scripting), 67-72 parameters, query parameters (attack surfaces), 86-89 Paros Proxy, 397, 406-407 passive hunting, 286 passwords, keys (Dojo.Offline), 268 payloads JavaScript worms, 364 browser history theft, 370-371 exploring intranets, 366-369 information theft, 365-366 stealing search engine queries, 371-372 Samy worm, 377-378 Yamanner worm, 383-384 penetration tests, 49 permissions cross-domain permissions, 224 cross-domain scripting permissions, 222 phishers, look and feel hacks, 338 phishing, 76-77 look and feel hacks, 339 PHP, 427 Sajax, 427-429 CSRF (Cross-Site Request Forgery), 430-431 Platform for Privacy Preferences Project (P3P) protocol, 298 poisoning LocalServer, 255 464 presentation information, 330-333 CSS, 332, 347 data mining, 334-336 embedded program logic, 345-346 vectors, 347-348 embedded program logic, 345-346 look and feel hacks, 337-340 advanced look and feel hacks, 341-345 presentation layer, attacking, 333-334 presentation layer attacks, preventing, 352 preventing presentation layer attacks, 352 pricing logic, 435 propagating JavaScript worms, 364 protecting data, Dojo.Offline, 266-267 from JSON hijacking, 196-199 keys, Dojo.Offline, 265-266 from request origin uncertainty, 292-293 Web applications from resource enumeration and parameter manipulation, 77-78 prototypes, JavaScript frameworks, 435-437 proxy listeners, 400 public key encryption, 326 public storage, 230 Q–R QA engineers, role of, 398 Qos (Quality of Service), 77 Quality Assurance team, 398-399 INDEX Quality of Service (Qos), 77 queries, code injection attacks, 170 query parameters, attack surfaces, 86-89 race conditions, asynchronicity, 135-139 Rager, Anton, 285 reflected XSS, 71 regular expressions detecting dynamic code execution, 118 input validation, 109 remote scripting, 283 removeAttribute() function, 236 RemoveServerHeader, 152 reporting security attacks, 90-92 request origin uncertainty, 273 JavaScript and, 276 Ajax requests from the Web server’s point of view, 276-279 HTTP attacks pre-Ajax, 284-285 human requests, 280-281 hunting content with XMLHttpRequest, 286-290 sending HTTP requests, 282-284 XSS/XHR attacks, 290-292 protecting from, 292-293 resource enumeration, 46-50 blind resource enumeration, 46-48 knowledge-based resource enumeration, 48 protecting Web applications from, 77-78 revealing sensitive data to users, security mistakes when writing client-side code, 165-166 rich user input, validating, 111 binary files, 113-114 JavaScript source code, 114-120 markup languages, 111-113 serialized data, 120-122 risk of users who browse the Web without Web browsers, 397-398 robots, 273 RSS, field names and data types, 113 RSS feed, validating, 112 runtime errors, JavaScript, 133 S Sajax, 427-429 CSRF (Cross-Site Request Forgery), 430-431 Same Origin Policy, JavaScript, 10-11 Samy worm, 373-374 conclusions, 379-380 how it worked, 374-377 payloads, 377-378 screen readers, 396 ScriptService, 417-419 versus UpdatePanel, 419-420 search engine queries, stealing, 371-372 Secure Sockets Layer (SSL), protecting Web applications, 78 security aggregate sites, 324-327 Ajax, Ajax applications, 18 client-side storage, 202-203 cookies, 211 465 INDEX deadlocks, 141-144 DOM storage, 233 Google Gears, 248-251 HTTP Cookies, 216-217 Internet Explorer userData, 240 LocalServer, Google Gears, 256 through obscurity, 172-173 obfuscation, 173-174 race conditions, 137-139 resources you can trust, 144-145 thick-client applications, 16 thin-client applications, 17 security defects, 394 testing for, 396 security mistakes, client-side code comments and documentation, 166-167 data transformation performed on the client, 167-172 granular server APIs, 161-164 improper authorization, 159-160 revealing sensitive data to users, 165-166 session states stored in JavaScript, 164-165 security testing, 411 security testing tools, 399 LAPSE (Lightweight Analysis for Program Security in Eclipse), 408-409 Paros Proxy, 406-407 site cataloging, 400-401 Sprajax, 403-405 vulnerability detection, 401-403 WebInspect, 409-410 466 SecurityFocus, 91 sending HTTP requests with JavaScript, 282-284 separating presentation from content, 332 serialized data, validating, 120-122 session hijacking, 72-74 session states stored in JavaScript, security mistakes when writing client-side code, 164-165 session storage, 227-229 shimming functions, 179-182 shipping rate calculator, 392-393 testing, 393-395 shunning, 313 Sima, Caleb, 98 Simon’s Sprockets, shipping rate calculator, 392-393 testing, 393-395 Simple Object Access Protocol (SOAP), 304 site cataloging, 400-401 sniffers, 151 SOAP (Simple Object Access Protocol), 304 social engineering, 71 sociological issues, vulnerabilities, 22-23 sol file format, LSOs, 225 “someone else’s problem,” multiple languages and architectures, 130-131 source code analysis, 401 spiders, 400 Sprajax, 403-405 INDEX SQL Injection, 51-56, 59-60, 168-170 blind SQL Injection, 56-59 client-side SQL Injection, dangers of, 262-264 Google Gears, 258-262 dangers of, 262-264 XPath Injection, 60-62 SQL Injection probes, 33-35 SQLite, 258 SSL (Secure Sockets Layer), protecting Web applications, 78 static analysis, 402 stealing search engine queries, JavaScript, 371-372 storage client-side storage, 201-202 attacks, 240-243 comparing methods, 244 HTTP Cookies 204-217 Internet Explorer userData, 235-240 LSOs (Local Shared Objects), 218-226 security, 202-203 DOM storage, 226-227, 231-233 Firefox, 232 global storage, 229-231 overview, 234 security, 233 session storage, 227-229 storage capacity, HTTP Cookies, 211-215 stored procedures, 102-104 stored XSS, 71 storing backup files, 89 string operations, 128-129 style information, viewing, 347 super cookies, 218-226 surfing the Web without Web browsers, 396 risks of, 397-398 synchronization, client-side synchronization, 144 systems, client-side storage systems, 200-201 T telnet, 397 testing black-box testing, 402 for security defects, 396 Quality Assurance team, 398-399 shipping rate calculator, 393-395 thick-client applications Ajax architecture shift, 12-13 security, 16 thin-client applications Ajax architecture shift, 13-15 Security, 17 third-party Ajax frameworks, 413 ASP.NET, 413 ASP.NET AJAX (Atlas), 414-417 configuring and debugging, 426-427 ValidateRequest, 424 ViewStateUserKey, 425-426 ASP.NET AJAX ScriptService, 417-419 WSDL and, 420-424 Java EE, 431 DWR (Direct Web Remoting), 432-433 467 INDEX JavaScript frameworks, 434 client-side code, 435 prototypes, 435-437 PHP, 427 Sajax, 427-431 third-party researchers, 91 tools analysis tools LAPSE (Lightweight Analysis for Program Security in Eclipse), 408-409 Paros Proxy, 406-407 Sprajax, 403-405 WebInspect, 409-410 security testing tools, 399-400 LAPSE (Lightweight Analysis for Program Security in Eclipse), 408-409 Paros Proxy, 406-407 site cataloging, 400-401 Sprajax, 403-405 vulnerability detection, 401-403 WebInspect, 409-410 traffic, listening to, 72 transparency, vulnerabilities, 19-22 trivial encryption algorithm, 30 U unintended functionality, 394 unique identifiers, 74 universal clients, 14 Universally Unique Identifers (UUID), 74 unlinked content, 46 468 UpdatePanel ASP.NET AJAX, 414-417 versus ScriptService, 419-420 Updater (Ajax.Updater), 436 uploaded files, attack surfaces, 89-90 user agents, 274-276 user-supplied content, 122-123 user-supplied widgets, 320 userData, 235 users, seeing what sites have been visited, 370 Utils.debug(), 177 UUID (Universally Unique Identifiers), 74 V ValidateRequest, ASP.NET, 424 validating, 435 input, 98-99, 111 apostrophes, 109 blacklisting, 99-102 client-side input validation, 268-269 mashups, 314-316 regular expressions, 109 special considerations, 109-111 treating the symptoms instead of the disease, 102-105 user-supplied content, 122-123 whitelisting, 105-108 rich user input, 111 binary files, 113-114 JavaScript source code, 114-120 markup languages, 111-113 serialized data, 120-122 RSS feed, 112 INDEX vectors, CSS, 347-348 modifying browser caches, 348-351 Veness, Chris, 265 Venus Fly Trap, 286 viewing style information, 347 XML files with hex editor, 237 ViewStateUserKey, ASP.NET, 425-426 viruses, 356 vulnerabilities Ajax architecture shift, 19-22 attractive and strategic targets, 23-24 security tracking sites, 91 sociological issues, 22-23 vulnerability detection, 401-403 W Web application attacks, 45 CSRF (Cross-Site Request Forgery), 75-76 Denial-of-Service (Dos), 77 parameter manipulation, 50-51 blind SQL Injection, 56-59 command execution, 63-66 file extraction/file enumeration, 66-67 session hijacking, 72-74 SQL Injection See SQL Injection XSS (Cross-Site Scripting), 67-72 Phishing, 76-77 resource enumeration, 46-50 Web applications as APIs, 156-158 data types, 158 method signatures, 158 attack surfaces, 98 protecting from attacks, 77-78 SSL (Secure Sockets Layer), 78 Web Hypertext Application Technology Working Group (WHATWG), 226 Web services, 299-301 attack surfaces, 92, 98 Web service definitions, 94 Web service methods, 92-93 Web Services Description Language (WSDL), 94, 299 ASP.NET AJAX and, 420-424 Web spiders, 400 WebInspect, 409-410 WHATWG (Web Hypertext Application Technology Working Group), 226, 230 white box systems, 148-149 versus black box systems, MyLocalWeatherForecast.com, 150-152 Ajax version, 152-156 comparison of both versions of, 156 whitelisting, 78 input validation, 105-108 whitespace, 116-117 widgets, 319, 324 Gmail widgets, 324 user-supplied widgets, 320 wmf (Microsoft Windows Metafile), 90 WorkerPool, Google Gears, 247, 251-252 World Wide Web, history of 2000s, 298-299 beginning of, 296-297 469 INDEX mid 90s, 297-298 Web services, 299-301 worms, JavaScript , 355, 359-361 constructing, 361-363 Flash, 361 lessons learned from, 387-388 limitations of, 363-364 overview, 355-356 payloads, 364 browser history theft, 370-371 exploring intranets, 366-369 information theft, 365-366 stealing search engine queries, 371-372 propagating, 364 Samy worm, 373-374 conclusions, 379-380 how it worked, 374-377 payloads, 377-378 traditional computer viruses, 356-358 Yamanner worm, 380-383 conclusion, 384-387 payload, 383-384 WSDL (Web Services Description Language), 94, 299 ASP.NET AJAX and, 420-424 www.av3.com, 385-386 470 X XML, 11 XML files, viewing with hex editor, 237 XMLHttpRequest, hunting content, 286-290 XMLHttpRequest objects, 276-279 XPath Injection, 60-62, 170 XSS (Cross-Site Scripting), 67-72, 280 DOM-based XSS, 71 reflected XSS, 71 stored XSS, 71 XSS-Proxy, 285 XSS/XHR attacks, 290-292 Y–Z Yahoo!, Yamanner worm, 380-383 conclusion, 384-387 payload, 383-384 Yamanner worm, 380-383 conclusion, 384-387 payload, 383-384 zero-footprint, 14 This page intentionally left blank ... GET/faq.html HTTP /1. 1 Host: www.other.com … HTTP /1. 1 200 Ok … Figure 8-5 www.other.com:80 The item cookie from www.store.com is not sent to other domains GET/Contact.aspx HTTP /1. 1 Host: support.store.com... sets a cookie with default access control GET/Shopping.php HTTP /1. 1 Host: www.store.com … HTTP /1. 1 200 Ok … Set-Cookie: item=84 41 Figure 8-3 www.store.com:80 The Web browser sends this cookie... pages on www.store.com regardless of the page’s path GET/Checkout/ HTTP /1. 1 Host: www.store.com … Cookie: item=84 41 HTTP /1. 1 200 Ok … www.store.com:443 Figure 8-4 The cookie is also sent to an