ウェブのセキュリティを前進させる

ウェブ上のサービスやウェブアプリケーションを利用する際、妥当なレベルのプライバシーとセキュリティが確保されていることを、私たちは当然のように期待するようになりました。こうしたサービスは、お金や金融、行政サービスとのやり取り、私たちや子どもたちの教育、友人や家族とのコミュニケーション、医療、そして食べ物の購入に至るまで、日常生活のあらゆる側面に関わっているからです。大規模なパスワード漏えいから、マルウェア、スパイウェア、ランサムウェアの拡散まで、セキュリティが破られたときに何が起こるか、私たちは深刻な影響を目の当たりにしてきました。私はここ数年、ユーザープライバシーについて多くの時間を費やしてきました。こうしたサービスを利用する際には、適切なプライバシーとセキュリティ対策が施されているとわかる必要があります。基本的には、通信が暗号化されていること（たとえばHTTPSの使用）が求められます。さらに、保存データが適切に保護されていることや、セキュリティアルゴリズムと暗号アルゴリズムが正しく使われていることも重要です。

2014年、私は大規模な監視の脅威からインターネットを強化するための業界ワークショップを主催しました。このワークショップでは、HTTPSへの移行などが提唱されました。企業や組織、そして多くの個人の取り組みにより、今ではウェブ利用の大半がHTTPS経由となっています。この業界全体の取り組みは、セキュリティがプライバシーを守るための前提条件であるという認識に基づいています。プライバシーを保護するアプリケーションを設計しても、安全な環境で開発・デプロイされておらず、ユーザーインターフェースに至るまで通信チャネルが適切に保護されていなければ、攻撃にさらされます。そして、この攻撃対象領域は悪意ある攻撃者にますます悪用されています。最近相次いでいるフィッシング、マルウェア、ランサムウェアの攻撃を見れば、問題があることは明らかです。

安全な通信だけでは不十分

安全な通信の問題に「対処」できた（あるいは解決に向かっている）今、ほかにどのような攻撃の入り口があるのでしょうか。サーバー側にはlog4jのような脆弱性があり、攻撃者はこれを悪用してJava APIエンドポイントを攻撃しています。クライアント側にも、ウェブアプリケーションでユーザーが操作する部分を脅かす脆弱性があります（たとえばクロスサイトスクリプティングの脆弱性）。クロスサイトスクリプティングの脆弱性は、JavaScript環境とウェブブラウザー（またはパッケージ化されたアプリケーションのWebビュー）のDocument Object Modelとのやり取りを悪用します。こうしたクライアント側の攻撃によって、ユーザーの個人データが攻撃者にさらされたり、さらに悪い場合には、ユーザーになりすまして操作されたりする可能性があります。この仕組みは、ウェブ（および多くのアプリ）の動作に本質的に備わっています。好むと好まざるとにかかわらず、ワンタップであらゆるサードパーティーのコードをダウンロードして実行できる世界に私たちは生きています。相手を知っていて信頼している場合でさえ、そのコードには脆弱性が含まれる可能性があります。特に、現実の環境で多くの開発者が書いたコードと共に動作させる場合はなおさらです。また、フィッシング攻撃では、ユーザーの信頼が悪意ある攻撃者に簡単に利用されてしまいます。

ソフトウェアサプライチェーン

ほとんどのソフトウェアプロジェクトは依存関係に頼っています。npmなどのパッケージマネージャーは、依存関係を扱いやすくするためのものです。NPMでは、package.jsonファイルに依存関係を含むプロジェクトの情報を記述しますが、直接の依存関係しか列挙されないため、ソフトウェアサプライチェーン全体を分析するには十分ではありません。開発者は、ソフトウェア開発をサプライチェーンという観点で考えることに慣れていないかもしれません。これは経済学から取り入れられた概念です。（以前にも書いたように、この用語に抵抗を感じる開発者もいるかもしれません。）「今や、ソフトウェア開発者は全員セキュリティの専門家にならなければならないのだろうか」と疑問に思うかもしれません。答えは、ある意味ではイエスです。少なくとも、複数のプログラミング言語やスタック全体にわたって開発に携わる人は、セキュリティの基本を理解し、学び始める必要があります。

オープンソースの依存関係のセキュリティを考える際、開発者がまず目を通すのに適しているのが、OpenSSFの「より安全なソフトウェア開発のための簡潔なガイド」です。このチェックリストには、コードをコミットする際に開発者全員が多要素認証を使うことや、脆弱性のスキャンと監視を行い、修正案を提示するツール（Snykが提供するツールなど）を利用することといった、基本的な対策が含まれています。

高度なセキュリティ仕様

ウェブアプリケーションセキュリティの新たな領域として、高度な機能をより強固なセキュリティとともに実現するウェブAPIの登場があります。たとえば「Spectre」脆弱性は、SharedArrayBufferを使うウェブアプリケーションをプロセッサーレベルの攻撃にさらし、本来は安全と見なされるコンテキスト（オリジン間）でデータが漏えいする恐れをもたらしました。これを受け、ウェブ標準化コミュニティはcross-origin-opener-policyとcross-origin-embedder-policyを策定しました。これは、高度なウェブAPIのセキュリティ向上や、こうした攻撃の軽減を目的として、さまざまな場所で開発された新しい仕様やAPIの一例です。しかし、問題の根本的な複雑さや、こうした手法の一部が入り組んでいること（たとえばCOOPやCOEPでHTTPヘッダーを設定する必要があること）から、開発者にこれらの仕様を周知するのは依然として難しい状況です。

2020年のMDN Web DNA調査で紹介された、ある開発者の言葉が状況をよく表しています。

コーディングを始めたばかりの私ですが、インターネット上のセキュリティは今も最大の懸念事項です。個人的には、現代のウェブセキュリティの仕組みを説明する専門用語が複雑すぎて、最善のセキュリティ対策を学び、実践することは、新人プログラマーにとって最も難しいことの一つだと感じています。サードパーティーの選択肢を利用する場合でさえそうです。

ウェブ開発者がセキュリティのベストプラクティスを実践できるよう、私たちはもっと支援する必要があります。

見えてきたこと

ウェブ開発者コミュニティとDevSecOpsコミュニティの両方に関わってきて、はっきりしたことの一つは、両者のコミュニケーションをもっと活発にする必要があるということです。ウェブ開発者は、ソフトウェアサプライチェーン（依存関係）という考え方を受け入れ、セキュリティ分析を開発の中心に据える必要があります。すでにセキュリティ問題に関心を寄せている開発者コミュニティは、このメッセージをさらに多くの開発者に届けるとともに、ユーザープライバシーなど、セキュリティに関連するエンドユーザーのリスクにも目を向ける必要があります。そうしたリスクを伝えることで、DevSecOpsがなぜ重要なのかを説明できます。

ウェブ開発者は、セキュリティを単に利用する側ではなく、積極的に取り組む必要があります。OpenSSFで活動するウェブ開発者がもっと増えてほしいと思います。たとえばOpenSSF Best Practicesワーキンググループでは、ソースコード管理プラットフォーム（Github、Gitlabなど）の設定に関するベストプラクティスをはじめ、さまざまなテーマのガイドラインを作成しています。また、OpenSSF Scorecardは、オープンソースリポジトリのセキュリティ関連の側面を評価します。こうした議論にはウェブ開発者コミュニティの声が不足してきました。このコミュニティはユーザープライバシーの問題を重視する傾向があるため、OpenSSFの活動では、本来あるべきほどこれらの問題が重視されてこなかったと私は考えています。こうしたコミュニティを結び付け、「ウェブのセキュリティを前進させる」ための業界ワークショップを企画したのは、そのためです。

6月7日と8日にロンドンで開催されるこのオープンな業界ワークショップでは、こうした声を集め、新たな取り組みを促進することを目指しています。ワークショップの発表募集（CfP）は4月24日まで受け付けています。セキュリティに関心のあるウェブ開発者も参加できます。