Web の脆弱性を解決する (パート 1)

ウェブ

Web 上のほとんどのセキュリティ問題は、次の 3 つのカテゴリのいずれかに分類されます。
1. サーバーは、提供すべきではないサービスを一般に提供します。

2. サーバーは、プライベートであるべきデータをパブリックにアクセスできる領域に置きます。

3.サーバーは信頼できないデータ ソースからのデータに依存していました。

明らかに、多くのサーバー管理者は、ポート スキャナーの使用など、別の角度からサーバーを観察したことがありません。そうすれば、公式に Web サービスをホストするマシン上で実行する必要のないサービスや、一般に公開する必要のないサービスをシステム上で実行することは少なくなるでしょう。

このエラーによく伴うのは、メンテナンス目的で情報を盗むために使用できる特定の安全でないプロトコルを実行していることです。たとえば、一部の Web サーバーは、注文を収集するための POP3 サービスを提供したり、新しいページ コンテンツをアップロードするための FTP サービスやデータベース サービスを提供したりすることがあります。場所によっては、これらのプロトコルが安全な認証 (APOP など) や安全な送信 (POP や FTP の SSL バージョンなど) を提供する場合もありますが、多くの場合、これらのプロトコルの安全でないバージョンが使用されます。 Msql データベース サービスなどの一部のプロトコルは、認証メカニズムをほとんど提供しません。

社外から自分のネットワークにアクセスし、自分の Web サイトに対する攻撃を完全にテストおよびシミュレーションして、何が起こるかを確認することは、Web 管理者にとって良い提案です。一部のサービスは、マシンのインストール後にデフォルト構成ですでに開始されているか、インストールと初期設定の必要性により開始されています。これらのサービスは正しくシャットダウンされない可能性があります。たとえば、一部のシステムでは、非標準ポート上でプログラミングのデモンストレーションやシステム マニュアルを提供する Web サーバーが提供されており、これらには誤ったプログラム コードが含まれていることが多く、セキュリティ リスクとなります。インターネットからアクセスできる正式に実行されている Web サーバーはこれらのサービスを実行すべきではないため、必ずオフにしてください。

9.1Web サーバーの一般的な脆弱性の紹介

私たちの目的は、Web サーバーの一般的な脆弱性を紹介することです。これを読んだ後、Web サーバーの脆弱性をいくつか発見してみることもできると思います。ただし、脆弱性を見つけるために脆弱性を探さないでください。また、脆弱性が見つかったとしても、それを悪用できるかどうかは別問題です。

Web サーバーの主な脆弱性には、物理​​パスのリーク、CGI ソース コードのリーク、ディレクトリ トラバーサル、任意のコマンドの実行、バッファ オーバーフロー、サービス拒否、競合状態、クロスサイト スクリプティングの脆弱性が含まれます。これらは CGI の脆弱性に多少似ていますが、さらに多くの場所で根本的な違いがまだあります。ただし、脆弱性がどのようなものであっても、Web サーバーのセキュリティを考慮する場合は、それに適合するオペレーティング システムを考慮する必要があります。

9.1.1物理パスの漏洩

物理パスの漏洩は、一般的に、長すぎるリクエスト、慎重に作成された特別なリクエスト、またはWebサーバー上に存在しません。これらのリクエストにはすべて共通の特徴があります。つまり、リクエストされたファイルは静的な HTML ページではなく CGI スクリプトに属している必要があります。

環境変数を表示する Web サーバーの一部のプログラムが Web サーバーの物理パスを誤って出力するという別の状況もあります。これは設計上の問題であると考えられます。

9.1.2 ディレクトリ トラバーサル

ディレクトリ トラバーサルは、任意のディレクトリに「../」を追加したり、特別な意味を持つディレクトリに「../」を追加したり、「. 「..」や「..//」などの ./"、あるいはそのエンコーディングによっても、ディレクトリ トラバーサルが発生する可能性があります。前者の状況はまれですが、次の状況は非常に一般的です。昨年非常に有名になった IIS の二次デコードの脆弱性と Unicode のデコードの脆弱性は、変形されたエンコーディングと見なすことができます。

9.1.3任意のコマンドの実行

任意のコマンドの実行とは、オペレーティング システムのコマンドを実行することを意味し、主に 2 つの状況が含まれます。 1 つは、前述した二次デコードおよび UNICODE デコードの脆弱性など、ディレクトリを横断してシステム コマンドを実行することです。もう 1 つは、Web サーバーがユーザーから送信されたリクエストを SSI コマンドとして解析し、任意のコマンドを実行させることです。

9.1.4バッファ オーバーフロー

バッファ オーバーフローの脆弱性については、Web サーバーがユーザーから送信された長すぎるリクエストを適切に処理できないということに他なりません。 HTTP ヘッダー フィールド、またはその他の非常に長いデータ。この脆弱性により、細工されたデータによっては、任意のコマンドが実行されたり、サービス拒否が発生したりする可能性があります。

9.1.5サービス拒否

サービス拒否は、長すぎる URL、特殊なディレクトリ、長すぎる HTTP ヘッダー フィールド、不正な形式の HTTP ヘッダー フィールドまたは DOS デバイス ファイルなど、さまざまな理由で発生します。 Web サーバーが負荷をかけられているか、これらの特別なリクエストが正しく処理されていないため、エラーで終了するかハングします。

9.1.6 条件付き競争

ここでの条件付き競合は主に、通常はシステムまたはルートとして実行される一部の管理サーバーを対象としています。一時ファイルを使用する必要があるが、これらのファイルに書き込む前にファイルの属性をチェックしないと、一般に重要なシステム ファイルが上書きされたり、システム制御を取得したりする可能性があります。

9.2CGI のセキュリティ

次に、CGI (Common Gate Intergace) とは何かについて説明します。物理的には、CGI はサーバー上で実行され、クライアントの HTML ページとのインターフェイスを提供するプログラムです。これは理解しにくいかもしれません。それでは、実際的な例を見てみましょう。現在、ほとんどの個人ホームページにはゲストブックがあります。メッセージ ボードは次のように機能します。ユーザーはまず顧客フィールドに名前などの情報を入力します。次に、ユーザーが「メッセージを残す」をクリックすると (ここまでの作業はクライアント上で行われています)、ブラウザーはサーバーの CGI ディレクトリ内の特定の CGI プログラムに情報を送信し、CGI プログラムはサーバー上で以下に従って処理されます。あらかじめ決められた方法。この例では、ユーザーによって送信された情報は、指定されたファイルに保存されます。次に、CGI プログラムは、要求されたタスクが終了したことを示すメッセージをクライアントに送信します。この時点で、ユーザーにはブラウザに「メッセージが終了しました」という文字が表示されます。プロセス全体が終了しました。

CGI は共通のゲートウェイ インターフェイスであり、メカニズムと呼ぶことができます。そのため、Visual Basic、Delphi、C/C++ などのさまざまなプログラムを使用して、適切な CGI プログラムを作成することができます。適切なプログラムは Web サーバーのコンピュータ上で実行され、その実行結果は Web サーバーを介してクライアントのブラウザに送信されます。実際、このコンパイル方法は難しく、非効率的です。プログラムを変更するたびに、CGI プログラムを実行可能ファイルに再コンパイルする必要があるからです。

9.2.1CGI を使用する理由

CGI は、次のような多くの機能を提供します。

1. 顧客情報フォームの送信と統計

3.
4. Web データベース

たとえユーザーが知らせようとしても、HTML を使用して顧客情報を記憶する方法はありません。また、HTML を使用して特定のファイルに情報を記録することもできません。クライアントのセグメント情報をサーバーのハードディスクに記録するには、CGI を使用します。これは HTML の欠点を補う CGI の最も重要な役割です。はい、それは単なるサプリメントであり、代替品ではありません。

9.2.2 CGI のセキュリティ問題

コンピューター分野、特にインターネットでは、ほとんどの Web サーバーは、コンテンツに少しのセキュリティがある限り、コンテンツを可能な限り侵害から保護するようにプログラムされています。 CGI スクリプト パスワード ファイル、個人データなどに誤りがあると、侵入者がコンピュータにアクセスできる可能性があります。いくつかの簡単なルールに従い、CGI スクリプトを侵害から守るために常に警戒することで自分自身を守ることができます。ここで言う CGI のセキュリティには主に 2 つの側面があり、1 つは Web サーバーのセキュリティ、もう 1 つは CGI 言語のセキュリティです。一般に、CGI の問題は主に次のカテゴリに分類されます。 :

1. 機密情報または非機密情報を公開します。

3. アプリケーションにリモート オーバーフローが存在します。
5. 非汎用 CGI プログラムのプログラミングの抜け穴。


CGIの脆弱性について詳しくご紹介します。

●設定エラー

ここで言う設定エラーとは主にCGIプログラムやデータファイルの権限設定が不適切なことで、CGIのソースコードや機密情報の漏洩につながる可能性があります。もう 1 つのよくある間違いは、CGI プログラムのインストール後にインストール スクリプトを削除しないことです。これにより、攻撃者がリモートからデータをリセットできるようになります。数日前、この低レベルのミスにより、「XX Alliance」フォーラムが何度もハッキングされました。

●境界条件エラー

このエラーは主に C 言語で書かれた CGI を対象としており、攻撃者はこのエラーを利用してバッファ オーバーフロー攻撃を仕掛けて権限を昇格させる可能性があります。

●アクセス検証エラー

この問題は主に、検証に使用された条件がユーザーの身元を判断するには不十分であることが原因で発生し、多くの場合、アクセス権のないコンテンツの不正アクセス、変更、さらには削除につながります。一般に、ユーザー ID を決定するには 2 つの方法があり、1 つはアカウントとパスワード、もう 1 つはセッション認証です。安全でない認証方法には、Userid 認証、Cookie 認証などが含まれます。

●ソース検証エラー

このエラーを攻撃に使用するより一般的な方法は、サービス拒否攻撃である DoS です。たとえば、灌漑機械が CGI プログラムを使用して記事のソースを検証できないことがわかっています。 、したがって、記事を投稿すると、最終的にサーバーのハードディスクがいっぱいになってハングアップしてしまいます。

●入力検証エラー

このエラーは、主に特殊文字がフィルタリングされないために、セキュリティ上最も問題を引き起こします。たとえば、「%20」のフィルタリングに失敗すると不正な登録が発生し、「../」のフィルタリングに失敗するとシステム ファイルが漏洩することが多く、「$」のフィルタリングに失敗すると Web ページ内の機密情報が漏洩することが多く、「; " は多くの場合、任意の実行を引き起こします。 システム コマンド、"|" または "t" をフィルタリングしないとテキスト ファイル攻撃につながることが多く、"'" および "#" をフィルタリングしないと SQL データベース攻撃につながることが多く、"<" および ">" をフィルタリングしないと SQL データベース攻撃につながります。 ;」はクロスサイトスクリプティング攻撃などにつながります。

●予期せぬ状況の処理失敗

この種のエラーも非常に一般的で、ファイルが存在するかどうかを確認せずにデバイスファイルを直接開いてサービス拒否が発生したり、ファイルが存在するかどうかを確認せずにファイルを開き、解凍したりするなどです。内容の比較や検証回避、コンテキスト攻撃による任意のコード実行など

●戦略エラー

この種のエラーは、主に CGI プログラムを作成するプログラマーの判断によって引き起こされます。たとえば、元のパスワード生成メカニズムが脆弱であるため、パスワードが膨大になり、アカウントのパスワードが平文で Cookie に保存され、機密情報が漏洩し、CGI プログラムとは異なる拡張子を使用して機密情報が保存され、ファイルが破損します。直接ダウンロードされ、ユーザーの身元を確認するためのパスワード モジュールが失われると、ユーザーは、ログイン時にアカウント番号と暗号化されたパスワードを使用して、ユーザーの登録メールボックスにパスワードを送信する代わりに、パスワードを直接変更するように求められます。そのため、攻撃者はユーザーの元のパスワードを知らなくてもログインできます。

●習慣の問題

たとえば、一部のテキスト エディタを使用して CGI プログラムを変更する場合、プログラマが編集後にこれらのバックアップ ファイルを削除しないと、セキュリティの問題が発生する場合があります。 CGI ソースコードの漏洩につながる可能性があります。さらに、プログラマが常に CGI ファイルに機密情報 (アカウント パスワードなど) を入れたがる場合、攻撃者が CGI ファイルに対する読み取り権限を持っている限り (または、前に紹介した攻撃手法の一部を使用している限り)、機密情報が漏洩する可能性があります。漏れた。

●使用上のエラー

主に、Perl の「die」関数など、一部の関数の誤った使用が原因です。エラー メッセージの後に「n」が追加されていない場合、物理パスが漏洩する可能性が高くなります。 。