idnits 2.17.1 draft-hodges-websec-framework-reqs-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) == There are 4 instances of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (Jul 2012) is 4293 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'I-D.draft-ietf-websec-strict-transport-sec-11' is mentioned on line 302, but not defined == Unused Reference: '28' is defined on line 921, but no explicit reference was found in the text == Unused Reference: '30' is defined on line 929, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-websec-strict-transport-sec' is defined on line 992, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. '0' -- Possible downref: Non-RFC (?) normative reference: ref. '1' -- Possible downref: Non-RFC (?) normative reference: ref. '2' -- Possible downref: Non-RFC (?) normative reference: ref. '3' -- Possible downref: Non-RFC (?) normative reference: ref. '4' -- Possible downref: Non-RFC (?) normative reference: ref. '5' -- Possible downref: Non-RFC (?) normative reference: ref. '6' ** Obsolete normative reference: RFC 5246 (ref. '7') (Obsoleted by RFC 8446) -- Possible downref: Non-RFC (?) normative reference: ref. '8' -- Possible downref: Non-RFC (?) normative reference: ref. '9' -- Possible downref: Non-RFC (?) normative reference: ref. '10' -- Possible downref: Non-RFC (?) normative reference: ref. '11' -- Possible downref: Non-RFC (?) normative reference: ref. '12' -- Possible downref: Non-RFC (?) normative reference: ref. '13' -- Possible downref: Non-RFC (?) normative reference: ref. '14' -- Possible downref: Non-RFC (?) normative reference: ref. '15' -- Possible downref: Non-RFC (?) normative reference: ref. '16' -- Possible downref: Non-RFC (?) normative reference: ref. '17' -- Possible downref: Non-RFC (?) normative reference: ref. '18' -- Possible downref: Non-RFC (?) normative reference: ref. '19' -- Possible downref: Non-RFC (?) normative reference: ref. '20' -- Possible downref: Non-RFC (?) normative reference: ref. '21' -- Possible downref: Non-RFC (?) normative reference: ref. '22' -- Possible downref: Non-RFC (?) normative reference: ref. '23' -- Possible downref: Non-RFC (?) normative reference: ref. '24' -- Possible downref: Non-RFC (?) normative reference: ref. '25' -- Possible downref: Non-RFC (?) normative reference: ref. '26' -- Possible downref: Non-RFC (?) normative reference: ref. '27' -- Possible downref: Non-RFC (?) normative reference: ref. '28' -- Possible downref: Non-RFC (?) normative reference: ref. '29' -- Possible downref: Non-RFC (?) normative reference: ref. '30' -- Possible downref: Non-RFC (?) normative reference: ref. '31' -- Possible downref: Non-RFC (?) normative reference: ref. '33' -- Possible downref: Non-RFC (?) normative reference: ref. '34' -- Possible downref: Non-RFC (?) normative reference: ref. '35' -- Possible downref: Non-RFC (?) normative reference: ref. '36' -- Possible downref: Non-RFC (?) normative reference: ref. '37' -- Possible downref: Non-RFC (?) normative reference: ref. '38' -- Possible downref: Non-RFC (?) normative reference: ref. '39' -- Possible downref: Non-RFC (?) normative reference: ref. '40' -- Possible downref: Non-RFC (?) normative reference: ref. '41' -- Possible downref: Non-RFC (?) normative reference: ref. '42' -- Possible downref: Non-RFC (?) normative reference: ref. '43' == Outdated reference: A later version (-14) exists of draft-ietf-websec-strict-transport-sec-11 Summary: 2 errors (**), 0 flaws (~~), 7 warnings (==), 43 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Hodges 3 Internet-Draft PayPal 4 Intended status: Standards Track Jul 2012 5 Expires: January 2, 2013 7 Web Security Framework: Problem Statement and Requirements 8 draft-hodges-websec-framework-reqs-02 10 Abstract 12 Web-based malware and attacks are proliferating rapidly on the 13 Internet. New web security mechanisms are also rapidly growing in 14 number, although in an incoherent fashion. This document provides a 15 brief overview of the present situation and the various seemingly 16 piece-wise approaches being taken to mitigate the threats. It then 17 provides an overview of requirements as presently being expressed by 18 the community in various online and face-to-face discussions. 20 Status of this Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on January 2, 2013. 37 Copyright Notice 39 Copyright (c) 2012 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 1.1. Where to Discuss This Draft . . . . . . . . . . . . . . . 4 56 2. Document Conventions . . . . . . . . . . . . . . . . . . . . . 4 57 3. Overall Constraints . . . . . . . . . . . . . . . . . . . . . 5 58 4. Overall Requirements . . . . . . . . . . . . . . . . . . . . . 6 59 5. Attacks and Threats to Address . . . . . . . . . . . . . . . . 8 60 5.1. Attacks . . . . . . . . . . . . . . . . . . . . . . . . . 8 61 5.2. Threats . . . . . . . . . . . . . . . . . . . . . . . . . 8 62 6. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 9 63 7. Detailed Functional Requirements . . . . . . . . . . . . . . . 10 64 8. Extant Policies to Coalesce . . . . . . . . . . . . . . . . . 18 65 9. Example Concrete Approaches . . . . . . . . . . . . . . . . . 19 66 10. Security Considerations . . . . . . . . . . . . . . . . . . . 19 67 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 68 12. Informative References . . . . . . . . . . . . . . . . . . . . 23 69 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 23 71 1. Introduction 73 Over the past few years, we have seen a proliferation of AJAX-based 74 web applications (AJAX being shorthand for asynchronous JavaScript 75 and XML), as well as Rich Internet Applications (RIAs), based on so- 76 called Web 2.0 technologies. These applications bring both luscious 77 eye-candy and convenient functionality--e.g. social networking--to 78 their users, making them quite compelling. At the same time, we are 79 seeing an increase in attacks against these applications and their 80 underlying technologies [1]. The latter include (but aren't limited 81 to) Cross-Site-Request Forgery (CSRF) -based attacks [2], content- 82 sniffing cross-site-scripting (XSS) attacks [3], attacks against 83 browsers supporting anti-XSS policies [4], clickjacking attacks [5], 84 malvertising attacks [6], as well as man-in-the-middle (MITM) attacks 85 against "secure" (e.g. Transport Layer Security (TLS/SSL)-based [7]) 86 web sites along with distribution of the tools to carry out such 87 attacks (e.g. sslstrip) [8]. 89 During the same time period we have also witnessed the introduction 90 of new web security indicators, techniques, and policy communication 91 mechanisms sprinkled throughout the various layers of the Web and 92 HTTP. We have a new cookie security flag called HTTPOnly [9]. We 93 have the anti-clickjacking X-Frame-Options HTTP header [10], the 94 Strict-Transport-Security HTTP header [11], anti-CSRF headers (e.g. 95 Origin) [12], an anti-sniffing header (X-Content-Type-Options: 96 nosniff) [13], various approaches to content restrictions [14] [15] 97 and notably Mozilla Content Security Policy (CSP; conveyed via a HTTP 98 header) [16], the W3C's Cross-Origin Resource Sharing (CORS; also 99 conveyed via a HTTP header) [17], as well as RIA security controls 100 such as the crossdomain.xml file used to express a site's Adobe Flash 101 security policy [18]. There's also the Application Boundaries 102 Enforcer (ABE) [19], included as a part of NoScript [20], a popular 103 Mozilla Firefox security extension. Sites can express their ABE 104 rule-set at a well-known web address for downloading by individual 105 clients [21], similarly to Flash's crossdomain.xml. Amidst this 106 haphazard collage of new security mechanisms at least one browser 107 vendor has even devised a new HTTP header that disables one of their 108 newly created security features: witness the X-XSS-Protection header 109 that disables the new anti-XSS features [22] in Microsoft's Internet 110 Explorer 8 (IE8). 112 Additionally, there are various proposals aimed at addressing other 113 facets of inherent web vulnerabilities, for example: JavaScript 114 postMessage-based mashup communications [23], hypertext isolation 115 techniques [24], and service security policies advertised via the 116 Domain Name System (DNS) [25]. Going even further, there are efforts 117 to redesign web browser architectures [26], of which Google Chrome 118 and IE8 are deployed examples. An even more radical approach is 119 exhibited in the Gazelle Web Browser [27], which features a browser 120 kernel embodied in a multi-principal OS construction providing cross- 121 principal protection and fair sharing of all system resources. 123 Not to be overlooked is the fact that even though there is a plethora 124 of "standard" browser security features--e.g. the Same Origin Policy 125 (SOP), network-related restrictions, rules for third-party cookies, 126 content-handling mechanisms, etc. [28]--they are not implemented 127 uniformly in today's various popular browsers and RIA frameworks 128 [29]. This makes life even harder for web site administrators in 129 that allowances must be made in site security posture and approaches 130 in consideration of which browser a user may be wielding at any 131 particular time. 133 Although industry and researchers collectively are aware of all the 134 above issues, we observe that the responses to date have been issue- 135 specific and uncoordinated. What we are ending up with looks perhaps 136 similar to Frankenstein's monster [30]--a design with noble intents 137 but whose final execution is an almost-random amalgamation of parts 138 that do not work well together. It can even cause destruction on its 139 own [31]. 141 Thus, the goal of this document is to define the requirements for a 142 common framework expressing security constraints on HTTP 143 interactions. Functionally, this framework should be general enough 144 that it can be used to unite the various individual solutions above, 145 and specific enough that it can address vulnerabilities not addressed 146 by current solutions, and guide the development of future mechanisms. 148 Overall, such a framework would provide web site administrators the 149 tools for managing, in a least privilege [33] manner, the overall 150 security characteristics of their web site/applications when realized 151 in the context of user agents. 153 1.1. Where to Discuss This Draft 155 Please disscuss this draft on the websec@ietf.org mailing list 156 [WebSec]. 158 2. Document Conventions 160 Note: ..is a note to the reader. These are points that should be 161 expressly kept in mind and/or considered. 163 [[XXXn: Some of the more major known issues are marked like this 164 (where "n" in "XXXn" is a number). --JeffH]] 166 [[TODOn: Things to fix (where "n" in "TODOn" is a number). --JeffH]] 168 We will also be making use of the WebSec WG issue tracker, so use of 169 the above two issue & TODO marks will evolve accordingly. 171 3. Overall Constraints 173 Regardless of the overall approaches chosen for conveying site 174 security policies, we believe that to be deployed at Internet-scale, 175 and to be as widely usable as possible for both novice and expert 176 alike, the overall solution approach will need to address these three 177 points of tension: 179 Granularity: 181 There has been much debate during the discussion of some policy 182 mechanisms (e.g. CSP) as to how fine-grained such mechanisms 183 should be. The argument against fine-grained mechanisms is 184 that site administrators will cause themselves pain by 185 instantiating policies that do not yield the intended results. 186 E.g. simply copying the expressed policies of a similar site. 187 The claim is that this would occur for various reasons stemming 188 from the mechanisms' complexity [34]. 190 Configurability: 192 Not infrequently, the complexity of underlying facilities, e.g. 193 in server software, is not well-packaged and thus 194 administrators are obliged to learn more about the intricacies 195 of these systems than otherwise might be necessary. This is 196 sometimes used as an argument for "dumbing down" the 197 capabilities of policy expression mechanisms [34]. 199 Usability: 201 Research shows that when security warnings are displayed, users 202 are often given too much information as well as being allowed 203 to relatively easily bypass the warnings and continue with 204 their potentially compromising activity [35] [36] [37] [38] 205 [39]. Thus users have become trained to "click through" 206 security notifications "in order to get work done", though not 207 infrequently rendering themselves insecure and perhaps 208 compromised [40]. 210 In the next section we discuss various high-level requirements 211 derived with the guidance of the latter tension points. 213 4. Overall Requirements 215 1. Policy conveyance: 217 in-band: 219 We believe that a regime based on HTTP header(s) is 220 appropriate. However we must devise a generalized, 221 extensible HTTP security header(s) such that the on-going 222 "bloat" of the number of disjoint HTTP security headers is 223 mitigated and there is a documented framework that we can 224 leverage as new approaches and/or threats emerge. 226 Note: The distinction between in-band and out-of-band 227 signaling is difficult to characterize because some 228 seemingly out-of-band mechanisms rely on the same 229 protocols (HTTP/HTTPS) and infrastructure 230 (transparent proxy servers) as the protocols they 231 ostensibly protect. 233 It may be reasonable to devise a small set of headers to 234 convey different classes of policies, e.g. web application 235 content policies versus web application network 236 capabilities policies. 238 out-of-band: 240 This policy communication mechanism must be secure and 241 should have two facets, one for communicating securely out- 242 of-band of the HTTP protocol to allow for secure client 243 policy store bootstrapping. potential approaches are 244 factory-installed web browser configuration, site security 245 policy download a la Flash's crossdomain.xml and Maone's 246 ABE for Web Authors [21], and DNS-based policy 247 advertisement leveraging the security of DNS Security 248 (DNSSEC) [32]. 250 2. Granularity: 252 In terms of granularity, vast arrays of stand-alone blog, 253 wiki, hosted web account, and other "simple" web sites could 254 ostensibly benefit from relatively simple, pre-determined 255 policies. However, complex sites--e.g. payment, ecommerce, 256 software-as-a-service, mashup sites, etc.--often differ in 257 various ways, as well as being inherently complex 258 implementation-wise. One-size-fits-all policies will 259 generally not work well for them. Thus, we believe that to be 260 effective for a broad array of web site and application types, 261 the policy expression mechanism must fundamentally facilitate 262 fine-grained control. For example, CSP offers such control. 263 In order to address the less complex needs of the more simple 264 classes of web sites, the policy expression mechanism could 265 have a "macro"-like feature enabling "canned policy profiles". 266 Or, the configuration facilities of various components of the 267 web infrastructure can be enhanced to provide an appropriately 268 simple veneer over the complexity. 270 3. Configurability: 272 With respect to configurability, development effort should be 273 applied to creating easy-to-use administrative interfaces 274 addressing the simple cases, like those mentioned above, while 275 providing advanced administrators the tools to craft and 276 manage fine-grained multi-faceted policies. Thus more casual 277 or novice administrators can be aided in readily choosing, or 278 be provided with, safe default policies while other classes of 279 sites have the tools to craft the detailed policies they 280 require. Examples of such an approach are Microsoft's 281 "Packaging Wizard" [41] that easily auto-generates a quite 282 complicated service deployment descriptor on behalf of less 283 experienced administrators, and Firefox's simple Preferences 284 dialog [42] as compared to its detailed about:config 285 configuration editor page [43]. In both cases, simple usage 286 by inexperienced users is anticipated and provided for on one 287 hand, while complex tuning of the myriad underlying 288 preferences is provided for on the other. 290 4. Usability: 292 Much has been learned over the last few years about what does 293 and does not work with respect to security indicators in web 294 browsers and web pages, as noted above, these lessons should 295 be applied to the security indicators rendered by new proposed 296 security mechanisms. We believe that in cases of user agents 297 venturing into insecure situations, their response should be 298 to fail the connections by default without user recourse, 299 rather than displaying warnings along with bypass mechanisms, 300 as is current practice. For example, the Strict Transport 301 Security specification 302 [I-D.draft-ietf-websec-strict-transport-sec-11] suggests the 303 former hard-fail behavior. 305 5. Attacks and Threats to Address 307 This section enumerates various attacks and threats that ought to be 308 mitigated by a web security policy framework. In terms of defining 309 threats in contrast to attacks, Lucas supplied this: 311 <"Re: More on XSS mitigation (was Re: XSS mitigation in browsers)" 312 (Lucas Adamski). http://lists.w3.org/Archives/Public/ 313 public-web-security/2011Jan/0089.html> 315 "... There's a fundamental question about whether we should be 316 looking at these problems from an attack vs threat standpoint. An 317 attack is XSS [or CSRF, or Response Splitting, etc.]. A threat is 318 that an attacker could compromise a site via content injection to 319 trick the user to disclosing confidential information (by 320 injecting a plugin or CSS to steal data or fool the user into 321 sending their password to the attacker's site). ..." 323 5.1. Attacks 325 The below is an enumeration of attacks which are desirable to 326 mitigate via a web application security framework (see [WASC-THREAT] 327 for a definition and taxonomy of attacks): 329 1. cross-site-scripting (XSS) [2] [WASC-THREAT] 331 2. Man-in-the-middle (MITM) attacks against "secure" (e.g. 332 Transport Layer Security (TLS/SSL)-based [7] [8] [WASC-THREAT]) 333 web sites. For example, be able to subsume the HSTS header [11]. 335 3. User Interface Redressing [UIRedress], aka Clickjacking 336 [Clickjacking]. 338 4. Cross-Site-Request Forgery (CSRF) [3] [WASC-THREAT] (?) 340 5. Response Splitting [WASC-THREAT] 342 6. more (ie eg from [WASC-THREAT] ?) ? 344 5.2. Threats 346 Via the attacks above, an attacker can.. 348 1. Obtain a victim's confidential web application credentials (e.g., 349 via cookie theft), and use the credentials to impersonate the 350 victim and enter into transactions, often with the aim of 351 monetizing the transaction results to the attacker's benefit. 353 2. Insert themselves as a Man-in-the-Middle (MITM) between victim 354 and various services, thus is able to instigate, control, 355 intercept, and attempt to monetize various transactions and 356 interactions with web applications, to the benefit of the 357 attacker. 359 3. Enumerate various user agent information stores, e.g. browser 360 history, facilitating views of the otherwise confidential habits 361 of the victim. This information could possibly be used in 362 various offline attacks against the victim directly. E.g.: 363 blackmail, denial of services, law enforcement actions, etc. 365 4. Use gathered information and credentials to construct and present 366 a falsified persona of the victim (e.g. for character 367 assassination). 369 There is a risk of exfiltration of otherwise confidential victim 370 information with all the threats listed above. 372 6. Use Cases 374 This section outlines various concrete use cases. Where applicable, 375 source email messages are cited. 377 1. I'm a web application site administrator. My web app includes 378 static user-supplied content (e.g. submitted from user agents via 379 HTML FORM + HTTP POST), but either my developers don't properly 380 sanitize user-supplied content in all cases or/and content 381 injection vulnerabilities exist or materialize (for various 382 reasons). 384 This leaves my web app vulnerable to cross-site scripting. I 385 wish I could set overall web app-wide policies that prevent user- 386 supplied content from injecting malicious content (e.g. 387 JavaScript) into my web app. 389 2. I'm a web application site administrator. My web application is 390 intended, and configured, to be uniformly served over HTTPS, but 391 my developers mistakenly keep including content via insecure 392 channels (e.g. via insecure HTTP; resulting in so-called "mixed 393 content"). 395 I wish I could set a policy for my web app that prevents user 396 agents from loading content insecurely even if my web app is 397 otherwise telling them to do so. 399 3. I'm a web application site administrator. My site has a policy 400 that we can only include content from certain trusted providers 401 (e.g., our CDN, Amazon S3), but my developers keep adding 402 dependencies on origins I don't trust. I wish I could set a 403 policy for my site that prevents my web app from accidentally 404 loading resources outside my whitelist. 406 4. I'm a web application site administrator. I want to ensure that 407 my web app is never framed by other web apps. 409 5. I'm a developer of a web application which will be included (i.e. 410 framed) by third parties within their own web apps. I would like 411 to ensure that my web app directs user agents to only load 412 resources from URIs I expect it to (possibly even down to 413 specific URI paths), without affecting the containing web app or 414 any other web apps it also includes. 416 6. I'm a web application site administrator. My web app frames 417 other web apps whose behavior, properties, and policies are not 418 100% known or predictable. 420 I need to be able to apply policies that both protect my web app 421 from potential vulnerabilities or attacks introduced by the 422 framed web apps, and that work to ensure that the desired 423 interactions between my web app and the framed apps are securely 424 realized. 426 7. Detailed Functional Requirements 428 Many of the below functional requirements are extracted from a recent 429 discussion on the [public-web-security] list. Particular messages 430 are cited inline and appropriate quotes extracted and reproduced 431 here. Inline citations are provided for definitions of various 432 terms. 434 1. Policy expression syntax: 436 * Declarative. 438 <"declarative languages". http://www.encyclopedia.com/ 439 doc/1O11-declarativelanguages.html> 441 * Extensible. 443 <"Extensibility". 444 https://secure.wikimedia.org/wikipedia/en/wiki/Extensible> 446 <"Re: XSS mitigation in browsers" (Lucas Adamski). http:// 447 lists.w3.org/Archives/Public/public-web-security/2011Jan/ 448 0066.html> 450 "On a conceptual level, I am not really a believer in the 451 current proliferation of orthogonal atomic mechanisms 452 intended to solve very specific problems. Security is a 453 holistic discipline, and so I'm a big supporter of investing 454 in an extensible declarative security policy mechanism that 455 could evolve as the web and the threats that it faces do. 456 Web developers have a hard enough time with security already 457 without being expected to master a potentially large number 458 of different security mechanisms, each with their own unique 459 threat model, implementation and syntax. Not to mention 460 trying to figure out how they're expected to interact with 461 each other... how to manage the gaps and intersections 462 between the models." 464 <"Re: Scope and complexity (was Re: More on XSS mitigation)" 465 (Adam Barth). http://lists.w3.org/Archives/Public/ 466 public-web-security/2011Jan/0108.html> 468 "I guess I wish we had an extensibility model more like HTML 469 where we could grow the security protections over time. For 470 example, we can probably agree that both and