目次


Web アプリケーションのセキュリティー: 脆弱性をテストする

オープンソースのツールを使って自分のサイトをテストしてみてください

Comments

Web がより一層社会的な性質を帯びるようになるにつれて、Web の安全性は逆に薄れてきています。事実、WASC (Web Application Security Consortium) では 2009年の初めに、全 Web サイトの 87% が攻撃に対して脆弱な状態にあると推定しています (詳細は「参考文献」を参照)。一部の企業はサイトにセキュリティー上の弱点がないかどうかをテストするために、外部のセキュリティー・アナリストを雇うだけの余裕があるものの、すべての企業や個人が外部セキュリティー監査に 20,000 米ドルから 40,000 米ドルの資金をつぎ込めるわけではありません。こうした資金に余裕がない組織ではセキュリティーのプロを雇う代わりに、社内の開発者がサイトに対する攻撃の脅威を理解し、自分たちが作成するコードにそのような脆弱性がないようにすることを期待するようになってきています。

セキュアなコードを作成するためには、何よりもまず、コードがさらされている脅威を理解しなければなりません。この記事では一般に見受けられる脆弱性のなかでも特に多い、クロスサイト・スクリプティング (XSS) や SQL インジェクションといった攻撃に対する脆弱性について見ていきます。さらに、サイトの安全を確保するだけでなく、サイトを構成するデータやネットワークの安全も確保するために使用できるツールを紹介します。この記事はセキュリティー・アナリストの代わりとなるものでも、本格的なセキュリティー・スキルを説明するものでもありません。記事で焦点とするのは、コードに存在する潜在的なセキュリティー上の弱点を突き止め、その脆弱性を修正する方法を説明することです。

よく見受けられる脆弱性

まずはこの記事で見ていく脆弱性について理解しなければなりません。脆弱性のなかでも圧倒的によく見られるのは、クロスサイト・スクリプティング (XSS) です。XSS は、悪意のあるスクリプトが Web サイトに注入されることによって発生します。例えば、Mallory が、Alice によって作成された信頼できる Web サイトにユーザーを送り込むスクリプトを作成したとします。Mallory はこのスクリプトを人気の高いフォーラムに挿入しました。フォーラムでこのリンクを見た Bob は、リンクをクリックして Alice の Web サイトにアカウントを作成します。するとこのスクリプトは、Alice の Web サイトにある XSS の弱点を悪用し、Bob の cookie を Mallory に送信します。これで Mallory は Bob の振りをして、彼の情報を盗めるようになるというわけです。

脆弱性として 2 番目によく見られるのは、SQL インジェクションです。これは主に、Web サイトがますますデータベースに依存するようになったことに起因しています。SQL インジェクションは実際にはかなり単純な攻撃で、悪意のあるハッカーがデータベースに接続する Web サイトを見つけ、そのサイトの開発者の意図とはまったく異なる目的で SQL クエリーを実行し、認証を迂回したり、データを操作したりするというものです。Albert Gonzalez (訳注: Albert Gonzalez とは米国史上最大規模のデータ窃盗の罪で 2009年 8月に起訴された被告) が 1 億 3000 万ものクレジット・カード番号を盗むために使ったのも、このタイプの攻撃でした。SQL インジェクションによる攻撃では、例えば Alice が電子機器を販売するために作成した Web サイトを Mallory が見つけたとすると、Mallory は通常のユーザー名とパスワードを入力する代わりに、ユーザー名として「‘) OR 1=1-」と入力します。このようにハイフン (-) を含めてあるため、他には何も必要ありません。1=1 は常に真となることから、彼女はログインに成功するはずです。これで、Mallory はデータベースを操作して Bob の顧客情報を盗むことができます。この例で取り上げたのは最も単純な形での SQL インジェクションですが、この説明から、アタッカーにとって SQL インジェクションがいかに簡単な攻撃手段になるかがわかるはずです。

セキュリティー・アナリストからなる専門のチームなしに、平均的な Web 開発者がこれらの脆弱性に対処するのは不可能のように思えるかもしれません。しかし幸い、そんなことはありません。サイトの脆弱性を見つけるために利用できる数々のツールの助けを借りれば、脆弱性をついた攻撃からサイトを守るために必要な措置を講じることができます。例えば WebScarab や Paros などのツールはブラウザーとサーバーとの間でのやり取りをキャプチャーするだけでなく、潜在するリスクを見つけ出せるように Web サイトをクローリングするため、この情報を基にサイトの脆弱性をチェックして対処することができます。

WebScarab

OWASP (Open Web Application Security Project) によって開発された WebScarab は、ブラウザーのリクエストとサーバーの応答を分析するために使用できるプロキシーとして、真っ先に挙げられるツールです。WebScarab はパケット分析のツールとして機能するだけでなく、サイトに前述のセキュリティー上の弱点がないかどうかを調べるためのファズ・テストにも使用することができます。WebScarab を使用するにはまず、使用している Web ブラウザーでプロキシーの情報を設定する必要があります。Mozilla Firefox の場合、その手順は以下のとおりです (この手順で説明している操作の代わりに使用できる操作方法については、Firefox のキーボード・ショートカットを参照してください)。

  1. 「Tools (ツール)」 > 「Options (オプション)」 > 「Advanced (詳細)」 > 「Network (ネットワーク)」の順にクリックします。
  2. Settings (接続設定)」をクリックします。

    すると、「Connection Settings (インターネット接続)」ウィンドウが開きます。

  3. Manual proxy configuration (手動でプロキシを設定する)」オプションを選択します。
  4. HTTP Proxy (HTTP プロキシ)」と「SSL Proxy (SSL プロキシ)」の両方に、「localhost」と入力し、ポートを「8008」に設定します。
  5. No proxy for (プロキシなしで接続)」ボックスが空であることを確認してから、「OK」をクリックします。

図 1 に、Firefox の接続設定を示します。

図 1. Firefox の接続設定
スクリーン・ショット: 「Manual proxy configuration (手動でプロキシを設定する)」が選択されている状態です。「HTTP Proxy (HTTP プロキシ)」にはアドレスとして「localhost」という値が設定され、その「Port (ポート)」には「8008」という値が設定されています。「SSL Proxy (SSL プロキシ)」にはアドレスとして「localhost」という値が設定され、その「Port (ポート)」には「8008」という値が設定されています。また、「SOCKSv5」が選択されています。
スクリーン・ショット: 「Manual proxy configuration (手動でプロキシを設定する)」が選択されている状態です。「HTTP Proxy (HTTP プロキシ)」にはアドレスとして「localhost」という値が設定され、その「Port (ポート)」には「8008」という値が設定されています。「SSL Proxy (SSL プロキシ)」にはアドレスとして「localhost」という値が設定され、その「Port (ポート)」には「8008」という値が設定されています。また、「SOCKSv5」が選択されています。

Windows® Internet Explorer® の場合は、以下の手順に従ってください (この手順で説明している操作の代わりに使用できる操作方法については、IE の「ヘルプ」メニューから Internet Explorer キーボード・ショートカットを参照してください)。

  1. 「Tools (ツール)」 > 「Internet Options (インターネット オプション)」 > 「Connections (接続)」の順にクリックします。
  2. LAN Settings (LAN の設定)」をクリックして「Proxy Settings (ローカル エリア ネットワーク (LAN) の設定)」ウィンドウを開きます。
  3. Proxy Servers (プロキシ サーバー)」の下にある「Use a proxy server for your LAN (LAN にプロキシ サーバーを使用する)」チェック・ボックスを選択し、「Advanced (詳細設定)」をクリックします。
  4. HTTP」と「Secure」に、使用するプロキシのアドレスとして「localhost」と入力し、ポートには「8008」と入力します。
  5. Exceptions (例外)」ボックスが空であることを確認してから、「OK」をクリックします。

図 2 に、Internet Explorer でのプロキシー設定を示します。

図 2. プロキシーの設定
プロキシーの設定: 「HTTP」にはアドレスとして「localhost」という値が設定され、ポートとしては「8008」という値が設定されています。「Secure」にもアドレスとして「localhost」という値が設定され、ポートとしては「8008」という値が設定されています。
プロキシーの設定: 「HTTP」にはアドレスとして「localhost」という値が設定され、ポートとしては「8008」という値が設定されています。「Secure」にもアドレスとして「localhost」という値が設定され、ポートとしては「8008」という値が設定されています。

これで、Web サイトをスキャンする準備は整いました。

WebScarab によるサイトのスキャン

以降の例では、Hacme Casino というサイトを使用します。これは、Foundstone がトレーニング用として使えるように、特定の脆弱性を持たせて作成したサイトです (「参考文献」を参照)。このサイトには Apache Tomcat もパッケージ化されているため、必要であればローカルで実行することもできます。

WebScarab を開いてください。ツールを起動すると、「Summary」と「Intercept」 という 2 つのタブだけが表示されます。ここではファジングの目的で WebScarab を使用するので、ビューを変更するために「Tools」 > 「Use full-featured interface」 > 「OK」の順にクリックします。この操作によって、WebScarab を再起動するように求められるので、メッセージに従って再起動すると、図 3 に示すインターフェースが最初から使用できる状態になります (WebScarab にはキーボード・ショートカットもありますが、その数は残念ながら 2 つしかありません)。

図 3 . WebScarab インターフェース
WebScarab インターフェースのスクリーン・ショット。表示されている複数のタブには、「Spider」、「Extensions」、「XSS/CRLF」、「SessionID Analysis」、「Scripted」、「Fragments」、「Fuzzer」、「Compare」、「Search」、「Summary」、「Messages」、「Proxy」、「Manual Request」、「Web Services」があります。そのなかで、「Summary」タブが開いた状態です。
WebScarab インターフェースのスクリーン・ショット。表示されている複数のタブには、「Spider」、「Extensions」、「XSS/CRLF」、「SessionID Analysis」、「Scripted」、「Fragments」、「Fuzzer」、「Compare」、「Search」、「Summary」、「Messages」、「Proxy」、「Manual Request」、「Web Services」があります。そのなかで、「Summary」タブが開いた状態です。

セッションを新たに開始するには「File」 > 「New」の順に選択します。すると、セッションを保存するかどうかを尋ねるボックスが表示されるので、保存先のディレクトリーを選択するか、作成してから「OK」をクリックします。WebScarab を Hacme Casino で使用するときには、ブラウザーを開く前にサーバーを起動しておいてください。ブラウザーを開いたら、アドレス・バーに http://localhost:3000 と入力します。

するとブラウザーの画面には、早速 WebScarab でのアクティビティーが表示されるはずです。これは、WebScarab がブラウザーとサーバーとの間で行われるすべてのリクエストとレスポンスをキャプチャーしているためです。ファジング機能を使用して脆弱性をテストする場合、最初に各種の脆弱性が存在する可能性のある場所を調べなければなりません。セキュリティー上の弱点があるかどうかを最初に調べる場所は、ログインです。ログインをテストするためには、ブラウザーとサーバーとの間で行われるやりとりを記録する必要があります。正常にログインする必要はないので、ユーザー名とパスワードには何を入力しても構いません。この例では、ユーザー名とパスワードの両方に「casino」と入力してから、「Login」をクリックします。

ログインは当然成功しませんが、調べているのはログインが成功するかどうかではないので、構わず WebScarab に戻ってください。WebScarab に戻ったら、「Path」列で「account\login」を右クリックし、表示されるメニューで「Use as fuzz template」をクリックします (図 4 を参照)。

図 4. ファジング・テンプレート
ファジング・テンプレートのスクリーン・ショット。スプレッド・シートのようなビューに各種の Web リンク・データが表示されています。
ファジング・テンプレートのスクリーン・ショット。スプレッド・シートのようなビューに各種の Web リンク・データが表示されています。

続いて、以下の手順を実行します。

  1. WebScarab インターフェースの上端にある「Fuzzer」タブをクリックします。
  2. Source」をクリックします。
  3. 使用するディクショナリーの場所までブラウズします (ここで使用したのは all_attack.txt です。「参考文献」のリンクを参照)。
  4. ソースの説明を入力し、「Add」をクリックします。
  5. Close」をクリックして「Fuzzer」ウィンドウに戻ります。

今度は user_login パラメーターに進み、「Fuzz Source」列の下にある領域をクリックします。ロードしたソースは 1 つだけなので (All attack)、ドロップダウン・メニューからこのソースを選択します。user_password についても、これと同じ操作を繰り返します (図 5 を参照)。

図 5. 攻撃ファイルの選択
攻撃ファイルのスクリーン・ショット。編集可能な各種パラメーターが一覧表示されています。
攻撃ファイルのスクリーン・ショット。編集可能な各種パラメーターが一覧表示されています。

これでソースは定義できたので、「Start」をクリックしてプロセスを開始します。ファザーはソースとして定義したファイルに記載されているパラメーターをユーザー名とパスワード両方の入力に挿入します。画面上には、ツールがそれぞれの試行を完了するごとに何らかのアクティビティーが表示されます。通常は、結果に示された各 ID を調べ、それぞれの試行で行われた内容を分析する必要がありますが、この例では追加したストリングによって、ある結果が生成されることはわかっているので、ファザーがファズ・テストに成功するとどのような動作をするのか確認することができます。

図 6 の画面例では、最初のストリングをダブルクリックします。

図 6. 脆弱性の調査
あるページに対して解析された情報を示すスクリーン・ショット。URL エンコード変数「user_login」および「user_password」の値が円で囲まれています。解析結果の下に表示されている「Location」および「Site Cookie」の値も円で囲まれています。
あるページに対して解析された情報を示すスクリーン・ショット。URL エンコード変数「user_login」および「user_password」の値が円で囲まれています。解析結果の下に表示されている「Location」および「Site Cookie」の値も円で囲まれています。

図に示された 2 つの円のうち、上のほうの円で囲まれている「user_login」および「user_password」の値はどちらも「‘) OR 1=1--」となっていることに注意してください。また、下のほうの円で囲まれている「Location」が、ホーム・ページである http://localhost:3000 から http://localhost:3000/lobby/games に変更されていることも注目の点です。ログインに成功したユーザーには、この変更後の URL のページが表示されることになります。「Location」の値が変更されるということが何を意味するかと言えば、そのサイトが脆弱であることを示しています。「‘) OR 1=1--」は SQL ストリングであることから、そのサイトは SQL インジェクションの攻撃を受けやすいことになります。「Next」ボタンを使って解析結果をスクロールし、「Location」の値を調べてください。「Location」は http://localhost:3000 のままになっているはずです。このことから、「'or 'x'='x」のようなストリングを挿入しても、ログイン試行は成功しないことがわかります。つまりこのサイトは、「'or 'x'='x」による攻撃に対しては脆弱ではありません。

Paros Proxy

Paros Proxy も同じく、セキュリティーのテストに役立つツールです。WebScarab と同様、Paros はブラウザーとサーバーとの間のやりとりをキャプチャーして分析できるようにします。また、このツールはサイト上の脆弱性をテストするためにも使用することができます。Paros を実行するには、ブラウザーのプロキシー設定で使用されているポート番号を変更する必要があります。WebScarab の場合はポート 8008 を使用しましたが、このポートを 8080 に変更してから Paros を実行してください。このように変更しないと、Paros は機能しません。この演習での例では、OWASP による別のツール WebGoat を使用します (「参考文献」を参照)。Hacme Casino と同じく、WebGoat は Tomcat サーバーをローカル・ホストとして使用して動作します。この記事では、Paros によるスキャンを行うと Hacme Casino サイトでの場合より多くの脆弱性が WebGoat に見つかることを明らかにします。

ポートを変更したら、Paros を開きます。その後は、次の手順に従います。

  1. WebGoat フォルダー内の WebGoat.ba をダブルクリックして Tomcat を起動します。
  2. ブラウザーを開き、http://localhost/WebGoat/attack と入力します。
  3. ユーザー名とパスワードの両方に guest と入力します。
  4. Start WebGoat」をクリックします。

Paros に戻り、WebGoat サイトのスキャンを開始します。このサイトではなく、独自のサイトを使用することももちろん可能です。その場合には、アドレス・バーにそのサイトの URL を入力してください。

Parosのツリーに http://localhost を表示するために、Sites フォルダーを展開します。このフォルダーを展開すると WebGoat が表示されます。WebGoat を強調表示した後、「Analyse Scan」をクリックします。すると瞬時にサイトのスキャンが始まります。大きなサイトであればスキャンにしばらく時間がかかりますが、このサイトの場合は数秒で完了するはずです。スキャンが開始されると同時に、一番下のペインは自動的に「Alerts」タブに切り替わります (図 7 を参照)。スキャンが完了するとレポートの配置場所を通知するポップアップ・ウィンドウが表示されるので、このウィンドウで「OK」をクリックします。

図 7. アラートの表示
アラート画面。標準的な IDE スタイルの分割ウィンドウが表示されており、左上のペインにはサイトのツリーがあり、右上のペインには左上のペインで選択された項目に関する詳細情報があり、下のペインにはアラートのツリーがあります。
アラート画面。標準的な IDE スタイルの分割ウィンドウが表示されており、左上のペインにはサイトのツリーがあり、右上のペインには左上のペインで選択された項目に関する詳細情報があり、下のペインにはアラートのツリーがあります。

アラートを展開することで、それぞれのアラートに関する詳細を表示することができます。また、さらに詳しい情報が記載されたレポートを表示することもできますが、まずはスキャン結果を保存してください。それには「File」 > 「Save As」の順にクリックし、スキャン結果の保存先とファイル名を選択して「Save」をクリックします。

レポートを表示するには、「Report」 > 「Last Scan Report」の順にクリックします。ポップアップ・ウィンドウで「OK」をクリックすると、新しいブラウザー・タグが開き、そこにスキャン結果のレポートが表示されます (図 8 を参照)。このレポートは、検出された脆弱性それぞれに関する極めて詳しい情報を提供します。この情報には、その特定の脆弱性について取り上げている OWASP ページへの参照も含まれます。

図 8. Paros のレポート
Paros レポートのスクリーン・ショット。先頭にはアラートについて要約した表が記載され、その下に各アラートの詳細が表示されています。
Paros レポートのスクリーン・ショット。先頭にはアラートについて要約した表が記載され、その下に各アラートの詳細が表示されています。

誤判定に対するテスト

スキャナーは Web サイトに考えられる脆弱性を見つける上で有効な手段となるものの、代表的なセキュリティー企業では、誤判定の可能性がある脆弱性については常に手動によるテストを行っています。セキュリティー上の弱点がないかどうかをテストするということは、脆弱であるとレポートされたサイトの該当部分に実際にアクセスし、サイト自体に SQL コードまたはスクリプトを挿入して応答を調べ、続いてサイトの内部で何らかの脆弱性実証コードを実行してみるということです。大手企業ではこのようなテスト (脆弱性検証) を専門とするプロのプログラマーを雇うのが通常ですが、開発者自身でもこのようなテストを実行することができます。テストを行うことによって、サイトのセキュリティーを多少なりとも強化できるだけでなく、今後サイトを構築する際の参考にもなります。

SQL インジェクションによる誤判定

再び Hacme Casino サイトを例に、WebScarab が検出した、ログイン時の SQL インジェクションに対する脆弱性について検討してみましょう。Hacme Casino が実行中の状態で、サイトの「Login」入力域に、WebScarab が使用して上手くいった SQL コード「‘) OR 1=1--」を入力します。そして「Login」をクリックすると、Andy_Aces というアカウントが開きます。「1=1」は真になるはずなので、ここで、最も基本的な形での SQL インジェクションが功を奏していることになります。Andy に関しては、彼は運悪く、データベースに格納された最初のアカウントだったというだけです。

この SQL インジェクションが上手くいく仕組みについて考えてみてください。バックエンドでは、データベースが以下のようなクエリーを実行します。

SELECT * FROM users WHERE (username=username AND password=password)

Login」ボックスから注入されたコードは、上記の有効なクエリーを以下のように変換します。

SELECT * FROM users WHERE (username=’’) OR 1=1—AND password=’’)

このクエリーが、サイトの最初のユーザー、つまり不幸にも Andy のログイン成功を返すというわけです。

もちろん、この例は SQL インジェクションのうわべをかじっているだけにすぎません。アタッカーは Web サイトに対する攻撃の腕を磨くにつれ、この脆弱性を実際に悪用し、ユーザーを作成したり、パスワードを変更したり、サイトから機密データを抽出したりできるようになります。サイトをこれらの攻撃から守るには、以下の対策を講じる必要があります。

  • データベースへのアクセスには、ストリングの連結を使用するのではなく、パラメーターを使ったクエリー、またはストアード・プロシージャーを使用すること。パラメーターを使ったクエリーでは、すべての SQL コードを定義し、以降のクエリーに対してそれぞれのパラメーターを渡さなければなりません。そのため、データベースがコードとデータを区別できるようになり、ユーザーがどのような入力をしようと問題ではなくなりなります。ストアード・プロシージャーは、SQL コードを定義した上でパラメーターを渡すという点ではパラメーターを使ったクエリーと同様ですが、ストアード・プロシージャーの場合、SQL コードはデータベース自体に定義および保管されてから、アプリケーションによって呼び出されるという点が異なります。
  • 許容される文字をホワイトリスト化することによって、ユーザー入力をサニタイズすること。名前の入力には a から z、および A から Z の文字だけを許容し、電話番号は 0 から 9 の数字だけに制限します。この場合の検証には、データベースがサポートしている適切な検証手法を使用してください。
  • データベースによってセットアップされた文字エスケープ・スキームを使用して、ユーザー提供の入力をエスケープすること。特殊文字をエスケープすることで、クエリーに提供された文字はコードではなく、実際にはデータであることがデータベースに伝わります。ユーザーによるすべての入力が適切なスキームによってエスケープされても、データベースがその入力と、開発者が作成した SQL コードとを混同することはありません。
  • アタッカーには決して手を貸さないこと。エラー・メッセージには後でサイトを攻撃するために使用できるような情報が含まれないようにしてください。

XSS による誤判定

XSS 攻撃の一例を説明するため、再び WebGoat を使用します。このサイトでまず、「Cross Site Scripting」 > 「LAB: Cross Site Scripting」 > 「Stage 1: Stored XSS」の順にクリックします。デモ・サイト (Goat Hills Financial) にログインするには、ユーザー名として Larry Stooge、パスワードとして larry と入力します。アタッカーであれば、ここで、悪意のあるスクリプトを入力する場所を探すことになります。おそらく Search Staff 機能には名前を入力できるテキスト・ボックスがあるはずです。「Search Staff」をクリックすると、それが明らかになります (図 9 を参照)。

図 9. XSS の注入ポイント
Goat Hills Financial Human Resources の場合の XSS 注入ポイントのスクリーン・ショット。ユーザーを検索するためのテキスト・フィールドと、「FindProfile」というラベルの付いたボタンが表示されています。
Goat Hills Financial Human Resources の場合の XSS 注入ポイントのスクリーン・ショット。ユーザーを検索するためのテキスト・フィールドと、「FindProfile」というラベルの付いたボタンが表示されています。

Name」ボックスに、「alert("You got me with XSS");」と入力します。このスクリプトは図 10 のようなアラート・ボックスを表示するだけですが、例えばスクリプトがユーザーを偽の人材サイトにリダイレクトするもので、そのサイトではユーザーが自分の社会保障番号 (訳注: 社会保障番号は、米国社会保障局が米国の住民に対して発行している、個人を特定できる番号)、自宅の住所、銀行口座の情報などを入力しなければならない場合を考えてみてください。「OK」ボタンに関連付けられたアクションを変更すれば、それはあり得る話です。創造力に富んだ悪意のあるハッカーにとって、ユーザーが信用する限り、可能性は無限です。

図 10. XSS 攻撃の成功
「You got me with XSS」というメッセージとその下に「OK」ボタンが表示された警告ボックス。
「You got me with XSS」というメッセージとその下に「OK」ボタンが表示された警告ボックス。

XSS 攻撃を防ぐには、すべての入力を問題のない入力へと変換する必要があります。この処理は、入力を後でオペレーティング・システムのコマンドやスクリプト、データベース・クエリーのパラメーターとして使用する場合には不可欠です。ユーザー入力を問題のない入力へと変換するには、信頼できないデータを HTML 要素のコンテンツまたは HTML の共通属性に挿入できるようにする前に、そのデータをエスケープします。HTML の共通属性の場合、OWASP では 256 未満のすべての ASCII 値をエスケープするように推奨しています。JavaScript™ のデータ値、HTML のスタイルのプロパティー値、そして HTML で使われる値の属性も同じくエスケープすることができます。当然のことながら、入力データをエスケープする前には、Web サイトへのあらゆる入力が検証済みであることを確実にする必要があります。入力に特定の値 (数字、文字、E メール・アドレスなど) を期待しているとしたら、該当するタイプのデータだけを許可し、その他のデータはすべて拒否するようにしてください。

まとめ

Web サイトが特に受けやすい、より一般的な攻撃を調べる上で重要な点は、これらの攻撃がどのように機能するかを理解することです。アタッカーが何を狙っているのかを知り、それに当てはまる脆弱性に対処することによって、あまり熟練していないアタッカーに対しては、サイトの侵害を不可能にすることができます。そして組織的なアタッカーに対しては、わざわざ挑戦する気にはなれないほど攻撃しにくくすることができます。この記事に挙げた対策と実行したスキャンは、これらの攻撃がどのように機能し、どのようにして防ぐかを表面的に説明しているにすぎませんが、これらの情報をセキュリティー対策の基盤として使用することができます。


ダウンロード可能なリソース


関連トピック

  • Prevent a cross-site scripting attack」(Anand Sharma 著、developerWorks、2004年2月): サイトに対する XSS 攻撃を防ぐ方法を説明しています。
  • セキュアなプログラマー: 入力を検証する」(David Wheeler 著、developerWorks、2003年10月): セキュアなプログラムにおける第一の防御方法の 1 つである入力検証について学んでください。
  • Web Application Security Statistics: WASC では、Web サイトの脆弱性に関するデータの収集、そして Web アプリケーションの脆弱性状況についての十分な理解に対する業界全体での取り組みを提言しています。
  • developerWorks Web architecture ゾーン: Web 2.0 開発のツールと情報が満載の Web development ゾーンにアクセスしてください。
  • WebScarab および WebGoat: この 2 つのテスト・サイトを OWASP からダウンロードしてください。
  • Paros Proxy: このツールをダウンロードして、ご自分のサイトをスキャンしてください。

コメント

コメントを登録するにはサインインあるいは登録してください。

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=Web development, Open source
ArticleID=446962
ArticleTitle=Web アプリケーションのセキュリティー: 脆弱性をテストする
publish-date=10202009