オープンウェブアプリケーションセキュリティプロジェクトは、Webアプリケーションのセキュリティに関する最も差し迫った問題のリストを定期的に更新しています。
この記事を読み終えると、以下のことができるようになります。
関連コンテンツ
是非、Cloudflareが毎月お届けする「theNET」を購読して、インターネットで最も人気のある洞察をまとめた情報を入手してください！
記事のリンクをコピーする
オープンウェブアプリケーションセキュリティプロジェクト（OWASP）は、Webアプリケーションセキュリティに特化した国際的な非営利組織です。OWASPの中核となる原則の1つは、すべての資料がWebサイトで無料で入手でき、簡単にアクセスできるため、誰でも独自のWebアプリケーションのセキュリティを向上できることです。彼らが提供する資料には、文書、ツール、ビデオ、フォーラムが含まれます。おそらく彼らの最も有名なプロジェクトはOWASPトップ10です
OWASPトップ10は、Webアプリケーションのセキュリティに関するセキュリティ上の懸念を概説する定期的に更新されるレポートであり、最も重要な10のリスクに焦点を当てています。このレポートは、世界中のセキュリティ専門家チームによってまとめられています。OWASPは、トップ10を「認識文書」と呼び、セキュリティリスクを最小化および/または軽減するために、すべての企業がレポートをプロセスに組み込むことを推奨しています。
以下は、『OWASPトップ10 2021レポート』で報告されたセキュリティリスクです。
アクセス制御とは、情報または機能へのアクセスを制御する仕組みを指します。不正アクセス制御により、攻撃者は認証をバイパスし、管理者などの特権ユーザーであるかのようにタスクを実行できます。たとえば、Webアプリケーションでは、他の検証なしで、URLの一部を変更するだけで、ユーザーがログインしているアカウントを変更できます。
Webアプリケーションが認証トークン*を使用し、それらに厳密な制御を設定することにより、アクセス制御を保護できます。
*多くのサービスは、ユーザーのログイン時に認証トークンを発行します。ユーザーが行うすべての特権リクエストでは、認証トークンが必要です。これは、ログイン資格情報を絶えず入力する必要なく、ユーザーが本人であることを保証する安全な方法です。
Webアプリケーションが金融情報やパスワードなどの機密データを暗号化によって保護しない場合、攻撃者はそのデータにアクセスし、悪意のある目的で売却したり利用したりすることができます。オンパス攻撃を使用して、機密情報を盗むこともできます。
すべての機密データを暗号化し、すべての送信を認証して、機密情報のキャッシング*を無効にすることにより、データ漏えいのリスクを最小限に抑えることができます。さらに、Webアプリケーション開発者は、機密データを不必要に保存しないように注意する必要があります。
*キャッシングは、再利用のためにデータを一時的に保存する方法です。たとえば、Webブラウザは多くの場合Webページをキャッシュするため、ユーザーが一定の時間内にそれらのページに再アクセスした場合、ブラウザはWebからページを取得する必要がありません。
インジェクション攻撃は、信頼できないデータがフォーム入力またはWebアプリケーションへの他のデータ送信を介してコードインタープリターに送信されるときに発生します。たとえば、攻撃者はSQLデータベースコードをプレーンテキストのユーザー名を想定したフォームに入力することができます。そのフォーム入力が適切に保護されていない場合、そのSQLコードが実行されることになります。これは SQLインジェクション攻撃として知られています。
インジェクションカテゴリには、XSS（Cross-site scripting）攻撃も含まれます。2017年のレポートでは、以前から独自のカテゴリでした。Cross-site scriptingの軽減戦略には、信頼されていないHTTPリクエストからのエスケープのほか、ReactJSやRuby on Railsなどの最新のWeb開発フレームワーク（組み込みCross-site scripting保護を提供）の使用が含まれます。
通常、ユーザーが送信したデータを検証またはサニタイズすることにより、インジェクション攻撃を防止することができます（検証とは、疑わしいデータを拒否することを意味し、サニタイズとは、データの疑わしい部分をクリーンアップすることを指します）。さらに、データベース管理者は、インジェクション攻撃が公開できる情報量を最小限に抑えるためのコントロールを設定できます。
SQLインジェクションを防ぐ方法の詳細は、こちらをご覧ください。
安全でない設計には、アプリケーションのアーキテクチャに埋め込まれる可能性のあるさまざまな弱点があります。これは、アプリケーションの実装ではなく設計に焦点を当てています。OWASPでは、安全でない設計の一例として、パスワード復旧のためのセキュリティ質問（例：「あなたが育った故郷は？」）の使用を挙げています。このようなワークフローが、開発者によってどれほど完全に実装されていたとしても、アプリケーションは依然として脆弱であることに変わりはありません。なぜなら、複数の人間がセキュリティ上の質問に対する答えを知ることができるからです。
アプリケーションの展開前に脅威モデリングを使用することで、この種の脆弱性の軽減に役立ちます。
不適切なセキュリティ設定は、リストで最も一般的な脆弱性であり、多くの場合、デフォルトの構成を使用したか、過度に詳細なエラーを表示した結果です。たとえば、アプリケーションはユーザーに過度に記述的なエラーを表示し、アプリケーションの脆弱性を明らかにする可能性があります。これは、コード内の未使用の機能を削除し、エラーメッセージがより一般的になるようにすることで軽減できます。
セキュリティの設定ミスのカテゴリには、XEE（XML External Entities）攻撃が含まれます。2017年のレポートでは、以前から独自のカテゴリでした。これは、XML*入力を解析するWebアプリケーションに対する攻撃です。この入力は外部エンティティを参照し、パーサーの脆弱性を悪用しようとします。この文脈での「外部エンティティ」は、ハードドライブなどのストレージユニットを指します。XMLパーサーを騙して不正な外部エンティティにデータを送信することで、攻撃者に機密データを直接渡すことができてしまいます。XEE攻撃を防止する最良の方法は、WebアプリケーションにJSONなどのそれほど複雑でないタイプのデータを受け入れさせるか、少なくともXMLパーサーにパッチを当てて、XMLアプリケーションで外部エンティティの使用を無効にすることです。
*XML（Extensible Markup Language）は、人間が読める形式と機械が読める形式の両方を対象としたマークアップ言語です。その複雑さとセキュリティの脆弱性のため、多くのWebアプリケーションで使用されなくなりました。
最新のWeb開発者の多くは、Webアプリケーションでライブラリやフレームワークなどのコンポーネントを使用しています。これらのコンポーネントは、開発者が冗長な作業を避け、必要な機能を提供するのに役立つソフトウェアです。一般的な例には、Reactなどのフロントエンドフレームワークや、共有アイコンやa/bテストの追加に使用される小さなライブラリが含まれます。一部の攻撃者は、これらのコンポーネントの脆弱性を探し、それらを使用して攻撃を調整することができます。より人気のあるコンポーネントの一部は、数十万のWebサイトで使用されています。攻撃者がこれらのコンポーネントの1つにセキュリティホールを見つけると、何十万ものサイトが悪用されやすくなります。
コンポーネント開発者は多くの場合、既知の脆弱性を補うためのセキュリティパッチと更新を提供しますが、Webアプリケーション開発者は、アプリケーションで実行されているコンポーネントのパッチ済みまたは最新バージョンを常に持っているとは限りません。既知の脆弱性を持つコンポーネントを実行するリスクを最小限に抑えるために、開発者はプロジェクトから未使用のコンポーネントを削除し、信頼できるソースからコンポーネントを受け取り、最新のものであることを確認する必要があります。
認証（ログイン）システムの脆弱性により、攻撃者はユーザーアカウントにアクセスでき、管理者アカウントを使用してシステム全体を侵害することもできます。たとえば、攻撃者はデータ漏えい中に取得した数千の既知のユーザー名/パスワードの組み合わせを含むリストを取得し、スクリプトを使用してログインシステムでそれらのすべての組み合わせを試して、機能するものがあるかどうかを確認できます。
認証の脆弱性を軽減するためのいくつかの戦略には、2要素認証（2FA）が必要とするものと、レート制限を使用して繰り返しログイン試行を制限または遅延させるものがあります。
現在のアプリケーションの多くは、その機能をサードパーティプラグインやその他の外部ソースに依存していますが、それらのソースからの更新やデータが改ざんされていないこと、予期する場所から発信されていることを必ずしも確認しているわけではありません。たとえば、外部ソースからのアップデートを自動的に受け入れるアプリケーションは、攻撃者が独自の悪意のあるアップデートをアップロードする際に脆弱である可能性があり、アップデートはそのアプリケーションのすべてのインストールに配信されます。このカテゴリには、安全でないデシリアライゼーションの悪用も含まれます。この攻撃は、信頼できないソースからのデータをデシリアライズした結果であり、DDoS攻撃やリモートコード実行攻撃などの深刻な結果をもたらす可能性があります。
データや更新の整合性が損なわれていないことを確実にするために、アプリケーション開発者はデジタル署名を使用して更新を検証し、ソフトウェアのサプライチェーンをチェックして、継続的インテグレーション/継続的デプロイメント（CI/CD）パイプラインに強力なアクセス制御が適用され、適切に構成されていることを確認する必要があります。
多くのWebアプリケーションは、データ漏えいを検出するのに十分な手順を実行していません。漏えいの発見時間の平均は、発生してから約200日です。これにより、攻撃者は応答を受け取る前にダメージを与えるための多くの時間を費やすことができます。 OWASPは、Web開発者がアプリケーションへの攻撃を確実に認識できるように、ログと監視、および事故対応計画を実装することを推奨します。
SSRF（Server-Side Request Forgery）は、攻撃者がサーバーにURLリクエストを送信することで、本来保護されているはずの予期しないリソースをサーバーに取得させる攻撃です。たとえば、攻撃者がwww.example.com/super-secret-data/へのリクエストを送信すると、通常のWebユーザーがアクセスできないはずの場所であっても、サーバーの応答を通じて機密データを取得できてしまう可能性があります。
SSRF攻撃に対する緩和策はいくつかありますが、最も重要なものの1つは、クライアントから来るすべてのURLを検証することです。不正なURLに対しては、サーバーが直接的かつ生のレスポンスを返さないようにする必要があります。
OWASPトップ10のより技術的で詳細な説明については、公式レポートを参照してください。