Securing the web (forward)

We have grown to expect a reasonable level of privacy and security when we use services on the web and web-based applications. That’s because these services deal with every aspect of our daily lives — from money and finances, to how we interact with government services, to our education or the education of our children, to communicating with friends and family, to healthcare, to simply buying food to eat. We’ve seen drastic implications of what happens when security fails, from large-scale password leaks to the spread of malware, spyware, and ransomware. I’ve been spending a good chunk of my time over the past few years on the topic of user privacy. When we interact with all these services, we need to know that appropriate privacy and security controls are applied. At a basic level, that means connections that are encrypted (for example, using HTTPS). It also extends to data at rest being properly secured, and correct use of security and cryptographic algorithms. 

In 2014, I hosted an industry workshop on strengthening the internet against the threat of pervasive monitoring, which — among other things — called for a move to HTTPS. Now, thanks to the efforts of companies, organizations, and many individuals, the vast majority of web use is over HTTPS. This industry effort has been in recognition of the fact that security is a prerequisite for privacy. You can design a privacy-preserving application, but if it’s not developed and deployed in a secure environment — and its communication channels are not properly secured all the way down to the user interface — then it’s open to attack. And this attack surface area is increasingly being exploited by bad actors. You need only look at the recent rash of phishing, malware, and ransomware attacks to see that we have a problem.

Beyond secure transport

So now that we’ve “fixed” (or are on the road to fixing) the secure transport issue, where are the other areas of attack? On the server end there are vulnerabilities such as log4j, which bad actors have been using to exploit Java API endpoints. There are client-side vulnerabilities (for example, cross-site scripting vulnerabilities) that pose a threat to user-facing interactions in web applications. Cross-site scripting vulnerabilities take advantage of interactions between the JavaScript environment and the Document Object Model in the web browser (or web view in a packaged application). These types of client-side attacks can expose a user’s private data to an attacker, or worse — perform an action on their behalf. This pattern is inherent in the way the web (and many apps) work. Like it or not, we live in a world where at one tap you can be downloading and executing code from any third party. Even in cases where you know and trust the third party in question, their code can still contain vulnerabilities, especially when brought into the real world where it must run alongside code written by many others. And in the cases of phishing attacks, user trust can easily be subverted by bad actors.

Software supply chain

Most software projects rely on dependencies. Package managers such as npm try to make dependencies easier to deal with. In NPM, the package.json file describes your project including dependencies, but because it only lists direct dependencies, this only goes so far towards helping you analyze the full software supply chain. Developers may not be used to thinking about software development in terms of a supply chain — which is really a concept borrowed from economics. (And as I’ve written previously, some developers may bristle at this terminology.) You may be asking yourself: “does every software developer have to become a security expert now?” The answer is yes, kind of. Or, at least, developers working across languages and across the stack need to be aware of security basics and start learning.

When it comes to thinking about the security of open source dependencies, a good place for developers to start is the OpenSSF’s Concise Guide to Developing More Secure Software. This checklist includes some basic hygiene factors like ensuring all developers are using multi-factor authentication when committing code, to using vulnerability scanning and monitoring tools that offer suggested fixes (such as the one Snyk provides).

Advanced security specs

Another frontier in the space of web application security is the emergence of web APIs that enable advanced features with extra levels of security. For example: the “Spectre” vulnerability exposed web applications using a SharedArrayBuffer to processor-level attacks that could enable leakage of data between contexts that would normally be considered secure (cross-origin). In response, the web standards community developed cross-origin-opener-policy and cross-origin-embedder-policy. This is one example of a raft of new specifications and APIs that have been developed in various places to improve the security of advanced web APIs and to mitigate against these types of attacks. But because of the underlying complexity of the problem, and the intricacy of some of these approaches (for example, being able to configure HTTP headers in the case of COOP and COEP), developer awareness of these specs remains problematic. 

A quote from a developer cited in the MDN Web DNA survey from 2020 sums it up:

While I still may be new to the coding journey, security...on the internet is still the number one concern. Personally, I feel the complex jargon used to describe how web security functions in the modern era makes learning and implementing best security practices one of the most difficult things as a new programmer, even if you go with the third-party options.

We need to do a better job of enabling web developers to implement security best practices.

What we have here…

One thing that’s become clear from having one foot in the web developer community and one foot in the DevSecOps community is that we have a great need for more communication. Web developers need to start embracing the message and mindset about the software supply (dependency) chain and bringing security analysis front and center. The developer community that’s already paying attention to security issues needs to bring this message to more developers, and pay attention to the end-user risks associated with security (such as user privacy) that can help to explain why the DevSecOps story is so vital.

Web developers need to engage in the security story — not only as consumers. I’d like to see more web developers working with us in the OpenSSF. For example, in the OpenSSF Best Practices working group, we’re creating a set of guidelines for source code management platform (e.g. Github, Gitlab) configuration best practices (among other topics). Another example is OpeSSF score cards, which measure security-related aspects of open source repositories. We’ve been missing voices from the web developer community in these discussions — and since that community tends to be more focussed on user privacy issues, these issues have had less prominence in the work of OpenSSF than I think they should. This is one reason I’ve worked to put together an industry workshop to bring these communities together to “secure the web forward.”

Taking place in London on June 7th and 8th, this will be an open industry workshop that can bring together some of these voices and hopefully catalyze some new work. The workshop CfP is open until April 24th. And the workshop will also be open to attend for security-minded web developers.