Application Foundations/SecurityPrivacy

Privacy and Security: Application Foundations

A goal of Application Foundations is to class the interfaces of the Open Web Platform into subsystems or modules that help WebApp developers to use them effectively. In security and privacy, that means organizing the work to a) to share meaningful guidance with those looking to increase their apps' security and privacy and b) enable developers to build secure and private apps by default.

Foundational Standards and Components: Numerous W3C Recommendations and Rec-track specifications help developers to build secure and privacy-preserving Web Applications. In particular we focus on the work of the Web Application Security WG (WebAppSec) and Web Cryptography WG, and review and architectural work by PING and TAG:

The security of a user's interaction with a Web site or Web app depends on the user's getting what he or she requested, without interference or interception by third parties. Many of the requirements of this interaction are defined elsewhere: [1] W3C standards build on and integrate many of these components.

Unless a site is delivered over HTTPS, it is vulnerable to on-network (man-in-the-middle) attacks as well as communication interception. Strong assurance thus begins by making it easier for developers to deploy HTTPS on their sites. Some features, such as those that provide access to sensitive personal information, should be used only when users can get assurance of the provenance and integrity of the site asking for that information.

HTTPS for Secure Communication

The TAG's guidance: Securing the Web [2], concludes “ that server authentication and integrity are baseline requirements for the continued success of the Web. Furthermore, confidentiality -- while arguably not always strictly necessary -- is often needed. Since the necessity of confidentiality may only become apparent in hindsight, we should also consider it as being crucial to the continued success of the Web.”

Therefore, the TAG finds that:

• The Web platform should be designed to actively prefer secure communication — typically, by encouraging use of "https://" URLs instead of "http://" ones (although exceptions like "localhost" do exist).
• Barriers to adopting "https://" should be removed where feasible.
• The end-to-end nature of TLS encryption must not be compromised on the Web, in order to preserve trust.

Privileged Contexts (FPWD, WebAppSec/TAG) provides guidance for dealing with features that self-designate as requiring a privileged context to be enabled. The recommendation will include non-normative advice on when a feature might designate itself as requiring a secure context and provide a normative algorithm for determining if a given context is privileged.

HTTPS Migration

Since today's Web is not yet fully HTTPS, several specifications help developers to get there.

Upgrade Insecure Requests (FPWD, WebAppSec) creates a mechanism to assist sites in migrating from HTTP to HTTPS by allowing them to assert to a user agent that they intend a site to load only secure resources, and that insecure URLs ought to be treated as though they had been replaced with secure URLs.

Mixed Content (CR, WebAppSec) recommends treatment for resources loaded over insecure channels in a secure web application. Use cases includes standard behaviors for user agents to follow when encountering insecure resource loads in a secure context. This might include definitions of “active” and “passive” content that must be blocked or can be loaded with a warning, and possibly ways for secure applications to consume insecure but non-sensitive resources (such as a weather feed).

Crypto Functionality

WebCrypto gives access to crypto primitives in the browser, easily enabling developers to incorporate new functions in their apps.

WebCrypto API (CR, WebCrypto) specification describes a JavaScript API for performing basic cryptographic operations in web applications, such as hashing, signature generation and verification, and encryption and decryption. Additionally, it describes an API for applications to generate and/or manage the keying material necessary to perform these operations. Uses for this API range from user or service authentication, document or code signing, and the confidentiality and integrity of communications. This will promote higher security insofar as Web application developers will no longer have to create their own or use untrusted third-party libraries for cryptographic primitives.

Secure Site Development and Maintenance

WebAppSec also gives developers tools for building and maintaining their sites:

Content Security Policy Level 2 (CR, WebAppSec) provides a policy language intended to enable web designers or server administrators to declare a security policy for a web resource. The goal of this specification is to reduce attack surface by specifying overall rules for what content may or may not do, thus preventing violation of security assumptions by attackers who are able to partially manipulate that content, for example by script injection or cross-site request forgery. Content Security Policy Pinning defines a new HTTP header that allows authors to instruct user agents to remember ("pin") and enforce a Content Security Policy for a set of hosts for a period of time.

Cross-Origin Resource Sharing (CORS) (Rec, WebApps and WebAppSec) defines a mechanism to enable client-side cross-origin requests. Specifications that enable an API to make cross-origin requests to resources can use the algorithms defined by this specification. If such an API is used on http://example.org resources, a resource on http://hello-world.example can opt in using the mechanism described by this specification (e.g., specifying Access-Control-Allow-Origin: http://example.org as response header), which would allow that resource to be fetched cross-origin from http://example.org.

Subresource Integrity (FPWD, WebAppSec) offers a recommendation for uniquely identifying resources loaded in a secure web application to detect and prevent potentially malicious modification. Use cases include adding integrity protections to sub-resource loads from HTML documents. This mechanism would have the goals of allowing resource authors to specify the exact hash value of cross- origin sub-resources. Possible future features may include allowing optimistic loading of such resources from content- aware caches or over insecure transports, provided appropriate privacy and security guarantees can be achieved.

Referrer Policy (FPWD, WebAppSec) A recommendation for a header and meta tag allowing resource authors to specify a policy for the values sent as part of the HTTP Referer (sic) header. Use cases include making this policy more restrictive to protect applications which include security capability tokens in the URL, or allowing more permissive sharing of referrer information from secure to insecure origins to remove barriers which today prevent applications from moving to secure origins.

Secure Authentication

Authentication remains a common need. Credential Management API (FPWD, WebAppSec) offers a standardized API to address use cases related to assisted management of user credentials, including traditional username/password pairs.

New Authentication Work

We also anticipate new work: Secure Web Authentication, based in the FIDO specifications for universal two-factor authentication (U2F) and universal authentication framework (UAF), a new WG will be chartered to develop a recommendation-track standard for secure authentication of entities (users, systems and devices) to enable high-security Web applications. Goals include standardized support of two-factor authentication as well as the elimination of passwords if allowed by device capabilities, while maintaining the same origin policy.

Hardware-Based Web Security will be chartered to develop recommendation-track documents that define a standard to provide secure services for high security Web applications. Use cases will include the ability to encrypt and to decrypt data using hardware based encryption modules, the ability to manage credential information for hardware based security modules, and the ability to access specific security sensitive services offered by hardware tokens.

Experimental New Work

Suborigin Namespaces Create and advance a recommendation to allow applications to place themselves into namespaces within a traditional scheme/host/port RFC 6454 Origin label to enable easier development of modular applications with privilege separation.

Confinement with Origin Web Labels Create and advance a recommendation for a robust JavaScript confinement system for modern web browsers, in a way that is backward-compatible with legacy web content. The goal of the specification is to define APIs for specifying privacy and integrity policies on data, in the form of origin labels, and a mechanism for confining browsing contexts (pages, iframes, etc.) according to these labels. This would allow Web application authors and server operators to share data with untrusted -- buggy but not malicious -- code (e.g., in a mashup scenario, cross-origin iframes) yet impose restrictions on how the code can further share the sensitive data. An additional goal is to define a light-weight, in-thread Web Worker. This would allow developers to build privilege-separated, compartmentalized applications

Entry Point Regulation for Web Applications (FPWD) Create and advance a recommendation to allow web applications to designate their entry points via a combination of headers and a policy manifest. Conformant user agents will restrict external navigations and other information flows into the application based on this policy to reduce the application's attack surface against Cross-Site Scripting and Cross Site Request Forgery. Restricting deep-linking for non-security purposes is not a goal of this deliverable, and it should give resource owners no additional ability to do so beyond current abilities of the web platform, e.g. by providing a simple to deploy mechanism using client-side state to supplement what can already be accomplished by a less-scalable web application firewall. Preserving the ability to link on the web platform will be prioritized.

Permissions API (FPWD) Create and advance a recommendation to allow web applications to be aware of the status of a given permission, to know whether it is granted, denied, or if the user will be asked whether the permission should be granted. This recommendation will not address user agent implementations of permissions, including their scope, duration, granularity, or user interface and experience for indicating, configuring, or asking for permissions.

Privacy and Security Reviews

PING, WebSec, and TAG contribute to the reviews of existing specs. While much of that review focuses on privacy and security considerations in the spec text or implementation, it may also include developer considerations that impact the privacy and security.

---Notes---

[1] DNS resolution provides an end-point based on the URL given to a client; DNSSEC, if used, can assure that it's the end-point intended by the domain registrant; TLS assures the integrity and confidentiality of the HTTP communications, while certificate validation provides some indication of the site-operator's identity.

[2] TAG Blog: Securing the Web, 23 January 2015.