リバースプロキシがウェブアプリケーションのセキュリティを強化する方法
今の時代、企業がウェブ・アプリケーションを利用する機会が増えているのは周知の事実だ。ウェブ・アプリケーションは、企業の業務を合理化し、効率を高め、手作業で行っていた作業のコストを削減するのに便利です。ウェブアプリケーションは、その人気の高まりとは裏腹に、リスクやサイバー攻撃を受けやすいものです。この記事では
今の時代、企業がウェブ・アプリケーションを利用する機会が増えているのは周知の事実だ。ウェブアプリケーションは、企業の業務を合理化し、効率を高め、手作業で行っていた作業のコストを削減するのに便利です。
Webアプリケーションは、その人気の高まりにもかかわらず、リスクやサイバー攻撃を受けやすい。この記事では、ウェブアプリケーションが受けやすい重要な攻撃についての洞察を提供します。そして、脅威を最小化するためにリバース・プロキシをどのように組み込むことができるかを発見するでしょう。
しかし、セキュリティの側面に飛び込む前に、典型的なウェブアプリケーションのアーキテクチャを見てみましょう。
ウェブ・アプリケーション・アーキテクチャの概要
ウェブアプリケーション
ほとんどの場合、ウェブアプリケーションはウェブサーバーとウェブページで構成されています。ウェブサーバはクライアント（ウェブブラウザ）からのリクエストを受け付け、ウェブサーバはそのリクエストを処理し、クライアントにレスポンスを返します。
サーバーサイドはPHP、Python、ASP.NETなどの動的プログラミング言語を使ってコード化され、クライアントサイドはHTML、CSS、JavaScriptを使ってコード化される。クライアントとサーバー間の通信はHTTPプロトコルによって行われる。
ウェブアプリケーションの構造については、こちらの記事を参照してください。下図は典型的なクライアントとサーバーの通信を示しています。
上の図では、クライアントとサーバーの間でリクエストが行き来し、通信はすべて単純に見える。しかし、必ずしもそうとは限らない。
残念なことに、上記の設計を用いたウェブ・アプリケーションは、クライアントとサーバーの間で部外者によるサイバー攻撃を受ける可能性がある。
サイバー攻撃の本質に迫る前に、最も刺激的なサイバー攻撃の統計を見てみよう。
ウェブアプリケーションに対する重大な脅威とは？
サイバー攻撃に関するエキサイティングな統計
Positive Technologiesの2018年のウェブアプリケーションの脆弱性データによると、攻撃されたウェブアプリケーション全体の28%を金融・銀行業界が占めている。また、サイバー攻撃の14 %が電気通信および製造業界のオンラインアプリケーションを標的としており、11 %が輸送アプリケーションを標的としていることを示している。
その他、政府機関（11％）、IT、Eコマース、マスメディアなどがリスクに直面している。
攻撃の種類に関しては、クロスサイト・スクリプティング（4％から54％へ）とSQLインジェクション（SQLi）攻撃（15％から76％へ）が増加していると F5の別の報告書は述べている。
これらの統計から、ウェブアプリケーションを脆弱性から保護するために、いくつかの厳しい対策が必要であるという結論に 達することができます。セキュリティ上の欠陥の中には、コーディング上の問題が原因で発生するものもあれば、ウェブアプリケーションで使用され ているインフラストラクチャが不適切であることが原因で発生するものもあります。そこで、パケットのフィルタリング、HTTPトラフィックのブロック、不正なロギングによって脆弱性を最小化できるウェブ・アプリケーション・ファイアウォール（WAF）が登場する。
以下、さらに掘り下げていく。その前に、重大なセキュリティ上の脅威について簡単に説明する。
SQLインジェクション（SQLi）
SQLi-SQLインジェクションとは、ウェブ・セキュリティの脆弱性の一つで、攻撃者がアプリケーションからデータベースへのSQLクエリを操作することを許してしまうものです。そうすることで、攻撃者は、誰もが容易に到達できない潜在的に貴重な情報にアクセスできるようになります。
単純で最も身近な例は、ハッカーにとって有利になるように、サニタイズされていないユーザー入力を利用することだろう。ユーザーIDを要求するテキストボックスがあるとしよう。そして、ユーザーIDに基づいて、クエリーはそのユーザーに属するすべての情報を検索する。
つまり、ユーザーがテキストボックスに次のように入力したとする：
ユーザーID228または1=1
その結果、クエリは次のようになる：
SELECT * FROM Users WHERE UserId = 228 OR 1=1；そして、テーブルがパスワードデータを含んでいれば、パスワードを含むユーザーテーブルのすべてのデータを取得する。
SQLiの詳細については、こちらを参照してください。
クロスサイト・スクリプティング（XSS）
XSSは、主にjavascriptの悪意のあるスクリプトを、ユーザがサニタイズされていない入力フィールドを通して注入することで発生します。通常、攻撃者はこの悪意のあるスクリプトを、疑われることのないユーザーに送信します。エンドユーザーのブラウザは、このスクリプトが有害であることに気づかず、スクリプトを実行してしまいます。
その結果、この悪意のあるスクリプトは、クッキー、セッショントークン、またはその他の機密情報に関連するすべてのデータにアクセスできるようになります。さらに、これらのスクリプトはウェブページのHTMLを書き換えることができます。
壊れた認証とセッション管理
ユーザがログイン認証情報を使ってウェブ・アプリケーションにログインしなければならないとします。その場合、ウェブサイト独自のアルゴリズムが、そのセッションにおけるユーザとウェブサーバ間の全通信のために、一意なセッション ID を生成します。
ウェブ開発者が、ユーザーとウェブサーバー間を行き来する安全なデータを暗号化していない場合、侵入者がそのデータを盗み、ユーザーとして振る舞う可能性が高い。このシナリオは、主にコーヒーショップの公衆無線LANを使用してインターネットにログインするときに発生します。
詳しくはこちらの記事を参照してほしい。
ウェブ攻撃を防ぐ方法とは？
ウェブアプリケーションファイアウォール
WAFはOSIモデルにおけるレイヤー7の防御であり、下図に示すように、宛先サーバーへのエントリーポイントに配置することができる。サーバーの内部ネットワークを攻撃から保護し、サーバーのネットワーク・トポロジーを隠蔽する。
WAFを機能させるためには、サーバーに追加の設定を行う必要がある。ファイアウォールと同様に、WAFは、サーバーの内部ネットワークにとって危険と思われるHTTPトラフィックが、WAFに設定したルールを満たさない場合に、送受信のフィルタリングを行う。
WAFは、次のセクションで説明するリバースプロキシの一種でもある。
リバースプロキシ
プロキシサーバーの仕事は、あなたのIPアドレスを隠し、プロキシサーバーのIPアドレスに置き換えることです。リバースプロキシもまた同じことを行い、IPアドレスとサーバの内部ネットワークトポロジーを隠すことでウェブサーバのセキュリティを強化します。
クライアントはプロキシサーバーのアドレスしか知らないので、実際のサーバーはクライアントから隠されている。
理想的なのは、リバースプロキシを使って、上で説明したウェブアプリケーションファイアウォール（WAF）を実現することだ。リバースプロキシが設定されたデバイス上のウェブアプリケーションにWAFを実装することができる。その結果、セキュリティ強化におけるWAFの範囲が広くなる。また、攻撃者はウェブサーバの実際の場所を見ることができません。
リバースプロキシに関する基本的な情報については、 この記事を参照されたい。次のセクションでは、アプリケーションのリスクを軽減するためにリバースプロキシを使ってみることにする。しかし、その前に、リバースプロキシが何をするのかについて概観しておこう。
リバースプロキシの仕組み
すべてのリバースプロキシは、以下の基本的な操作をすべて実行する：
- クライアント・ブラウザは公開URLにHTTPリクエストを送る。URLはポート80のwww.host.com。
- それから、通常通り、ホスト名はリバースプロキシサーバを中心に解決される。このリバースプロキシサーバはこのアドレスをリッスンし、リクエストを受け取る。
- その後、リバースプロキシはリクエストをどこにプロキシする必要がある かを決定するためにURLを調査する。通常、リバースプロキシはリクエストをどこにルートするかを決定するた めに、どのようなURLコンポーネントでも使用できる。例えば、ホスト、プロトコル、パス、ポート、またはクエリー 文字列を使うかもしれない。通常、パスはルーティングを決定する主要なコンポーネントである。
- リバースプロキシのコンフィギュレーション設定は、リクエストを送信するアウトバウンドURLを決定します。この送信先URLは通常、コンテンツを提供するバックエンドサーバです。リバースプロキシサーバはリクエストの一部を書き換えるかもしれません。例えば、ルートセグメントを変更したり追加したりするかもしれません。
- リバースプロキシは、URLの再マッピングに加えて、内部ウェブサーバを示すHTTPヘッダ情報の一部も更新しなければならない。例えば、"Host: "ヘッダーは、URLのリクエスト元のホスト名を含んでいます。
- この場合、ホスト名がrealhostに変更されているのがわかる。ポート番号も8080に変更された。
- 最後に、リバースプロキシはリクエストを実際のサーバーに送り、サーバーは リクエストを処理する。
- サーバーはリクエストを処理した後、応答をリバースプロキシに送る。
- そして、リバースプロキシは以下のことを行う：
- これは、クライアントに正しく送信されるようにレスポンスを修正します。これには "Location: "フィールドが含まれます。
- リバースプロキシはヘッダーを再マッピングし、最後にクライアントに応答を送信する。
リバースプロキシでWebアプリケーションを保護する方法
我々の目的は、先に述べたサイバー攻撃を克服することなので、リバースプロキシは、上記のステップの他に、追加の機能を実行する必要がある。
リクエスト内容の検証
クライアントがサーバにリクエストを送ると、リバースプロキシはそのシグネチャデータベースと比較することによって入力をサニタイズする。プログラマは高度な正規表現を使ってこれらのシグネチャを開発する。リバースプロキシがユーザー入力によるリクエストを許可するかどうかの 決定は、ブロックリストフィルタとホワイトリストフィルタのアプローチに だけ基づいて行われる。
ブラックリスト・フィルターのアプローチ
ブラックリストフィルターは既知の有害なリクエストを保存する。そして各リクエストをリストのエントリと比較する。マッチするものを発見した場合、リクエストは拒否される。同じ攻撃の異なるバリエーションはリストに別々に記録されなければならない。ブラックリストの包括性はその有効性を助ける。
ホワイトリストフィルターのアプローチ
ホワイトリストフィルタは、特定のサイトに対する有効なリクエストの全集 合を捕捉します。その結果、ホワイトリストは既知のリクエストだけがサーバーに到達することを許可することで、攻撃を防ぎます。一方、ホワイトリストを構築するプロセスは時間がかかり、ユーザーがサーバーに送る可能性のある正当なリクエストの全範囲を知る必要があります。
さらに、SQLインジェクションが発生した場合、何十万ものデータベースベンダーに有効なリクエストを作成するのは大変です。
セキュリティで保護されたウェブ・アプリケーションに変更を加えると、ホワイトリストの更新が必要になる。その結果、ホワイトリストを維持することは管理者の負担を増やすことになる。
応答内容の検証
サーバからの応答をクライアントに送り返す前に、リバースプロキシはその応答を検証する。通常、ブラックリストがこのために使われる。ブラックリストフィルターは、見る必要のないクライアントから既知の 応答を隠すかもしれない。エラーメッセージはこの種のデータの例である。リバースプロキシは、 エラーを機密データを含まない一般的なエラーメッセージに置き換えることが できる。
リクエストとレスポンスのログ
リバースプロキシは、その後の検査のためにリクエストをログに記録 することもできる。最良の方法は、リバースプロキシが最初にブロックしたリクエストだけの ログを設定することである。インストールの最初の段階を通してログを注意深く調べるべきである。これは、リバースプロキシが 本物のリクエストをブロックしていないことを確認するために不可欠である。
結論
この記事では、ウェブアプリケーションの脆弱性と、これらの脅威を解決するためにリバースプロキシ をどのように利用できるかを理解していただければ幸いです。実際、リバースプロキシはウェブアプリケーションに関連する可能性のある脆弱性をすべて排除するわけではありません。
しかし、ウェブ・アプリケーションで遭遇する脅威のほとんどを軽減するための素晴らしい戦略でしょう。ですから、最後に、あなたのウェブ・アプリケーションでセキュリティ上の懸念が発生した場合に、この記事で学んだ 概念を適用してくれることを願っています。