W3C Workshop Secure the Web Forward

Driving developer awareness and adoption of Web security standards & practices

September 26-28, 2023 - Virtual

Presented by W3C, OpenSSF, OWASP, OpenJS

Parsoa Khorsand

Position papers

The program committee has reviewed and selected the following position papers as input to the live discussions in September 2023. Live presentations were recorded and published, see below for links.

Focus topics

The position papers have been organized per focus topic. The program committee organized the agenda of the on-line sessions along similar axes:

  1. Supply Chain Security
  2. JavaScript Security
  3. Developer Awareness

Supply Chain Security

Software Bill of Materials for web frontends

by Jan Kowalleck.
Description

Today's web frontends are more and more assembled from multiple components from different sources. Assembler tools like webpack are used to bundle deliverables for the web. Even Angular and React use webpack for this purpose. For multiple roles, it appears important to know accurate details of this assembly and deliverables.

Solution

Software Bill of Materials (SBOM) is a way to describe components, assembly, and formulation of software, such as web deliverables. Such SBOMs can be ingested into dependency trackers, vulnerability analyzers, or risk assessment tools.

SBOM can document the state of the software they deliver to clients' web browsers. SBOM can document the licensing situation of a web frontend. SBOM can help understand supply chain risks.

For all the use cases, it is very important to create an accurate SBOM based on what is actually delivered.

Retrieval of SBOM

Retrieving the SBOM of a web frontend is discussed in an IETF draft.

Unfortunately, this is still a draft. It would really help if this was on a more mature level, a standard at best.

Generation of SBOM

One document standard for SBOM is OWASP's CycloneDX, which is capable of documenting an application's metadata, components, dependencies, licensing, and formulation.

OWASP's CycloneDX Webpack Plugin is a tool that hooks into webpack to create a CycloneDX SBOM containing an aggregate of all bundled dependencies. This plugin uses the linkages generated by webpack to create a dependency graph that only contains the dependencies that are actually used (after tree-shaking) in the bundled result. To my knowledge, OWASP's CycloneDX Webpack Plugin is the only tool that creates an accurate SBOM based on what is actually delivered.

Resources
Author

Jan Kowalleck is the maintainer of OWASP's CycloneDX Webpack Plugin and a member of OWASP's CycloneDX Core Working Group. He has worked as a professional software engineer, as a software architect, and as a tech lead in web development teams for the past 15+ years.

Establish Standards to Support Web Access to SBOM Data

by Gary O'Neall.
Description

Establishing a common vocabulary and protocol for accessing SBOM information over the public internet would ease integration into various software build and deployment systems thereby improving overall software supply chain security.

Although this is a very ambitious goal, there is already a lot of standardization we can leverage for this purpose.

There is an existing IETF draft proposal to extend the Manufacturers Usage Description (RFC 8520) to discover and retrieve SBOM information. Although this proposal is focused on devices at the end of the supply chain, aspects of the model and approach could be leveraged for more general SBOM discovery scenarios.

For the SBOM vocabulary, the SPDX standard defines terms for supporting use cases involving SBOMs as well as many other supply chain relevant use cases.

The SPDX standard is a formal ISO standard (ISO/IEC 5962:2021) as well as an RDF ontology described in the W3C OWL Ontology language. The standard is also freely available as a JSON schema and more human readable web pages.

SPDX is supported and maintained by a large group of contributors representing tooling providers, SBOM producers and SBOM consumers.

The upcoming SPDX 3.0 has some very specific enhancements for making the SBOM information more web accessible.

Leveraging an existing well-defined vocabulary that supports standards ranging from JSON Schemas to full RDF Ontologies can accelerate the adoption of internet accessible SBOM data and improve overall software supply chain security.

Author

Gary is a co-lead of the technical workgroup for the Software Package Data Exchange® (SPDX™) - an open standard for communicating software bill of material information, including components, licenses, copyrights, and security references. Gary has contributed several open-source tools including the SPDX Java Libraries and Tools. Gary O’Neall is responsible for product development and technology for Source Auditor Inc., a software and service company helping software companies manage the technical and legal risks of open-source software.

Source Code Transparency

by Daniel Huigens.
Description

Today, whenever you open a web app, the browser fetches and runs its source code from the server. This enables the ease of deployment and iteration that the web is known for, but can also pose security risks. In particular, for web apps that don't want to trust the server, such as those using client-side encryption to protect the user's data before sending it to the server, or those processing the user's data entirely client-side without sending any sensitive data to the server, the current security model of the web is insufficient.

After all, if a web app claims not to send sensitive data to the server, this is very difficult for users to check, as they would need to read (and understand) the source every time it's loaded from the server. Even for security researchers, such a claim is impossible to verify, as the server could simply serve a different version of the web app to a user it wants to target than to the security researcher.

Therefore, we would like to propose a mechanism to enable security researchers to audit the source code of especially-sensitive web apps that is (or was) sent to any user, not just to themselves.

Our goal is only to allow detection rather than prevention of malicious code, possibly after the fact, as we believe this will still deter servers from serving malicious code. Additionally, preventing malicious code from being deployed would require mandating security audits prior to deploys, which would slow down and fundamentally change the deployment model of the web.

High-level Proposal

To accomplish the above, the source code of (a given version of) a web app should be published to a transparency log, similar to Certificate Transparency. Then, when opening a web app, the browser should check that the fetched source code was received by (and is or will be included in) the transparency log, and only run it if so. Then, security researchers can check the transparency log for all published versions of a given web app, and check that none of them contain any malicious code.

To aid the auditing process, web apps may want to employ additional existing and proposed security mechanisms, such as CSP, SRI, SBOMs, reproducible builds, etc. These mechanisms, which currently only allow the developer of web apps to check the security of the web app, would additionally allow external security researchers to audit a web app, if it used a mechanism such as Source Code Transparency.

Detailed Proposal

To simplify the distribution and integrity verification of web apps' source code, we could make use of Web Bundles, and publish a hash of the bundle to a transparency log.

The transparency log could be structured as an append-only chain of Merkle Trees, each of which operates as a map of (domain, version) keys to hash(bundle) values (where the key could be hashed and interpreted as a binary path in the binary tree, with the value of the final leaf being the hash of the web bundle). Web apps could submit the hash of the bundle to the transparency log, which would periodically include all (existing and new versions of each) web app in the next Merkle Tree. Auditors could check that the transparency log is behaving consistently and not changing the hash of old versions of web apps, for example.

Then, when loading a participating web app, the browser would check the latest Merkle Tree and verify that the hash of the bundle received is included in it, and warn the user if not. To still allow instantaneous deploys, we could allow this check to be done some time after loading the web app, at the cost of delayed warnings in case of issues.

To signal to the browser that a given web app is using Source Code Transparency, we could introduce a X.509 certificate extension, which would automatically be included in the Certificate Transparency logs, allowing security researchers to check that all certificates for the domain of the web app include this extension. Browser would refuse to load web apps without Source Code Transparency from a domain using a certificate with this extension.

Please see the Source Code Transparency GitHub repository for discussions.

Resources
Author

Daniel Huigens is the cryptography team lead at Proton. He is the editor of the Web Cryptography API specification, and the author of the Secure Curves in Web Crypto draft.

He has also been thinking about web application security for roughly a decade, having created Airborn (a browser-based encrypted documents editor) in 2014.

JavaScript Security

Applying Hardened Javascript to supply chain security for a proactive approach

by Zbyszek Tenerowicz.
Description

The problem of supply chain security for the Web is currently being addressed by building up databases of known issues and improving the pace at which research and testing results are delivered to web developers. The approach has been successful in improving the security of popular open source software. The friction introduced by false-positives and its impact on security postures in the community is yet to be addressed.

This approach depends on security researchers, increasingly aided by AI, discovering vulnerabilities and malicious packages. It constitutes an arms race, while the growth in malicious packages for the web ecosystem is clearly superlinear.

As a result, projects wait for audit results of their dependencies to trickle down to developers, and assume malicious packages will be discovered in time for them to be stopped. Targeted attacks and sophisticated threat actors may never be stopped by this approach even at maximum throughput.

We need another layer of protection that can be proactive, not reactive.

Using Hardened JavaScript one can take control of all powerful APIs and resources in JavaScript and decide which should be avialable to specific dependencies. With appropriate tooling that can also include projects producing bundles where application code and dependencies coexist in one file and share references.

Hardened JavaScript protects all intrinsics from being modified and introduces the Compartment constructor, which can be used to evaluate code in isolation from outer scope.

The current approach in LavaMoat is to generate a policy at a point in time and only allow access to expected globals and imports. The enforcement happens at runtime using Compartments. Any dependency suddenly turning malicious, for example by reaching for fetch although it was not accessing network before, will fail to work.

As work on introducing Hardened Javascript (Module\* classes, Evaluators, Compartment and lockdown) to JavaScript progresses, it's time to look into making runtime supply chain security a feature of the Web platform.

While using Compartment to isolate dependencies and control what they access is a proven technique by now, open questions remain.

  • Access to DOM is the ultimate power that makes references to all globals reachable. Attempts to apply a membrane to DOM have not been successful.
  • Compartment can provide isolation within one Realm, but accessing another Realm would allow escalating privileges further.

I wish to present on the topic above and open a conversation about supporting the proactive approach to supply chain security in the Web platform.

Author

Zbyszek Tenerowicz has been involved in Open Source and Web development and spent 7 years leading a team building and maintaining ultimately over 30 web applications in production. Over that period, Zbyszek has been putting increased attention towards security and building up awareness of the needs of development teams in security context, built npm-audit-resolver and ultimately joined the LavaMoat team where he's working on tooling to apply Hardened Javascript to the problem of supply chain security.

JavaScript realms used to bypass and eliminate web apps security tools - A problem with a WIP solution

by Gal Weizman.
Description
Introduction

There are many security tools that try to defend web apps in runtime in the browser by redefining and protecting built in JavaScript APIs. The need for such tools grows with the difficulty in securing web apps supply chains which results in having a hard time detecting changes in the supply chain that might cause harm in the victim's browser.

For example, if a malicious code manages to execute within the browser of the victim, it can try accessing some secrets stored by the app in the localStorage - therefore we have different security tools which attempt to better control access to such sensitive APIs by redefining their behaviour to be more selective on which code is allowed to access it and which code isn't.

Problem

However, thanks to JavaScript realms, an attacker can ignore such protection quite easily by simply creating a new JavaScript realm and accessing such sensitive APIs via the new realm's unique set of APIs:

// will fail if the localStorage API is hooked into by a security tool
const stolenSecret = localStorage.secret;
// bypass security tool easily - access the sensitive API via a new realm
const stolenSecret = document.body.appendChild(document.createElement('iframe')).contentWindow.localStorage.secret

This effectively eliminates such protections almost completely.

Solution (WIP)

We are currently working on the most advanced solution to this problem by trying to provide an easy way to handle creation of new realms in runtime before attackers gain access to those.

However, implementing such a solution in JS comes with many difficulties and issues, which could have been easier to address natively by the browser.

Goal

I wish to bring up this issue and the possible approaches to it in order to discuss and explore them.

Author

Gal Weizman has been working on browser JavaScript runtime security specifically for supply chain security for the past 5 years, focusing mostly on realms security research. In general, most of Gal's work so far was about browser JavaScript security in all sorts of aspects.

Gal Weizman currently leads the research and work around realms security in MetaMask, and works on Snow being an open source WIP solution for this problem.

Establishing a robust long-term security model for cookies on the web

by Artur Janc.
Description

Browser vendors' efforts to disable third-party cookies are motivated primarily by privacy / anti-tracking considerations, but they have a significant - and generally underappreciated - impact on the overall security of the web platform. The presence of third-party cookies is the root cause of multiple classes of vulnerabilities in web applications, such as Cross-Site Request Forgery (CSRF), clickjacking and numerous cross-site leaks; consequently, blocking the sending of cookies on cross-site requests would provide web applications with substantial isolation benefits.

However, the anti-tracking focus of third-party cookie blocking efforts carries a risk of leading to implementations which won't reliably protect websites from cross-site attacks. For example, establishing the top-level site as the boundary for sending third-party cookies (the current implementation in multiple browsers) risks allowing untrusted embedded content, such as ads, to send credentialed requests to endpoints hosted by the top-level site and continue to exploit cross-site vulnerabilities.

Similarly, mechanisms meant to restore functionality limited by the deprecation of third-party cookies, such as the Storage Access API, Cookies Having Independent Partitioned State (CHIPS), Federated Credential Management API (FedCM), as well as various features to re-enable third-party cookies on a per-site basis, need to grapple with the same scoping rules. The risk of being overly permissive (for example, creating convenient mechanisms to fully re-enable third-party cookies for a given site) is that it will permit web-based attackers to bypass built-in isolation defenses. This is particularly concerning in the long run: if the web is safe by default from cross-site vulnerabilities, developers will pay less attention to implementing application mitigations (such as the use of CSRF tokens or X-Frame-Options headers). As a result, attackers who can regain access to third-party cookies on their sites will be able to exploit gaps in isolation on a large fraction of the web.

This session is meant to discuss the cookie model that we're aiming for from a security perspective, including a review of the potential security benefits of reliable third-party cookie blocking. It also aims to identify specific hardening opportunities for browsers' third-party cookie blocking logic to help browser vendors improve their implementations.

Author

Artur Janc is the Team Leader for web security on Google's Information Security Engineering team, focusing on the adoption of security features across the Google web ecosystem as well as broader security and privacy improvements to the web platform.

Developer Awareness

Can securing jQuery help secure the Web forward?

by Tobie Langel.
Description

Open source security has increasingly become a top concern due to numerous high-profile and high-impact vulnerabilities affecting critical open source projects that underpin the internet's infrastructure. Over the years, various industry efforts have aimed to address this issue, with a renewed sense of urgency emerging recently. The White House and the EU Commission have taken notice, and legislative efforts are underway across multiple jurisdictions. Open source security is now increasingly framed as a software supply chain issue.

In this context, the OpenSSF has launched an ambitious new project called Alpha-Omega. Most of the open source projects identified by Alpha-Omega fit well within the activity streams defined by the OpenSSF's Open Source Software Security Mobilization Plan. they are, after all, the infrastructure building blocks that this initiative was designed to harden.

A few projects, however, stand out. jQuery is one of them.

Originally released in 2006, jQuery has significantly impacted both web developers and browser vendors by addressing browser interoperability issues through a unified and enjoyable-to-use API. This has empowered web developers, accelerated the advent of the Web as an application platform, and driven the adoption of better Web standards and more interoperable implementations.

Despite newer frameworks like React, Vue.js, and Svelte gaining popularity, jQuery remains an essential feature of the Web. As of today, it is present in a staggering 78% of the top 1 million websites, according to BuiltWith. For context, React is only found on 14% of the same sample, and most other JavaScript libraries that appeared in the meantime (e.g., Twitter Bootstrap, Modernizr, or Backbone) have fallen out of favor.

jQuery's massive reach and longevity aren't its only unique aspects. It's also one of the rare JavaScript libraries identified by Alpha-Omega that is directly consumer-facing--effectively running on billions of consumer devices--and it runs inside the browser sandbox. This combination creates a different set of security concerns and calls for a dedicated approach.

While this approach is specific to jQuery in this context, it touches on several broader points relevant to this audience, notably:

  • Identifying vulnerabilities that are specific to JavaScript code that is meant to be run in the browser sandbox.
  • Educating maintainers of web-facing open source projects about those vulnerabilities.
  • Improving web developer education about browser and web application security to reduce the prevalence of those vulnerabilities that the browser sandbox cannot protect from.
  • Supporting standardization efforts designed to reduce related risk (particularly around making it easier to manage user-generated content more safely).
  • Exploring the life cycle of open-source projects, in particular those that fill browser standardization gaps ot interoperability issues.
  • Examining the security aspects of hosting JavaScript on CDNs and determining best practices around those (and a possible deprecation path).

This project also provides an opportunity to explore improving the security of end-users on the web through multi-modal approaches across:

  • standard bodies and standardization efforts
  • browser implementations and developer tools
  • developers advocates
  • documentation (such as MDN)
  • specialized media
  • maintainers of open source libraries and the foundations that support them
  • industry-wide security-focused efforts such as Alpha-Omega project
  • open source funding through both industry and national efforts

Once again--and against all odds--jQuery can be a trailblazer and help move the web forward.

Resources
Author

Tobie Langel is a world-leading expert and international speaker on open source and standardization. He advises some of the biggest names in tech (Google, Microsoft, Mozilla, Intel, Cisco), promising startups (GitLab, Airtable, Coil), industry organizations (OpenJS Foundation, OASIS, W3C) and nonprofits (Organization for Ethical Source, Ushahidi, Omidyar Network), either pro bono or through his consultancy, UnlockOpen.

Documentation for web security education

by Florian Scholz.
Description

The WebDX community group ran a short survey on MDN to identify the most challenging security aspects that web devs need to face today. (297 responses)

At least two aspects of this survey suggest that better education is needed:

  • "Understanding security threats": 29% said "very challenging" and 40% "somewhat challenging".
  • "Understanding the browser security model": 27% said "very challenging" and 39% said "somewhat challenging"

The Open Web Docs team would like to attend the Secure the Web Forward workshop to collaborate with a group of security experts on writing better documentation for web security on MDN Web Docs.

Given the survey results, and with the help of subject matter experts, we want to produce a content outline to improve the information web developers need to understand web security.

To achieve this we want to use Divio’s documentation system to make the docs better. It requires four different types of documentation to be created: Tutorials (learning-oriented), How-Tos (problem-oriented), Guides (understanding-oriented), Reference (information-oriented).

Currently, on MDN, web security is documented on the Web/Security page with a few subpages. We would like to bring structure into this documentation area and fill gaps.

Resources
Author

Open Web Docs (OWD) is a non-profit collective funded by corporate and individual donations. More information is available on the Open Web Docs web site.

Florian Scholz is a Technical Writer at Open Web Docs. Email: florian@openwebdocs.org.

Roadmap planning for a JavaScript security framework

by Joe Sepi, Robin Ginn and Ben Sternthal.
Description

The OpenJS Foundation has a full tank of gas to build and execute a security framework roadmap for JavaScript thanks to the funding support from the German government’s Sovereign Tech Fund. New dedicated resources combined with active OpenJS working groups in security and standards can help the JS ecosystem broadly adopt more secure policies and practices. OpenJS is seeking feedback from web platform communities in developing a security and maintenance roadmap plan.

Joe Sepi, OpenJS Cross Project Council (CPC) Chair, and Chair of the OpenJS Security Collaboration Space, together with OpenJS Executive Director Robin Ginn, seek an interactive discussion about industry best practices and priorities so that OpenJS can help customize and execute for JavaScript.

Best practices from OpenSSF and OWASP, for example:

The OpenJS Foundation is committed to supporting the healthy growth of the JavaScript ecosystem and web technologies by providing a neutral organization to host and sustain projects, as well as collaboratively fund activities for the benefit of the community at large.

The foundation’s hosted projects have a significant level of maturity and stability, achieved through open and transparent technical governance, and a positive culture of cross-project collaboration among OpenJS projects through its Cross Project Council (CPC). Hosted projects include Node.js, jQuery, Jest, Electron, webpack, ESLint, Node-RED and Appium.

Resources
Authors

Joe Sepi is Chair of the OpenJS Cross Project Council (CPC), and Chair of the OpenJS Security Collaboration Space. Robin Ginn is an Executive Director of the OpenJS Foundation. Ben Sternthal is the OpenJS Program Director.