エキスパートへの質問：Webアプリケーション・セキュリティの最大の問題点は何ですか？
結論：あらゆるWebアプリケーションに共通な「Webアプリケーション・セキュリティの最大の問題点」は存在しませんが、これらの問題は自社のセキュリティの見直しを始める「きっかけ」にはなるでしょう。
回答不能な質問であることはわかっています。アプリケーションや組織ごとに抱える問題に違いがあるため、「Webアプリケーション・セキュリティの最大の問題点」というものは一つだけではありません。では、リソースが限られている開発組織の場合はどこから着手すればよいでしょうか？ OWASPトップ10などのデータ漏洩/エクスプロイト/上位n件のリストで頻出する問題にどのようなものがありますか？ などについて、何人かの専門家に（およびTwitterで）意見を求めました。
この重要な#セキュリティの質問への回答にご協力ください。Web#アプリケーション・セキュリティの最大の問題点は何ですか？
—ソフトウェア・インテグリティ（@SW_Integrity）2019年6月26日
認証の不備は、特に危険な Webアプリケーション・セキュリティの問題です。適切な認証が存在しなければ、システムを誰が使用しているかわかりません。また、既知の脆弱性を含んだオープンソースやサードパーティーのコンポーネントを使用することも問題であるという点について異論のある人はいないでしょう。コードの内容がわからない場合、定期的に更新やパッチの適用を行わないと困った状況に見舞われることになります。困ったときはこちらにご相談ください。しかし、Webアプリケーション・セキュリティはそこで終わりではありません。Webアプリケーション・セキュリティの最大の問題点とその修正方法に関する専門家の意見については、以下をご確認ください。
認証の不備
もちろん、「最も深刻な」という表現は状況に依存するため、「Webアプリケーション・セキュリティの最も深刻な問題点」をひとつに絞り込むことは困難です。とはいえ、Webアプリケーションを使用する企業にとって、「最も深刻な」セキュリティ上の問題はアプリケーションの危殆化に利用される可能性のある問題です。
この分野のジャーナリストとしての総体的な見地から、危殆化に関して自分が書いた記事やそれよりさらに多くの読んできた記事を思い返してみると、認証関連の問題（OWASPの用語で表現すると「認証の不備」）は大問題であると思います。簡単に言えば、Webアプリケーション開発組織はパスワードの再利用やブルートフォース/クレデンシャル・スタッフィング（総当たり/パスワード・リスト）攻撃などの技術的に単純な問題に十分な注意を払っていません。高度な知識を持たない攻撃者でさえWebアプリケーションを侵害できる可能性があるため、この欠陥は特に厄介です。認証の問題は比較的簡単に特定して修正できます。開発チームが予測して防ぐことも比較的容易です。Webアプリケーション開発チームはクレデンシャル・スタッフィングやパスワードの再利用、ユーザー名の列挙その他のありきたりのハッキングなどの問題を考慮し、これらの陳腐な手法を用いたWebアプリケーションの侵害に対する対策を講じる必要があります。
—Paul Roberts、「The Security Ledger」発行人、編集長
インジェクションと不適切な入力妥当性検証
フォーム入力データの妥当性検証の欠如。最も古くから存在する欠陥であり、既知の結果でよく知られているにもかかわらず、未だに蔓延している。弁解の余地はない。
— Tony Dalton（@Tony_Dalton4）2019年6月28日
既知の脆弱性を持つコンポーネントの使用
Webアプリケーションを作成するほとんどの組織では、最終的にはサードパーティー製のコードを運用環境に導入しています。平均的なWebアプリケーションを構成するコードの80～90%はサードパーティー製のライブラリまたはコンポーネントから派生しているとも推定されています。こうしたサードパーティー製コンポーネントのセキュリティは、控えめに言っても疑問の余地があります。各種のスキャン・ツールおよびサービスは総じて、サードパーティー製のライブラリやコンポーネントに潜むセキュリティ上の問題を管理するために登場したものです。「サードパーティー製コンポーネントの使用」に関するセキュリティ上の問題は、2013年からOWASPトップ10の項目となっています。
— Jim Manico、OWASP財団グローバル理事
既知の脆弱性を含んだコンポーネントの使用
既知の脆弱性を含んだクローズドソース・ソフトウェア。
— Barely Functional::?????????::ᛊᛁᛗᛟᚾ（@simon_brooke）2019年6月29日
サードパーティー製コンポーネントに対してもう一票
「既知の脆弱性を含むコンポーネントの使用」は、OWASPトップ10の9位ではあるものの、組織が利用している依存関係に対するアタック・サーフェスを確実に監視し、理解することに取り組むべき非常に重要な問題です。攻撃者がWebサーバーからホスト・コンテンツを取得することを可能にしたRuby On Railsの脆弱性CVE-2019-5418はその好例です。npmのイベント・ストリームが問題になり、プロジェクトにコードを挿入して、依存関係がインストールされたホストからビットコインを盗もうとする攻撃者にプロジェクトが「開示」されました。
サードパーティー製コンポーネントを扱う際に考慮すべきいくつかの点を次に示します。
- サードパーティー製コンポーネントのアセット・レジストリを構築する。
- Black Duck、Dependency Check、npm監査、Synkなどのツールを使用してサードパーティー製コンポーネントを監視する。
- 組織に影響を与えるイベント・ストリームなどの問題を防ぐために、可能な場合は依存関係のバージョンをピン留めする。
- 外部コンポーネントを更新およびリグレッション・テストするプロセスを開発する。
- 強力なコンテンツ・セキュリティ・ポリシー（CSP）を用いて、Webサイトに読み込むリソースと読み込み方法を定義する。
- サードパーティー製コンポーネントにサブリソース・インテグリティ（SRI）を用いる。
—Lewis Ardern、シノプシス、シニア・セキュリティ・コンサルタント（JavaScriptのセキュリティ・レビューに関するWebセミナーを見る）
監視の不備
アタック・ベクターは、エントリー・ポイントからシステムを通じて主要コンポーネントにまで及ばない限り重大ではありません。
これがセキュリティ・カーネルを備える理由であり、セキュリティ・カーネルが大いに有効である理由です。
最悪の失敗は、このような長い破断を可能にすることです。他にもあらゆる事態が起こります。
— John Steed （@imipak）2019年6月26日
ビジネス・ロジックを忘れてはいけない
1つの問題に絞り込むことは間違ったアプローチだと思います。1つ（または10）の問題に焦点を絞ることで、攻撃者に対するセキュリティのハードルが高くなる可能性はありますが、想定外のエクスプロイトの可能性があるという問題が残ってしまいます。高リスクのアプリケーションの場合は、あらかじめ用意されたリストよりもっと広い視野で考える必要があります。
1つの問題に焦点を絞ることにした場合は、社内のアプリケーションに対する過去のセキュリティ評価のデータを使用して、即座に成果が上がるもの（リスクが大きく、修正が容易で、多くのアプリケーションに影響している問題）を選択してください。
開発者の教育や、可能であれば、アプリケーション・ポートフォリオ全体で該当する問題を検出するための自動テストの作成など、1つの問題を完全に解決するアプローチを開発してください。
覚えておきたい主なポイント：あなたにとって一般的でリスクの高い問題は、私にとっては必ずしもそうではありません。データに基づいて独自の問題を1つ選択してください。
思い浮かばなければ、ロジックの問題を検討してはいかがでしょうか。この問題は過小評価されていると思います。
—Koen Buyens、シノプシス、アソシエイト・プリンシパル・コンサルタント（Koen Buyensのブロックチェーン・セキュリティに関するホワイトペーパーを読む）
Webアプリケーション・セキュリティの問題で立ち往生することはありません。
