発注したWebアプリケーションの開発が終わって、納品されたときにやっておくべきセキュリティチェックの為のリストです。個人情報の漏洩やサービスの一時停止、Webアプリケーションの不正使用をされないためにも是非ともこのチェックを行ってください。

なおこの情報はあくまで受け入れテストやQAテストの際に使用するための物です。絶対に自分が管理していないアプリケーションに対して使用しないでください。使用した場合は不正アクセスとなり、犯罪です。決して悪用しないでください。

１．テスト用ツール

• Burp proxy
• Achiless
• LiveHTTPHeaders
• HTML Source Code Explorer Bar
• Web Sleuth
• WebScarab
  
• SpikeProxy
• nc (or netcat)
• telnet

２．セキュリティチェック項目

• 収集データファイルのアクセス制御
  収集したデータファイルがWebサーバーを使用してブラウザから取得できないか確認します。収集した顧客情報などがブラウザを利用して第３者に漏洩することがあります。

  テスト方法:
  

  格納されるデータファイルのファイル名がhoge.csvで、WebアプリケーションのURLがhttp://www.test.com/cgi-bin/hoe.cgiとなっている場合、例えば以下のURLにアクセスしてみます。
  例）
  

  http://www.test.com/cgi-bin/hoge.csv
  http://www.test.com/cgi-bin/data/hoge.csv
  http://www.test.com/cgi-bin/csv/hoge.csv
  http://www.test.com/hoge.csv
  http://www.test.com/data/hoge.csv
  http://www.test.com/csv/hoge.csv
  
  

  場合によっては開発元からデータ格納先のURLを指定されているかもしれません。その際、IDとパスワードなどによるアクセス制御が出来ているかを確認します。
  
  確認事項)
  
  格納先URLにアクセスするとユーザーID、パスワードを求めてこない
  格納先URLに管理を行うIPアドレス以外から（別のISP経由で）アクセスできる
  
  上記事項が当てはまるなら、開発元に修正を依頼します。
  

• クロスサイトスクリプト
  詳しくはこちらを参照してください。

  テスト文字列：
  

  "><s>hoge</s>
  '><s>hoge</s>
  ><s>hoge</s>
  "><s>hoge</s>
  %22%3E%3Cs%3Ehoge%3C%2Fs%3E
  %27%3E%3Cs%3Ehoge%3C%2Fs%3E
  "><%1b%28%42s>hoge<%1b%28%42/s>
  '><%1b%28%42s>hoge<%1b%28%42/s>
  

  結果：
  

  「hoge」に打ち消し線（hoge）が表示されたらクロスサイトスクリプトの問題が存在する可能性が高いです。開発元に修正を依頼しましょう。
  
• ＳＱＬインジェクション
  詳しくはこちらを参照してください。

  テスト文字列１：
  

  ';
  ";
  hoge
  

  結果１：
  

  「ODBCエラー」や、「JDBCエラー」、「ORA-ほげほげ」、「データベースエラー」等、データベースのエラーが表示されたら、データベースを不正に操作される可能性があります。開発元に修正を依頼しましょう。
  

  テスト文字列２：
  

  数値 12345 に対して、

  12344%2B1 （＝12344+1)
  12346-1
  

  文字列 abcde に対して

  abcd'%2B'e （＝abcd'+'e)
  abcd'%2C%2C'e
  

  結果２：
  

  操作する前と同じコンテンツが表示されたら、データベースを不正に操作される可能性があります。開発元に修正を依頼しましょう。
  
• コマンドインジェクション
  詳しくはこちらを参照してください。

  テスト文字列：
  

  |hoge
  %7Choge
  "|hoge
  %22%7Choge
  '|hoge
  %27%7Choge
  &hoge
  %26hoge
  "&hoge
  %22%26hoge
  '&hoge
  %27%26hoge
  

  結果：
  

  500 Internal server errorと表示されたら、Webサーバーでコマンド実行ができる可能性があります。開発元にコマンド実行ができないか確認しましょう。
  
• ディレクトリトラバーサル
  詳しくはこちらを参照してください。

  テスト文字列１：
  

  ../hoge
  ..\\hoge
  ..\hoge
  

  結果１：
  

  500 Internal server errorと表示されたら、Webサーバー上のファイルを閲覧できる可能性があります。開発元にファイルの閲覧ができないか確認しましょう。
  

  テスト文字列２：
  

  ファイルhogeに対して ./hoge
  .\hoge
  .\\hoge
  

  結果２：
  

  操作する前と同じコンテンツが表示されたら、Webサーバー上のファイルを閲覧できる可能性があります。開発元にファイルの閲覧ができないか確認しましょう。
  
• バッファオーバーフロー
  詳しくはこちらを参照してください。ただしこの問題は最近ではほとんどないと思います。

  テスト文字列：
  

  aaaa・・・(いっぱい入れてみる)
  

  結果：
  

  500 Internal server errorと表示されたら、アプリケーションでバッ　ファオーバーフローが発生する可能性があります。開発元に、ポインタ、配列の境界チェックをきっちりしているかソースコードを確認してもらいましょう。
  
• セッション管理不備
  詳しくはこちらを参照してください。
  セッション管理を行っている場合、数回同じユーザーでログオン後のセッ ション管理データをチェックしましょう。セッション管理データが同じ場 合、ユーザーなりすましによる被害を受けやすくなります。また、同様に 異なるユーザーや同じユーザーで連続してログオンしてセッション管理デ ータをチェックしましょう。セッション管理データが連番、時刻など推測 出来そうな場合、セッション管理データを推測されて他のユーザーになり すまされます。
  これらに該当した場合、すぐにセッション管理機能を開発元に修正しても らいましょう。
  

  テスト方法：
  

  セッション管理データを確認するには以下の方法を使います。

  1. hiddenフィールドにセッション管理データが格納されている場合、ペ ージのソースをブラウザで表示します。
  2. クッキーにセッション管理データが格納されている場合、ログオン後 ブラウザのURLを入力部分に、JAVAScriptを有効にした後、以下の文字を入力します。
     
     javascript:alert(document.cookie);
     このコマンドを実行するとクッキーの内容がポップアップで表示されます。
  3. この中から、セッション管理データらしい文字列を探します。たいていの場合、「SID」、「Session」、「ID」といった文字が使われているはずです。これらの値が推測可能かどうかでセッション管理が貧弱かどうかを判断します。

これらのテストは最悪の場合、暴走してサービスが停止する可能性があります。あくまでこのテストは受け入れテストかQAテストでのみ使用してください。

なお、このチェックはあくまで簡易的な物です。これにパスしたからといって安全とは限りません。その点を注意して運用を行ってください。

このようなテストを自動化できるツールを作成しました。詳しくはこちら

最後にいろいろアイデアをいただきましたopenmyaMLのみなさまに感謝いたします。

Secure Coding に入ろう！
	メールアドレス