オープンウェブアプリケーションセキュリティプロジェクトは、Webアプリ ケーションのセキュリティに関する最も差し迫った問題のリストを定期的に更新しています。
この記事を読み終えると、以下のこ とができるようになります。
関連コンテンツ
サインアップして、Cloudflareからセキュリティ関連の学習用記事をお受け取りください。
記事のリンクをコピーする
オープンウェブアプリケーションセキュリティプロジェクト（OWASP）は、Webアプリケーションセキュリティに特化した国際的な非営利組織です。OWASPの中核となる原則の1つは、すべての資料がWebサイトで無料で入手でき、簡単にアクセスできるため、誰でも独自のWebアプリケーションのセキュリティを向上できることです。彼らが提供する資料には、文書、ツール、ビデオ、フォーラムが含まれます。おそらく彼らの最も有名なプロジェクトはOWASPトップ10です
OWASPトップ10は、Webアプリケーションのセキュリティに関するセキュリティ上の懸念を概説する定期的に更新されるレポートであり、最も重要な10のリスクに焦点を当てています。このレポートは、世界中のセキュリティ専門家チームによってまとめられています。 OWASPは、トップ10を「認識文書」と呼び、セキュリティリスクを最小化および/または軽減するために、すべての企業がレポートをプロセスに組み込むことを推奨しています。
以下は、OWASPトップ10 2017レポートで報告されたセキュリティリスクです
インジェクション攻撃は、信頼できないデータがフォーム入力またはWebアプリケーションへの他のデータ送信を介してコードインタープリターに送信されるときに発生します。たとえば、攻撃者はSQLデータベースコードをプレーンテキストのユーザー名を想定したフォームに入力することができます。そのフォーム入力が適切に保護されていない場合、そのSQLコードが実行されることになります。これは SQLインジェクション攻撃として知られています。
ユーザーが送信したデータを検証またはサニタイズすることにより、インジェクション攻撃を防止することができます。 （検証とは、疑わしいデータを拒否することを意味し、サニタイズとは、データの疑わしい部分をクリーンアップすることを指します。）さらに、データベース管理者は、インジェクション攻撃が公開できる情報量を最小限に抑えるためのコントロールを設定できます。
認証（ログイン）システムの脆弱性により、攻撃者はユーザーアカウントにアクセスでき、管理者アカウントを使用してシステム全体を侵害することもできます。たとえば、攻撃者はデータ漏えい中に取得した数千の既知のユーザー名/パスワードの組み合わせを含むリストを取得し、スクリプトを使用してログインシステムでそれらのすべての組み合わせを試して、機能するものがあるかどうかを確認できます。
認証の脆弱性を軽減するためのいくつかの戦略には、2要素認証（2FA）が必要とするものと、レート制限を使用して繰り返しログイン試行を制限または遅延させるものがあります。
Webアプリケーションが金融情報やパスワードなどの機密データを保護しない場合、攻撃者はそのデータにアクセスし、売り手はそれを悪意のある目的で利用できます。機密情報を盗むための1つの一般的な方法は、オンパス攻撃です。
すべての機密データを暗号化し、機密情報のキャッシュ*を無効にすることにより、データ漏えいリスクを最小限に抑えることができます。さらに、Webアプリケーション開発者は、機密データを不必要に保存しないように注意する必要があります。
*キャッシュは、再利用のためにデータを一時的に保存する方法です。たとえば、Webブラウザは多くの場合Webページをキャッシュするため、ユーザーが一定の時間内にそれらのページに再アクセスした場合、ブラウザはWebからページを取得する必要がありません。
これは、XML *入力を解析するWebアプリケーションに対する攻撃です。この入力は、パーサーの脆弱性を悪用しようとする外部エンティティを参照できます。このコンテキストでの「外部エンティティ」とは、ハードドライブなどのストレージユニットを指します。 XMLパーサーは、許可されていない外部エンティティにデータを送信するようになり、機密データを攻撃者に直接渡すことができます。
XEE攻撃を防止する最良の方法は、WebアプリケーションにJSON **などのそれほど複雑でないタイプのデータを受け入れさせるか、少なくともXMLパーサーにパッチを当てて、XMLアプリケーションで外部エンティティの使用を無効にすることです。
* XMLまたはエクステンシブルマークアップランゲージは、人間が読める形式と機械が読める形式の両方を対象としたマークアップ言語です。その複雑さとセキュリティの脆弱性のため、多くのWebアプリケーションで使用されなくなりました。
** JavaScriptオブジェクトノーテーション（JSON）は、インターネット経由でデータを送信するためによく使用される単純で人間が読める形式の表記法です。元々JavaScript用に作成されましたが、JSONは言語に依存せず、さまざまなプログラミング言語で解釈できます。
アクセス制御とは、情報または機能へのアクセスを制御する仕組みを指します。不正アクセス制御により、攻撃者は認証をバイパスし、管理者などの特権ユーザーであるかのようにタスクを実行できます。たとえば、Webアプリケーションでは、他の検証なしで、URLの一部を変更するだけで、ユーザーがログインしているアカウントを変更できます。
Webアプリケーションが認証トークン*を使用し、それらに厳密な制御を設定することにより、アクセス制御を保護できます。
*多くのサービスは、ユーザーのログイン時に認証トークンを発行します。ユーザーが行うすべての特権リクエストでは、認証トークンが必要です。これは、ログイン資格情報を絶えず入力する必要なく、ユーザーが本人であることを保証する安全な方法です。
不適切なセキュリティ設定は、リストで最も一般的な脆弱性であり、多くの場合、デフォルトの構成を使用したか、過度に詳細なエラーを表示した結果です。たとえば、アプリケーションはユーザーに過度に記述的なエラーを表示し、アプリケーションの脆弱性を明らかにする可能性があります。これは、コード内の未使用の機能を削除し、エラーメッセージがより一般的になるようにすることで軽減できます。
クロスサイトスクリプティングの脆弱性による影響は、WebアプリケーションがユーザーがURLパスまたは他のユーザーに表示されるWebサイトにカスタムコードを追加することを許可している場合に発生します。この脆弱性は、被害者のブラウザで悪意のあるJavaScriptコードを実行するために悪用される可能性があります。たとえば、攻撃者は、信頼できる銀行から送られたように見える内容でその銀行のWebサイトへのリンクが記載された電子メールを被害者に送信できます。このリンクには、URLの最後に悪意のあるJavaScriptコードがタグ付けされている可能性があります。銀行のサイトがクロスサイトスクリプティングから適切に保護されていない場合、被害者がリンクをクリックすると、その悪意のあるコードが被害者のWebブラウザで実行されます。
クロスサイトスクリプティングの軽減戦略には、信頼されていないHTTPリクエストからのエスケープ、ユーザー生成コンテンツの検証および/またはサニタイズが含まれます。ReactJSやRuby on Railsなどの最新のWeb開発フレームワークを使用すると、組み込みのクロスサイトスクリプティング保護も提供されます。
この脅威は、データを頻繁にシリアル化およびデシリアル化する多くのWebアプリケーションを対象としています。シリアル化とは、アプリケーションコードからオブジェクトを取得し、データをディスクに保存したりストリーミングしたりするなど、別の目的に使用できる形式に変換することを意味します。デシリアル化は正反対です。シリアル化されたデータをアプリケーションが使用できるオブジェクトに変換します。シリアル化は、引っ越し前に家具を箱に詰めるようなもので、デシリアル化は、引っ越し後に箱を開梱して家具を組み立てるようなものです。安全でないデシリアライゼーション攻撃は、引っ越し業者が開梱される前にボックスの内容を改ざんするようなものです。
安全でないデシリアライゼーションエクスプロイトは、信頼できないソースからのデータをデシリアライズした結果であり、DDoS攻撃やリモートコード実行攻撃などの深刻な結果をもたらす可能性があります。デシリアル化の監視や型チェックの実装など、攻撃者を捉えようとする手段を講じることができますが、安全でないデシリアル化攻撃から保護する唯一の確実な方法は、信頼できないソースからのデータのデシリアル化を禁止することです。
最新のWeb開発者の多くは、Webアプリケーションでライブラリやフレームワークなどのコンポーネントを使用しています。これらのコンポーネントは、開発者が冗長な作業を避け、必要な機能を提供するのに役立つソフトウェアです。一般的な例には、Reactなどのフロントエンドフレームワークや、共有アイコンやa/bテストの追加に使用される小さなライブラリが含まれます。一部の攻撃者は、これらのコンポーネントの脆弱性を探し、それらを使用して攻撃を調整することができます。より人気のあるコンポーネントの一部は、数十万のWebサイトで使用されています。攻撃者がこれらのコンポーネントの1つにセキュリティホールを見つけると、何十万ものサイトが悪用されやすくなります。
コンポーネント開発者は多くの場合、既知の脆弱性を補うためのセキュリティパッチと更新を提供しますが、Webアプリケーション開発者は、アプリケーションで実行されているコンポーネントのパッチ済みまたは最新バージョンを常に持っているとは限りません。既知の脆弱性を持つコンポーネントを実行するリスクを最小限に抑えるために、開発者はプロジェクトから未使用のコンポーネントを削除し、信頼できるソースからコンポーネントを受け取り、最新のものであることを確認する必要があります。
多くのWebアプリケーションは、データ漏えいを検出するのに十分な手順を実行していません。漏えいの発見時間の平均は、発生してから約200日です。これにより、攻撃者は応答を受け取る前にダメージを与えるための多くの時間を費やすことができます。 OWASPは、Web開発者がアプリケーションへの攻撃を確実に認識できるように、ログと監視、および事故対応計画を実装することを推奨します。
OWASPトップ10のより技術的で詳細な説明については、公式レポートを参照してください。