はてな小池啓仁(コイケヒロヒト)の動画など。はてなこの広告は、90日以上更新していないブログに表示しています。マスターWEB以下は、WEBプログラマー用のWEB脆弱性の基礎知識の一覧です。WEBプログラマーの人はこれを読めばWEB脆弱性の基礎をマスターしてWEBプログラムを書くことができるようになっているかもです。WEB脆弱性の簡易リファレンスとしても少し利用できるかもしれません。WEBアプリケーションを開発するには、開発要件書やプログラム仕様書通りに開発すれば良いというわけにはいきません。WEB脆弱性を狙う悪意のユーザにも対処しないといけないのです。今回、WEBアプリケーションを開発にあたってのWEB脆弱性を、以下の一覧にまとめてみました。このまとめがWEBアプリケーション開発の参考になれば幸いです。Traversal)CSRF(クロスサイト・リクエスト・フォージェリ)尚、本コンテンツを作成するにあたって、以下のリンク先を大変参考にさせて頂きました。下記のリンク先は、凄く勉強になりました。謹んで御礼申し上げます。参考リンクhttp://www.ipa.go.jp/security/vuln/documents/website_security.pdf追記:すでに、はてブで指摘されているように、本コンテンツは、参考リンク先で勉強したノートです。したがって、本コンテンツより、参考リンク先で勉強することを強くお薦めします。追記(5/23):以下の暗号化の基礎知識もあわせてご利用ください。インジェクションとは?インジェクション(injection)の意味は、内部に何かを注入することです。WEB脆弱性のインジェクションには、以下の3つがあります。SQLインジェクションOSコマンドインジェクションHTTPヘッダインジェクションつまり、SQL、OSコマンド、HTTPヘッダの各々に、Webページから悪意のコマンドをインジェクションされることなのです。SQLインジェクションたとえば、以下のソースで、$uidと$passhをWebページから入力(POST)される以下のSQLがあったとします。'$passh'";$uidに「taro'--」と入力されたら、以下のように展開されます。''";すると、SQLで「--」はコメントになりますので、パスワードがなくても以下のSQLが発行されてしまうのです。'taro'";これ、Delete文もインジェクションされるケースもあり、私は実際にテストで体験しております。DBがクリアされました!・対策1バインド機構を利用します。バインド機構とは、実際の値がまだ割り当てられていない記号文字(プレースホルダ)を使用して、あらかじめSQL文の雛形を用意し、後に実際の値(バインド値)を割り当ててSQL文を完成させるようにします。・対策2対策1のバインド機構が利用できない場合は、入力されるパラメータや、データベースに格納される情報や、SQL文を構成する全ての変数や演算結果に対し、エスケープ処理を行います。特別な意味を持つ記号文字は、利用しているデータベースエンジンによって異なるので、それぞれに応じて対策を行います。・対策3たとえば、データ検索のみのケースでは、削除や更新系のSQLが使えないようにDBの権限設定を行います。・対策4あとは、SQLのエラーメッセージをWeb画面に表示しないとか、hiddenパラメータにSQL文をそのまま指定しないとか、があります。OSコマンド・インジェクションたとえば、以下のソースで、$fromをWebページから入力(POST)される以下のopen文があったとします。「`touch[0x09]/tmp/foo`」と入力されたら、以下のように展開されます。`touch[0x09]/tmp/foo`);すると、touchコマンドが実行されてしまいます。・対策1OSコマンドを起動できる言語機能の利用を避けます。Perlでは、open関数でなくsysopen関数を使用すれば、OSコマンドを起動することができません。・対策2対策1が利用できない場合は、引数に埋め込む前にチェックをかけ、本来想定する動作のみが実行されるようします。HTTPヘッダ・インジェクションたとえば、以下のソースで、$numをWebページから入力(POST)される以下のHTTPのLocationがあったとします。「3%0D%0ASet-Cookie:SID=evil」と入力されたら、以下のようなクッキーが発行されてしまうのです。SID=evil・対策1ヘッダの出力を直接行わず、Webアプリケーションの実行環境や言語に用意されているヘッダ出力用APIを使用します。・対策2対策1が利用できない場合は、ヘッダの出力時に想定外の改行を許可しないようにします。これは、HTTPヘッダは改行によって区切られる構造となっているため、これを許すと、任意のヘッダフィールドや任意のボディを注入される原因となるからです。クロスサイト・スクリプティングとは普通CGIなどWebアプリケーションは、Webページから検索のキーワード入力や個人情報の登録入力などを処理して、Webページとして出力します。ここで、Webページへの出力処理に問題があると、そのWebページにスクリプトなどを埋め込まれてしまうことがあります。このようなスクリプトのインジェクション(注入)を、特にクロスサイト・スクリプティング攻撃と言います。対策としては、入力されたHTMLテキストを出力する際にエスケープ処理を行い、HTMLテキストを許可しない方法があります。しても、HTMLテキストが必要な場合は、構文解析を行い、「ホワイトリスト方式」で許可する要素のみを抽出します。共通の対策としては、HTTPレスポンスヘッダのContent-Typeフィールドに文字コード(charset)の指定を行います。・エスケープ処理エスケープ処理には、Webページの表示に影響する特別な記号文字(「<」、「>」、「&」、「"」、「'」など)を、HTMLエンティティ(「&lt;」、「&gt;」、「&amp;」、「&quot;」、「&#39;」など)に置換します。「https://」で始まるURLのみを許可するようにします。これは、「javascript:」の形式で始まるURLがあるからです。以下は、上記の置換をするPerlでのソースです(前に書いた記事の引用です)。$strhtml;}http://d.hatena.ne.jp/chaichanPaPa/20080329/1206748795・ホワイトリスト方式リストに登録された内容に一致する文字列の通過を「許可」する方式です。未知の攻撃パターンにも有効であり、漏れが生じにくい点で安全性は高いです。ちなみに、ブラックリスト方式は、ホワイトリスト方式の逆で、リストに登録された内容に一致する文字列の通過を「禁止」する方式です。これは、未知の攻撃パターンを検出できない可能性があり、漏れが生じやすいという性質あります。・HTTPレスポンスヘッダの文字コード指定HTTPレスポンスヘッダに文字コードを指定していないと、ブラウザは、文字コードを推測して画面表示を処理します。UTF-7に推測された場合、上記のような「エスケープ処理」を施してもエスケープをスルーしてしまうケースがあるとのことでした(参考リンク参照)。セッション・ハイジャックとはHTTPは、ステートレスなので、普通は、ステートを引き継ぐセッション管理ができません。ログインが必要なサイトでは、セッション管理がないと実現ができません。そのために、クッキーが考案され、クッキーにステート(セッションID)を保存することにより、セッション管理を実現します。セッション管理がクッキーにより実現できても、その不備を狙うWEB脆弱性があり、それをセッション・ハイジャック攻撃と言います。セッション・ハイジャック攻撃には、以下の3通りがあります。悪意のある人は、セッションIDの生成規則を割り出し、有効なセッションIDを推測します。これにより、善意の利用者に成りすましすることができるのです。対策:セッションIDは、生成アルゴリズムに安全な擬似乱数生成系を用いるなどして、予測困難なものにします。悪意のある人は、罠を仕掛けたり、ネットワークを盗聴したりし、利用者のセッションIDを盗みます。これにより、善意の利用者に成りすましすることができるのです。対策:セッションIDをURLパラメータに格納しないようにしたり、HTTPS通信で利用するCookieにはsecure属性を加えます。Fixation)悪意のある人は、以下のような『何らかの方法』で、自分が取得したセッションIDを善意の利用者のセッションIDに送り込みます。これにより、善意の利用者に成りすましすることができるのです。対策:ログイン成功後に、新しくセッションを開始するようにします。悪意の利用者が、BBS掲示板等へ「セッションIDを送り込む細工をされたURL」を貼り付けます。善意の利用者は、そのURLをクリックし、ログインします。悪意の利用者は、送り込んだセッションIDを使って善意の利用者のページを閲覧できるようになります。悪意のある人が、予め用意したセッションID(例ではクッキーのPHPSESSID=aaa)をdocument.cookieで善意の利用者のに送り込み、ログインページに遷移します。するとその後、悪意の利用者は、そのセッションIDでログインすることにより、善意の利用者に成りすましすることができるようになるのです。アクセス制御の欠落と対策アクセス制御の欠落とは、ログインが必要なサイトでは、ログイン情報によりアクセス制御を掛けますが、たとえば、そのログイン情報がメールアドレスだった場合は、他人にも知られ得る情報であり、そのような情報の入力だけでログインできてしまうのは、アクセス制御機能が欠落していると言えます。アクセス制御の対策は、他人にも知られ得る情報でなく、パスワードなどの入力を必要とするように、Webアプリケーションを設計する必要があります。認可制御の欠落とは、上記の「アクセス制御の欠落」をなくして、ログインを実装しても、ログイン者が他のログイン者の情報(データベース)にアクセスできてしまうことがあります。このような実装は、認可制御機能が欠落していると言えます。認可制御の対策は、ログイン者がアクセスできる情報(データベース)の範囲をつねに考慮するように、Webアプリケーションを設計する必要があります。ディレクトリ・トラバーサルとは?「../../」のような相対パスを使用し、システム内の任意ファイルへアクセスする攻撃手法をディレクトリ・トラバーサルと言います。システム内のディレクトリ間を自由に横断(トラバース)できることが攻撃名称の由来で、パス・トラバーサルとも呼ばれます。対策は、CGIでは、GET(引数)とPOST(hidden)で、ファイル名のみで、ファイルパスを指定しないように設計します。万が一、ファイル名にファイルパスを付加された場合を想定して、そのようなパスを削除するように設計します。charset=Shift_JIS;<html><body><h1>test</h1><p>$wk</p></body></html>HERE1尚、上記は、XSS対応にはなっていませんので、ご注意を!XSSに関しては、『クロスサイト・スクリプティング』を参照してください。『./』は自ディレクトリです。『../』は、親ディレクトリです。bbbディレクトリにtest.txtがあったとします。/aaa/bbb/ccc/ddd/../../test.txtは、同じになるのです。クロスサイト・リクエスト・フォージェリとは?普通、Webページの入力項目に対して入力をして、書き込みを押すと、その入力データがサーバーに送られます。このWebページで、入力をしないで、悪意のあるページにアクセスしたとします。すると、それだけで悪意のある入力データがサーバーへ送られる可能性があるのです。このような攻撃をCSRF(クロスサイト・リクエスト・フォージェリ)と言います。確認のページが、以下のようになっていたとします。value="実行"></form>このときに、実行を押さず、以下のような悪意のページにアクセスしたら...。太郎・大阪府でなく、いぱくん・東京都が書き込みされてしまうのです。これ、mixi(ミクシィ)のような会員制のサイトでは、自分のIDで悪意の第三者に書き込みがされてしまうのです。場合があるわけです!CSRF対策としては、使用者と開発者では以下があります。使用者としてのCSRF対策とにかく、会員制のサイトにログインしたら、ログアウトするまではサイト以外のページにアクセスしない。更新ページで、秘密情報挿入やRefererチェック等で、なりすましを厳しくチェックします。Tumblrカウンターはてなブログをはじめよう!chaichanPaPaさんは、はてなブログを使っています。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。