備忘録 〜セキュリティ〜

こんばんは、うさです。 本日は、セキュリティについての書籍を読んでまとめていきます。 今回参考にさせて頂いた書籍はこちら。

第1章 Webアプリケーションの脆弱性とは

アプリケーションのバグにおいて悪用ができてしまうものを脆弱性(セキュリティバグ)と呼ぶ。 →この脆弱性があってはいけない理由
  1. 経済的損失
    • 利用者が受けた金銭的損失の補填、補償
    • 迷惑料として配る金券等の費用、配送料
    • Webサイト停止による機会損失
    • 信用失墜による売上の減少
  2. 法的な要求: Webサイトの安全対策を要求している法律として、「個人情報の保護に関する法律」があり、 5000件を越える個人情報を保持する事業者は個人情報取扱事業者として安全管理措置を講じる義務がある
  3. 利用者が回復不可能なダメージを受ける場合がある: 利用者の個人情報が漏洩した場合、元の状態に戻すことは不可能である。金銭的に解決は出来ても精神面の解決はできない。
  4. Webサイト利用者に嘘をつくことになる: 多くのWebサイトは安全性をうたっている。ここで脆弱性があると安全性に大きく影響をする。
  5. ポットネットワーク構築に荷担する: サイトを閲覧した利用者のPCがボットに感染し、それにより攻撃者の指令を受けて操作されてしまう可能性がある。 ボットネットワークに組み込まれたPCは迷惑メール送信やDDoS攻撃に荷担する。 また、ボットからサーバーに対して攻撃されることもある。
では、脆弱性が生まれる理由とは・・・
  1. バグによるもの→ セキュリティに無関係なところで発生し、アプリケーション全体に影響が及ぶ (例)SQLインジェクション、クロスサイト・スクリプティング等
  2. チェック機能の不足によるもの→ セキュリティ上のチェックが甘いことにより発生し、アプリケーション全体に影響が及ぶ (例)ディレクトリ・トラバーサル脆弱性等

第2章 自習環境のセットアップ

この章では仮想的にLinuxサーバーが動作する環境を作り、Webサーバーに見立てての実習のための環境設定を行っているので、割愛する。

第3章 Webセキュリティの基礎 〜HTTP、セッション管理、同一生成元ポリシー〜

3-1 HPPTとセッション管理

HTTPを学ぶ理由:Webアプリケーションの脆弱性には、Web固有の特性に由来するものがあるため ブラウザは、サーバーへ要求としてHTTPリクエスト(リクエストメッセージ)を送信し、サーバーはブラウザへの返信としてHTTPレスポンス(レスポンスメッセージ)を返す。 リクエストメッセージには「Referer」というヘッダが付く場合がある。 これが役立つ場合は、セキュリティ確保を目的として積極的にチェックする場合であり、 反対に問題になる場合は、URLが秘密情報を含んでいる場合。 <GETとPOSTの使い分け> リクエストメッセージの1行目はリクエストラインと呼ばれ、「GET」と「POST」が存在する。 使い分け方としては、
  • GETメソッドは参照(リソースの取得)のみ用いる
  • GETメソッドは副作用がないことが期待される
  • 秘密情報の送信にはPOSTメソッドを用いること
また、POSTで送信すべき理由としては、
  • URL上に指定されたパラメータがReferer経由で外部に漏洩する
  • URL上に指定されたパラメータがアクセスログに残る
上記をまとめると以下の中で1つでも当てはまる時はPOSTで、1つも当てはまらない時はGETを利用すべき
  • データ更新など副作用を伴うリクエストの場合
  • 秘密情報を送信する場合
  • 送信するデータの送料が多い場合
<hiddenパラメータ> 利用者の入力した値はhiddenパラメータとしてHTMLソース上に記述される そして、このhiddenパラメータは書き換え可能である。 メリットとしては、書き換え可能であると記述したが、情報漏洩や第三者からの書き換えに対しては堅牢である。 <クッキーとセッション管理>
  • セッション管理:アプリケーションにおいてログインした状態をサーバー側で覚えておくこと
  • クッキー:サーバー側からブラウザに対して「名前=変数」の組を覚えておくように指示するもの
クッキーはアプリケーションデータを保持する目的でクッキーに値を入れることはあまり行われない。 その理由は、
  • クッキーが保持できる値の個数や文字列長には制限がある
  • クッキーの値は利用者本人には参照・変更できるので、秘密保持の格納には向かない

3-2 受動的攻撃と同一生成元ポリシー

Webアプリケーションに対する攻撃は、能動的性攻撃と受動的攻撃に分類される。
  • 能動的攻撃:攻撃者がWebサーバーに対して直接攻撃すること。
  • 受動的攻撃:攻撃者がサーバーを直接攻撃するのではなく、Webサイトの利用者に罠を仕掛けることにより、罠を閲覧したユーザを通してアプリケーションを攻撃する手法。
『正規サイトを悪用する受動的攻撃』 以下の順で攻撃される
  1. 攻撃者が正規サイトを攻撃してコンテンツに仕掛けを仕込む
  2. 仕掛けられた正規サイトを利用者が閲覧する
  3. マルウェア感染などがおこる
この手法の攻撃者のメリットは、
  • 罠サイトに誘導する手間がいらない
  • 正規サイトは利用者が多いので被害が拡大する可能性が高い
  • 正規サイトの機能を不正利用することにより攻撃者にメリットが得られる
  • 利用者の個人情報を盗むことにより攻撃者にメリットが得られる
この手法は以下の4つがよく用いられる
  • FTPなどのパスワードを不正入手してコンテンツを書き換える
  • Webサーバーの脆弱性をついた攻撃によりコンテンツを書き換える
  • SQLインジェクション攻撃によりコンテンツを書き換える
  • SNSなどの利用者が投稿できるサイト機能をクロスサイト・スクリプティング脆弱性を悪用する
『サイトをまたがった受動的攻撃』 以下の順で攻撃される
  1. 利用者が罠サイトを閲覧する
  2. 罠サイトから、仕掛けを含むHTMLをダウンロードする
  3. HTMLの仕掛けが発動して正規サイトに攻撃のリクエストを送信する
  4. 正規サイトからJavaScriptなどの仕掛けを含むレスポンスが返る
では、ブラウザはどのように受動的攻撃を防ぐのか サンドボックス:プログラムができることに制限があり、悪意のあるプログラムを作ろうとしても利用者に被害が及ばないように配慮されている 一般的に、以下の機能が制限される
  • ローカルファイルへのアクセスの禁止
  • プリンタなどの資源の利用禁止
  • ネットワークアクセスの制限(同一生成元ポリシー)
上記に記載した「同一生成元ポリシー」とは、JavaScriptによるサイトをまたがったアクセスを禁止するセキュリティ上の制限である。 同一生成元である条件として、
  • URLのホストが一致している
  • スキーム(プロトコル)が一致している
  • ポート番号が一致している
ブラウザは同一生成元ポリシーにより受動的攻撃を防止しているが、アプリケーションに脆弱性があると受動的攻撃を受ける場合がある。

第4章 Webアプリケーションの機能別に見るセキュリティバグ

4-1 Webアプリケーションの機能と脆弱性の対応

まずは、以下にWebアプリケーションでよく用いられる処理と混入しやすい脆弱性を示す。
  • HTMLへの出力→クロスサイト・スクリプティング
  • HTTPヘッダの出力→HTTPヘッダ・インジェクション
  • SQLの呼び出し(発行)→SQLインジェクション
  • シェルコマンドの呼び出し→OSコマンド・インジェクション
  • メールヘッダ及び本文の出力→メールヘッダ・インジェクション

4-2 入力処理とセキュリティ

Webアプリケーションの入力では何をするのか →HTTPリクエストとして渡されるパラメータの値の受付時の処理(以後、入力処理とする) 入力処理では以下の処理を行う
  • 文字エンコーディングの妥当性検証
  • 文字エンコーディングの変換
  • パラメータ文字列の妥当性検証
文字エンコーディング関連の処理が終わった後、入力値の検証を行う。 入力値検証の目的は
  • 入力値の間違いを早期に発見して再入力を促すことにより、ユーザビリティ(使いやすさ)を向上する
  • 間違った処理を継続することによるデータの不整合などを防ぎ、システムの信頼性を向上させる
入力値検証の主目的はセキュリティのためではないが、以下のようなケースにおいてセキュリティの役に立つ。
  • SQLインジェクション対策が漏れていたパラメータがあるが、英数字のみ許可していたので実害には至らない
  • PHPのバイナリセーフでない関数を使っているが、入力段階で制御文字をチェックしているので実害には至らない
  • 表示処理の関数に文字エンコーディングの指定を怠っているが、入力段階で不正な文字エンコーディングをチェックしているので実害には至らない
上記に出てきたバイナリセーフとは・・入力値がどんなバイト列であっても正しく扱えること →値ゼロのバイト(ヌルバイト)が現れても正しく処理できる このヌルバイトを利用した攻撃もある その為、アプリケーションの入り口でバイナリセーフの関数を用いて入力値のヌルバイトをチェックし、ヌルバイトがあればエラーにすることにより対応が可能 しかし、入力値検証だけでは対策にならない。 なぜなら、「すべての文字を許容する」というアプリケーションの仕様の場合は入力時点では何も防げない。 その対策としては、
  • 制限文字のチェック
  • 文字数のチェック
を行う。

4-3 表示処理に伴う問題

表示処理が原因で発生するセキュリティ上の問題は以下がある。
  • クロスサイト・スクリプティング
  • エラーメッセージからの情報漏洩
<クロスサイト・スクリプティング> 『概要』 Webアプリケーションには外部からの入力などに応じて表示が変化する箇所があり、この部分のHTML生成の実装に問題があるとクロスサイト・スクリプティング(以下、XSSと省略する)が生じる その場合の影響としては以下が挙げられる。
  • サイト利用者のブラウザ上で、攻撃者の用意したスクリプトの実行によりクッキー値を盗まれ、利用者に成りすましの被害にあう
  • 同じくブラウザ上でスクリプトを実行させられ、サイト利用者の権限でWebアプリケーションの機能を悪用される
  • Webサイト上に偽の入力フォームが表示され、フィッシングにより利用者が個人情報を盗まれる
『攻撃手法』
  • クッキーの盗み出し
  • JavaScriptによる攻撃
  • 画面の書き換え
それぞれの攻撃について。 まずは、「クッキーの盗み出し」
  1. 攻撃者は脆弱なサイトの正規利用者を罠サイトに誘導する
  2. 正規利用者が罠サイトを閲覧すると、XSS攻撃により、クッキー値をクエリー文字列につけて、情報収集ページに遷移する。
  3. 情報収集ページは受け取ったクッキー値をメールで攻撃者に送信する。
続いては、「JavaScriptによる攻撃」 現在は、Ajaxの流行により、アプリケーションの様々な機能を呼び出すためのAPIが用意されているWebサイトが増加している。 APIは攻撃に悪用することも可能なので、XSSとJavaScriptの組み合わせによる攻撃がしやすくなっている。 最後に、「画面の書き換え」 攻撃者はリンクに見せかけたボタンを用意し、それをクリックすると、 もとのformを隠し、新たなformを追加することにより改変された画面へと誘導される。 そこに個人情報などを入力させて盗む。 『脆弱性の生まれる原因』 HTML生成の際に、HTMLの文法上特別な意味を持つ特殊記号を正しく使っていないことであり、それにより、HTMLやJavaSriptを注入・変形される現象がXSSである。 『基本的対策』
  • 要素内容については「<」と「&」をエスケープする
  • 属性値については、ダブルクォートで囲って、「<」と「”」と「&」をエスケープする
『保険的対策』
  • 入力値検証を行い、条件に一致しない入力の場合にはエラーを表示して再入力を促す
  • クッキーにHttpOnly属性を付与して、JavaScriptからのクッキーの読み出しを禁止する
  • TRACEメソッドの無効化にすることで、クロスサイト・トレーシングというJavaScriptによりHTTPのTRACEメソッドを送信することにより、クッキー値やBasic認証のパスワードを盗み出す攻撃に対処できる
<エラーメッセージからの情報漏洩> エラーメッセージからの情報漏洩については以下の2種類がある。
  • エラーメッセージに攻撃者にとって有益なアプリケーションの内部情報が含まれる
  • 意図的な攻撃として、エラーメッセージに秘密情報を表示させられる

4-4 SQL呼び出しに伴う脆弱性

<SQLインジェクション> 『概要』 SQLインジェクションはSQLの呼び出し方に不備がある場合に発生する脆弱性。 以下の影響を受ける場合がある。
  • データベース内のすべての情報が外部から盗まれる
  • データベースの内容が書き換えられる
  • 認証を回避される(ID、パスワードを用いずにログイン)
  • その他、データベースサーバ上のファイルを読み出し、書き込み、プログラムの実行などが行われる
『攻撃手法と影響』
  • エラーメッセージ経由の情報漏洩:あるURLを表示するとエラーメッセージが表示され、そこにユーザIDやパスワードが表示され、情報漏洩となる
  • UNION SELECTを用いた情報漏洩:UNION SELECTは2つのSQL文の結果の和集合を求める演算で、これにより、意図しない情報が表示されてしまう
  • SQLインジェクションによる認証回避:SQLインジェクション脆弱性があると、パスワードを知らなくてもログインできてしまう場合がある
  • SQLインジェクション攻撃によるデータ改ざん::iframe要素やscript要素を埋め込み、Webサイトの利用者のPCにマルウェアを感染させるように誘導する攻撃
『脆弱性が生まれる原因』
  • 文字列リテラルの問題:SQLの標準規格では、文字列リテラルはシングルクォートで囲む。 しかし、シングルクォートを重ねることを忘れてしまうと脆弱性が生まれる
  • 数字項目に対するSQLmインジェクション:数字リテラルはシングルクォートで囲まれないため、数値でない文字が現れた時点で数値リテラルは終了する。その後の文がSQL文として解釈されてしまう。
『対策』
  1. プレースホルダによりSQL文を組み立てる
  2. アプリケーション側でSQL文を組み立てる際に、リテラルを正しく構成するなど、SQL文が変更されないようにする
上記2つのうち2は対策が難しいため、1による対策が良い <プレースホルダによるSQL文組み立て> SQL文中のクエッションマークがプレースホルダであり、変数や式などの可変パラメータの場所に埋め込んでおくもの。 プレースホルダには「静的プレースホルダ」と「動的プレースホルダ」がある。
  • 静的プレースホルダ:値のバインドをデータベースエンジン側で行う。
    1. プレースホルダのついたSQL文はデータベースエンジンに送られ、コンパイルなどの実行準備が行われ、SQL文が確定
    2. バインド値がデータベースエンジンに送られ、エンジン側で値を当てはめたSQL文が実行
    →プレースホルダの状態でSQL文がコンパイルされるため、後からSQL文が変更される可能性は原理的にあり得ない。
  • 動的プレースホルダ:SQLを呼び出すアプリケーション側のライブラリ内で、パラメータ内をバインドしてからデータベースエンジンに送る方式。 バインドに当たりリテラルは適切に構成されるため、処理系にバグがなければSQLインジェクションは発生しない。
『保険的対策』
  • 詳細なエラーメッセージの抑止:先ほど記載した通り、エラーメッセージにより情報を得られてしまうため、詳細なエラーメッセージを抑止することで被害に遭いにくくする
  • 入力値の妥当性検証:4-2節のようにアプリケーション要件に従った入力値検証を行うと、脆弱性対策になる可能性がある
  • データベースの権限設定:アプリケーションを利用するデータベースユーザに対しては、アプリケーションを実現するために必要最低限な権限のみ与えることで被害を最小限に抑えられる

4-5 「重要な処理」の際に混入する脆弱性

「重要な処理」→ログインした利用者のアカウントにより、取り消しできない重要な処理が実行できるもの <クロスサイト・リクエストフォージェリ> 『概要』 「重要な処理」の受付に際し、利用者を意図したリクエストであることを確認する必要がある。 しかし、この確認処理が抜けていると、罠サイトを閲覧しただけで、利用者のブラウザから勝手に「重要な処理」を実行させられてしまう。 以下、クロスサイト・リクエストフォージェリ(以下CSRFと略す)の影響を示す。
  • 利用者のアカウントによる物品の購入
  • 利用者の退会処理
  • 利用者のアカウントによる掲示板への書き込み
  • 利用者のパスワードやメールアドレスの変更
『攻撃方法と影響』
  • 入力-実行パターンのCSRF攻撃:例としてパスワード変更画面を示す
    1. 利用者があるホームページにログインしている
    2. 攻撃者が罠を用意する
    3. 被害者が罠を閲覧する
    4. 罠のJavaScriptにより、被害者のブラウザ上で攻撃対象サイトに対し、新しいパスワードがPOSTメソッドにより送信される
    5. パスワードが変更される
  • 確認画面がある場合のCSRF攻撃:例としてメールアドレス変更時を示す
    1. hiddenパラメータでパラメータ受け渡ししている場合 このパターンは確認画面がない場合と同じで「入力-実行パターンのCSRF攻撃」と同じ攻撃を受ける
    2. セッション変数によりパラメータ受け渡ししている場合 このパターンでは、次の2段階の攻撃が必要になってくる
      1. 確認画面に対してメールアドレスをPOSTしてセッション変数にメールアドレスをセットする
      2. タイミングを見計らって実行画面を呼び出す
『脆弱性が生まれる原因』
  • form要素のaction属性にはどのドメインのURLでも指定できる →罠などのサイトからでも、攻撃対象サイトにリクエストを送信できるということ
  • クッキーに保管されたセッションIDは、対象サイトに自動的に送信される →罠経由のリクエストに対しても、セッションIDのクッキー値が送信されるので、認証された状態で攻撃リクエストが送信されるということ
『対策』
  • CSRF対策の必要なページを区別する
  • 正規利用者の意図したリクエストであることを確認する
  • 具体的な方法としては以下の3つがある
    1. 秘密情報(トークン)の埋め込み
    2. パスワードの再入力
    3. Refererのチェック
『CSRF攻撃への保険的対策』 重要な処理の実行後に、対象利用者の登録済みメールアドレスに対して、処理内容の通知メールを送信する →攻撃を受けた際に利用者が早期発見をし、被害を最小限にとどめることが出来る。

4−6 セッション管理の不備

第三者がセッションIDを知るための手段は次の3つ
  1. セッションIDの推測
  2. セッションIDの盗み出し 方法としては、
    • クッキー生成の際の属性の不備により漏洩する
    • ネットワーク的にセッションIDが盗聴される
    • クロスサイト・スクリプティングなどアプリケーションの脆弱性により漏洩
    • PHPやブラウザ等プラットフォームの脆弱性により漏洩
    • セッションIDをURLに保持している場合は、Refererヘッダから漏洩
  3. セッションIDの強制
推測可能なセッションID 攻撃は以下の順で行われる。
  1. 対象アプリケーションからセッションIDを集める
  2. セッションIDの規則性の仮説を立てる
  3. 推測したセッションIDを対象アプリケーションで試す
対策としては、 Webアプリケーション開発ツールが備えるセッション管理機構を利用する。 URL埋め込みのセッションID セッションIDをクッキーに保存せず、URLに埋め込ませる場合がある。 →Refererヘッダを経由して、セッションIDが外部に漏洩し、成りすまし原因になる場合がある。 漏洩する条件
  • URL埋め込みのセッションIDを使える
  • 外部サイトへのリンクがある。あるいはリンクを利用者が作成できる。
対策としては、 URL埋め込みのセッションIDを使わないためには、クッキーにセッションIDを保存するように設定する。 セッションIDの固定化 セッションIDの固定化攻撃は以下の順で行われる。
  1. セッションIDを入手する
  2. 被害者に対して、入手したセッションIDを強制する
  3. 被害者は標的アプリケーションにログインする
  4. 攻撃者は、被害者に強制したセッションIDを使って標的アプリケーションにアクセスする
対策として、
  • セッションIDをURL埋め込みにしない
  • クッキーモンスター問題のあるブラウザを使わない
  • クッキーモンスター問題の発生しやすい地域型ドメインを使わない
  • クロスサイト・スクリプティング脆弱性をなくす
  • HTTPヘッダ・インジェクション脆弱性をなくす
  • その他、クッキーを書き換えられる脆弱性をなくす
があります。 しかし、これらを満たすことは困難である。 このため、セッションIDが外部から強制されることは許容し、セッションIDの固定化攻撃が行われても、セッションハイジャックは防ぐようにすることが一般的。

4-7 リダイレクト処理にまつわる脆弱性

オープンリダイレクタ脆弱性 『概要』 リダイレクトの中で、任意のドメインにリダイレクトできるものをオープンリダイレクタ。 →フィッシングという詐欺に悪用される可能性がある 『脆弱性が生まれる原因』
  • リダイレクト先のURLを外部から指定できる
  • リダイレクト先のドメインのチェックがない
どちらか一方の条件に当てはまらないようにすれば脆弱性はなくなる。 『対策』
  • リダイレクト先のURLを固定する
  • リダイレクト先のURLを直接指定せず番号指定する
  • リダイレクト先のドメインをチェックする
HTTPヘッダ・インジェクション 『概要』 リダイレクトやクッキー発行など、外部からのパラメータを元にHTTPレスポンスヘッダを出力する際に発生する。 『脆弱性が生まれる原因』 リダイレクト先URLやクッキー値として設定されるパラメータ中に改行を挿入した場合に、改行がそのままレスポンスとして出力されることが原因 『対策』
  1. 外部からのパラメータをHTTPレスポンスヘッダとして出力しない: 以下の方針に従うべきである。
    • リダイレクト先をURLとして直接指定するのではなく、固定にするが番号などで指定する
    • Webアプリケーション開発ツールの提供するセッション変数を使ってURLを受け渡す
  2. 次の2つを実施する。
    • リダイレクトやクッキー生成を専用APIにまかせる
    • ヘッダ生成するパラメータの改行文字をチェックする

4-8 クッキー出力にまつわる脆弱性

一般的に、セッション管理機構ではセッションIDのみをクッキーに保存し、 データ自体は、Webサーバのメモリやファイル、データベースなどに保存する。 一方、クッキーに保存すべきでないデータをクッキーに保存することにより脆弱性が生まれる。 このデータとは、書き換えられると困る情報で、ユーザIDや権限情報などが挙げられる。 クッキーのセキュア属性不備 クッキーにはSecureという属性(以下、セキュア属性と記述)があり、これを指定したクッキーはHTTPSの場合のみブラウザからサーバに送信される。 『攻撃手法と影響』 セキュア属性のないクッキーを盗聴する方法は以下の手順である。
  1. Fiddlerを起動しておく
  2. 上記ページを閲覧して、ブラウザにクッキーをセットする
  3. 罠ページをアクセスする
  4. 罠ページからのリクエストにクッキーがついていることをFiddlerで確認する
『脆弱性が生まれる原因』 原因はセキュア属性をつけていないことであるが、 セキュア属性をつけない主な原因は以下が挙げられる。
  • 開発者がセキュア属性について知らない
  • セキュア属性をつけるとアプリケーションが動かなくなる →そのアプリケーションはショッピングサイトのようなHTTPとHTTPSが混在するWebアプリケーション
セキュア属性がついていないセッションIDが盗聴された場合でも、トークンにセキュア属性を付けることで確実に暗号化されていればHTTPSのページはセッションハイジャックされることはない。

4-9 メール送信の問題

メールヘッダ・インジェクション脆弱性 メールヘッダ・インジェクションは宛先や件名などのメールヘッダを外部から指定する際に、改行文字を使ってメールヘッダや本文を追加・変更する手法。 メールヘッダ・インジェクション脆弱性は以下の通り。
  • 件名や送信元、本文を改変される
  • 迷惑メールの送信に悪用される
  • ウイルスメールの送信に悪用される
脆弱性の生まれる原因以下の通り。 ヘッダの各フィールドは改行で区切られているので、外部から指定するパラメータに改行を挿入できれば、新たなヘッダを追加できる。 この改行をアプリケーションがチェックしていない場合には、ヘッダや本文を追加・変更できることになる。 →つまり、これが脆弱性の生まれる原因 『対策』 メール送信にsendmailコマンドではなく、専用のライブラリを使用すべき。 その上で、以下のいずれかを実施する。
  • 外部からのパラメータメールヘッダに含ませないようにする
  • 外部からのパラメータには改行を含ませないようにメール送信時にチェックする

4-10 ファイルアクセスにまつわる問題

ディレクトリ・トラバーサル脆弱性 外部からパラメータの形でサーバ上のファイルを指定できるWebアプリケーションでは、ファイル名に対するチェックが不十分であると、アプリケーションの意図しないファイルに対して閲覧や改ざん、削除が出来る場合がある。 この脆弱性をディレクトリ・トラバーサルという。 影響は以下の通り。
  • Webサーバ内のファイルの閲覧→重要情報の漏洩
  • Webサーバ内のファイルの改ざんの削除 →Webコンテンツ改ざんによるデマ、誹謗中傷の書き込み →マルウェアのサイトに誘導する仕組みの書き込み →スクリプトファイルや設定ファイル削除によるサーバ機能停止 →スクリプトファイル改ざんによる任意のサーバスクリプト実行
脆弱性が生まれる原因は、
  • ファイル名を外部から指定することができる
  • ファイル名として、絶対パスや相対パスで異なるディレクトリを指定できる
  • 組み立てたファイル名に対するアクセスの可否をチェックしていない
対策は、
  • 外部からファイル名を指定してできる仕様を避ける
  • ファイル名にディレクトリ名が含まれないようにする
  • ファイル名を英数字に限定する
意図しないファイル公開 外部から閲覧されると困るファイルをWebサーバの公開ディレクトリに配置している場合がある。 この場合、ファイルに対するURLがわかると、秘密ファイルの閲覧が可能になる。 意図しないファイルの公開により重要情報の漏洩が発生する。 脆弱性が生まれる原因は、
  • ファイルが公開ディレクトリに置かれている
  • ファイルに対するURLを知る手段がある
  • ファイルに対するアクセス制限がかかっていない
根本的な対策としては、非公開ファイルを公開ディレクトリに置かないことである。 そのためには、
  • アプリケーションの設計時に、ファイルの安全な格納場所を決める
  • レンタルサーバを契約する場合は非公開ディレクトリが利用できることを確認する

4-11 OSコマンド呼び出しの際に発生する脆弱性

OSコマンド・インジェクション Webアプリケーションの開発に用いる言語の多くはシェル経由でOSコマンドを呼び出す機能を提供しており、シェルを呼び出せる機能の使い方に問題があると、意図しないOSコマンドが実行可能になる場合がある。 これがOSコマンド・インジェクションである。 典型的には以下のような攻撃を受ける。
  1. 攻撃用ツールを外部からダウンロードする
  2. ダウンロードしたツールに実行権限を与える
  3. OSの脆弱性を内部から攻撃して管理者権限を得る
  4. Webサーバは攻撃者の思い通りのままになる
上記を行うと以下の悪用が可能になる。
  • Webサーバ内のファイルの閲覧・改ざん・削除
  • 外部へのメールの送信
  • 別のサーバへの攻撃
この脆弱性が生まれる原因は、
  • シェル経由でOSコマンドを呼び出す際に、シェルのメタ文字がエスケープされていない場合
  • シェル機能を呼び出せる関数を仕様している場合
対策としてはいずれかを行うべきである。(優先すべき順に並べる)
  1. OSコマンド呼び出しを使わない実装方法を選択する
  2. シェル呼び出し機能のある関数の利用を避ける
  3. 外部から入力された文字列をコマンドラインのパラメータに渡さない
  4. OSコマンドに渡すパラメータを安全な関数によりエスケープ
万一対策に漏れがあった場合の影響が大きいため、攻撃の被害を軽減する保険対策を実施すべきである。
  • パラメータの検証
  • アプリケーションの稼働する権限を最小限する
  • WebサーバのOSやミドルウェアのバッチ適用

4-12 ファイルアップロードにまつわる問題

アップロード機能に対するDoS攻撃 Webアプリケーションのアップロード機能に対して、巨大なファイルを連続して送信することにより、Webサイトに過大な負荷を掛けるDoS攻撃を仕掛けられる可能性がある。 影響として、
  • 応答速度の低下
  • 最悪の場合、サーバの停止
対策としては、アップロードファイルの容量制限が有効である。 アップロードファイルによるサーバ側スクリプト実行 影響として、
  • Webサーバ内のファイルの閲覧・改ざん・削除
  • 外部へのメールの送信
  • 別サーバへの攻撃
アップロードファイルによるサーバ側スクリプト実行を防止するには以下を実施する。
  • 利用者にアップロードされたファイルは公開ディレクトリに置かず、スクリプト経由で閲覧させる
  • ファイルの拡張子をスクリプト実行の可能性のないものに制限する
脆弱性が生まれる原因は、
  • アップロードしたファイルが公開ディレクトリに保存される
  • アップロード後のファイル名として、「.php」、「.asp」などスクリプトを示す拡張子が指定できる
対策としては、上記の原因を潰せば良いわけですが、 拡張子の制限だけでは対策抜けが生じる可能性があるため、 ファイルを公開ディレクトリに保存しない方法が望ましい。 ファイルダウンロードによるクロスサイト・スクリプティング 攻撃者がアプリケーションに罠を仕掛けて、アップロードしたファイルがHTMLとして認識されるような仕向ける。 利用者のブラウザがこのファイルをHTMLとして認識するとXSS攻撃が成立する。 脆弱性の生まれる原因は、Internet Explorer特有の仕様が影響する。 ファイルダウンロードによるXSS脆弱性対策はファイルのアップロード時とダウンロード時の対策それぞれを示す。
  1. ファイルアップロード時の対策 以下を実施する。
    • 拡張子が許可されたものかをチェックする
    • 画像の場合は、マジックバイトも確認する
  2. ファイルダウンロード時の対策 以下を実施する。
    • Content-Typeを正しく設定する
    • 画像を場合は、マジックバイトを確認する
    • 必要に応じてContent-Dispositionヘッダを設定する
  3. その他の対策
    • ファイルサイズ以外の縦横サイズ、色数などのチェック
    • 画像として読み込めるかどうかのチェック
    • ウイルス・スキャン
    • コンテンツの内容チェック →アダルトコンテンツ →著作権を侵害するコンテンツ →法令、公序良俗に反するコンテンツ

4-13 インクルードにまつわる問題

ファイルインクルード攻撃 includeなどに指定するファイル名を外部から指定できる場合、アプリケーションが意図しないファイルを指定することにより脆弱となる場合がある。 →ファイルインクルード脆弱性 影響は以下の通り。
  • Webサーバ内のファイルの閲覧による情報漏洩
  • 任意のスクリプトの実行による影響 →サイト改ざん →不正な機能実行 →他サイトへの攻撃
脆弱性が生まれる原因は、
  • インクルードファイル名を外部から指定することが出来る
  • インクルードすべきファイル名かどうかの妥当性をチェックしていない
である。 対策は以下のいずれかを実施する。
  • 外部からファイル名を指定することを避ける
  • ファイル名にディレクトリ名が含まれないようにする
  • ファイル名を英数字に限定する

4-14 evalにまつわる問題

evalインジェクション eval関数の利用法に問題がある場合、外部から送り込んだスクリプトを実行される場合がある。 →このような攻撃をevalインジェクション攻撃 この攻撃による影響は、
  • 情報漏洩
  • サイト改ざん
  • 不正な機能実行
  • 他サイトへの攻撃
がある。 脆弱性が生まれる原因は、
  • evalを用いることがそもそも危険である
  • evalに与えるパラメータのチェックがされていない
である。 対策としては、上記の原因からもわかる通り、
  • evalを使わない
  • evalの引数に外部からのパラメータを指定しない
  • evalの与える外部からのパラメータを英数字に制限する

4-15 共有資源に関数問題

競合状態の脆弱性 共有資源とは、複数のプロセスやスレッドから同時に利用している変数、共有メモリ、ファイル、データベースなどのこと。 共有資源に対する排他制御が不十分な場合、競合状態の脆弱性の原因となる場合がある。 代表例としては、
  • 別人の個人情報などが画面に表示される
  • データベースの不整合
  • ファイルの内容の破壊
が挙げられる。 脆弱性の生まれる原因は、
  • 変数nameは共有変数である
  • 共有変数nameの排他制御をしていない
対策は以下のうちいずれかの実施である。
  • 可能であれば共有資源を使用しない
  • 共有資源に対して排他制御を行う
まとめ だいぶだらだらと長く記述していきましたが、 それぞれの脆弱性の発生原因とそれへの対策をしっかりと抑えていく必要があると感じた。 現状、覚えられていない。とりあえず、このような脆弱性があるのだなという把握は必要。

第5章 代表的なセキュリティ機能

5−1 認証

認証:利用者が確かに本人であることをなんらかの手段で確認すること。 Webアプリケーションで用いられる認証手段は、「HTTP認証」、「HTMLフォームでのIDとパスワードを入力させるフォーム認証」、「SSLクライアント証明書を用いるクライアント認証」がある。 それでは、認証処理を要素分解していく。
  1. ログイン機能:認証処理の中心となるのが本人確認の機能=ユーザIDとパスワードをデータベースとの照合
    • ログイン機能に対する攻撃
      • SQLインジェクション攻撃による認証機能のバイパス・パスワードの入手
      • ログイン画面に対するパスワード試行
      • ソーシャルハッキングによるパスワード入手
      • フィッシングによるパスワード入手
    • ログイン機能が破られた場合の影響:Webアプリケーションが不正ログインされると、攻撃者は利用者の持つ権限を全て利用できるようになる。
    • 不正ログインを防ぐためには →SQLインジェクションなどのセキュリティバグをなくす →パスワードを予測困難なものにする
  2. 総当たり攻撃への対策:アカウントロックが有効である。 →暗証番号やパスワードを規定回数以上間違えるとアカウントをロックする
  3. パスワードの保存方法
    • パスワードの保護の必要性:パスワードの漏洩→他の秘密情報の漏洩→悪用により情報漏洩以外の被害
    • 暗号化によるパスワードと課題:暗号を使う場合の課題は以下の通り
      1. 安全な暗号のアルゴリズムの選定
      2. 鍵の生成
      3. 鍵の保管
      4. 暗号アルゴリズムが危殆化した場合の再暗号化
    • メッセージダイジェストによるパスワード保護と課題 メッセージダイジェスト・・・任意の長さのデータを固定長のデータ(メッセージダイジェスト)に圧縮する関数をハッシュ関数といい、セキュリティ上の要件を満たすハッシュ関数を暗号学的ハッシュ関数という。 それでは、メッセージダイジェストを用いてパスワードを保護する。 まず、ハッシュ関数の特性は、
      • ハッシュ値から元データを得ることが困難(一方向性)
      • 異なる入力から得られるハッシュ値が一致する確率が極めて低い(衝突耐性)
      であり、これによりパスワードが安全に保存できる。 しかし、ハッシュ値から元のパスワードを解析するための手法がしられている。 3種類取り上げる。
      1. オフライン総当たり攻撃:パスワードは短い文字列で文字種も限られていることから総当たり的にデータを探索できる
      2. レインボー・クラック:レインボーテーブルというものを用いて文字種と文字数の制限毎に作成される →文字数を多くすることで防ぐことができる
      3. ユーザDB内にパスワード辞書が作られる:攻撃者がダミーのユーザを多数登録して、ユーザDB上に「パスワード辞書」を作ってしまう
    • ハッシュ解読の対策として2つ示す。
      1. ソルト:ハッシュの元のデータに追加する文字列のこと。 →見かけのパスワードを長くするとともに、ソルトをユーザ毎に異なるものにすることで、パスワードが同じでも異なるハッシュ値が生成される
      2. ストレッチング:ハッシュの計算を繰り返し行うことによって計算時間をのばすことが出来る
  4. 自動ログイン
    • 自動ログインの安全な実装方式:
      • セッション寿命を延ばす
      • トークンを使う
      • チケットを使う
      • 3方式の比較を行うと、 この中ではトークン方式が一番好ましい。 メリットとして、
        • 自動ログインを選択しない利用者に影響を与えない
        • 複数端末からログインしている場合に一斉ログアウトできる
        • 管理者が、特定利用者のログイン状態をキャンセルできる
        • クライアント側に秘密情報がわたらないので解析されるリスクがない
    • 自動ログインのリスクを低減するには:重要な処理の前にはパスワード入力を要求する
  5. ログインフォーム:一般的なガイドラインは以下の通り
    • パスワード入力欄はマスク表示する
    • HTTPSを利用する場合は、ログインフォームからHTTPSにする
  6. エラーメッセージの要件:エラーメッセージは攻撃者のヒントとなる情報は含むべきでない
  7. ログアウト機能:ログアウト処理の要件は以下の通り
    • ログアウト処理は副作用があるのでPOSTメソッドでリクエストする
    • ログアウト処理ではセッションを破棄する
    • 必要な場合、CSRF対策の対象とする

5-2 アカウント管理

アカウント管理における6つの機能についてセキュリティ上の注意点を記述する
  1. ユーザ登録:ユーザ登録については4つのセキュリティ上の注意点がある。
    1. メールアドレスの受信確認:メールアドレスを登録・変更する際には、登録されたメールアドレスに送信されるメールを利用者自身が受信できることを確認すべき そのために→
      • メールにトークンつきURLを添付して、そのURLから処理を継続する
      • メールアドレスを入力した後、トークン入力画面に遷移する。 トークンは、指定したメールアドレスにメール送信される
    2. ユーザIDの重複防止:ユーザIDは一意でなければならない為、排他的制御に細心の注意を払う必要がある
    3. ユーザの自動登録への対処:インターネット経由で自由にユーザ登録できるWebサイトの場合、外部からの自動操作により大量にユーザを作成される場合がある。 →CAPTCHAという仕組みを用いて、わざと文字をゆがめた画像を表示させ、利用者に文字を入力させ人間であることを確認する方法がある。
    4. パスワードに関する注意
  2. パスワードの変更:パスワード変更機能に対するセキュリティ上の注意点は以下の4点
    1. 現在のパスワードを確認する:現在のパスワードを入力してもらい照合 →セッションハイジャックされた状態で第三者がパスワードを変更することを防止できる
    2. パスワード変更時にはメールでその旨を通知する:第三者が不正にパスワードを変更した場合でも早期発見に繋がる
    3. SQLインジェクション脆弱性:
    4. CSRF脆弱性
  3. メールアドレスの変更:メールアドレス変更に必要な機能対策は以下の3つ
    • 新規メールアドレスに対する受信確認
    • 再認証
    • メール通知
  4. パスワードリマインダ:パスワードを忘れた際に何らかのかたちでパスワードを知らせる仕組みを用意する場合がある。 これには、管理者向けパスワードリマインダと利用者向けパスワードリマインダがある。 利用者向けパスワードリマインダの方法は以下の4つ
    • 現在のパスワードをメールで通知する
    • パスワード変更画面のURLをメールで通知
    • 仮パスワードを発行してメールで通知
    • パスワード変更画面に直接遷移
    この中で推奨すべきは下の2つである。
  5. アカウントの停止:特定のアカウントに対してセキュリティ上の問題が生じた場合は当該のアカウントを一時的に停止する場合がある。
  6. アカウントの削除:アカウントの削除は通常取り消し出来ない処理なので、本人の意思確認とCSRF脆弱性対策を目的として、パスワードの確認を要求すべき

5-3 許可

許可とは、認証された利用者に対して権限を与えること。 権限の例を以下に示す。
  • 認証された利用者のみ許可された機能 →退会処理、送金、新規ユーザ作成等
  • 認証された利用者のみに許可された情報の閲覧 →非公開の利用者自身の個人情報、非公開の掲示板、Webメール等
  • 認証された利用者のみに許可された編集操作 →利用者本人の設定変更、Webメールからのメール送信等

5-4 ログ出力

ログ出力の目的
  • 攻撃や事故の予兆をログから把握し、早期に対処する
  • 攻撃や事故の事後調査
  • アプリケーションの運用監査
アプリケーションログは以下の3種類である。
  • エラーログ:エラーを記録するもの →攻撃の検出に役立つ場合がある
  • アクセスログ:Webアプリケーションの情報閲覧や機能の利用記録をしてのログ →正常・異常共にログを残し、個人情報漏洩事件・事故への対応に役立つ
  • デバッグログ:デバッグ用のログ →開発環境やテスト環境で取得するもので、本番環境では取得すべきでない

第6章 文字コードとセキュリティ

6-1 文字コードとセキュリティの概要

文字コードとは以下の2つの概念を合わせたものである。
  • 文字集合
  • 文字エンコーディング

6-2 文字集合

文字集合とは、その名の通り文字を集めたもの。 文字集合の扱いが原因でおこる脆弱性は、文字変換の際のエスケープ処理で脆弱性が生まれる。

6-3 文字エンコーディング

文字エンコーディングとは、文字集合をコンピュータ上で扱う為の符号化。 文字エンコーディングは以下のようなものがある。
  • Shift_JIS
  • ISO-2022-JP
  • UTF-16
  • UTF-8

6-4 文字コードによる脆弱性の発生要因まとめ

文字コードによる脆弱性については以下の3つのタイプに分類される。
  • 文字エンコーディングとしては不正なバイト列による脆弱性
  • 文字エンコーディングの扱いの不備による脆弱性
  • 文字集合の変更に起因する脆弱性

6-5 文字コードを正しく扱うために

文字コードを正しくあつかうためには、以下の4つのポイントがある。
  1. アプリケーション全体を通して文字集合体を統一する
  2. 入力時に不正な文字エンコーディングをエラーにする
  3. 処理の中で文字エンコーディングを正しく扱う
  4. 出力時に文字エンコーディングを正しく扱う

第7章 携帯電話向けWebアプリケーションの脆弱性対策

7-1 携帯電話向けWebアプリケーションの技術的特徴

携帯電話のブラウザでWebアクセスする際は、キャリアのゲートウェイからインターネットに説ゾオクされる形態となる。 ゲートウェイの役割は以下の通り。
  • 携帯電話網からインターネットへの橋渡し(プロキシ)
  • 携帯IDの付与
  • クッキー保持
  • 絵文字の変換
  • SSL処理
  • 言語変換
ブラウザの機能的特徴
  • クッキーが使えない端末の存在:セッション管理にクッキーを用いず、URLにセッションIDを埋め込む方式が定着
  • JavaScriptが使えない端末が大半
  • Refererなどのリクエストヘッダの制限
  • HTTPレスポンスの容量制限

7-2 携帯ブラウザの技術仕様

JavaScriptのサポートにより脆弱性が¥が存在する場合のリスくが高まるとともに、新たな脆弱性パターンが生まれる可能性もある。 クッキーの仕様を以下に示す
  • HTTPの状態でSet-Cookieされたクッキーは事業者のゲートウェイが保持する
  • HTTPSの状態でSet-Cookieされたクッキーは端末が保持する

7-3 かんたんログインの問題

かんたんログインとは、IDとパスワードの代わりに端末IDのみを用いた認証方法。 かんたんログインに対する攻撃手法を以下に示す。
  • 携帯電話をモデムとしてゲートウェイを経由する方法
  • リクエストヘッダを書き換える
  • DNSリバインディング攻撃(受動的攻撃)
上記に攻撃手法を示したが、安全なかんたんログインの実装方法はあるのか 以下が必須条件となる
  • 携帯電話事業者のゲートウェイからのアクセスのみを受け付ける
  • リモートIPアドレスを元に事業者判定する
  • 携帯IDとしてはiモードID、EZ番号、ユーザIDのみ用いる
  • HTTPSではかんたんログインを受け付けない
  • Hostヘッダのチェックまたは名前ベースのバーチャルホストの設定を行う
  • ソフトバンクの非公式JavaScript対応端末へのなんらかの対処を行う

7-4 URL埋め込みのセッションIDによる問題

Refererヘッダにより外部にセッションIDが漏洩するという問題がありますが、それ以外にも以下の問題がある。 ・セッションIDの固定化がおこりやすい 対策としては、
  • クッキーが使え得る場合はクッキーを使う
  • 外部ドメインに極力リンクしない
  • 外部リンクにはクッションページをはさむ
  • ログイン後にセッションを開始する
  • 検索エンジン対策:認証前はセッションに有効にしないこと。

第8章 Webサイトの安全性を高めるために

Webサーバへの攻撃経路と対策

Webサーバへの攻撃はソフトウェアの脆弱性をついた攻撃や、Webサーバの管理に用いるパスワード攻撃がある。 対策としては、
  • サービス提供に不要なソフトウェアは稼働させない:不要なソフトウェアについては削除か停止をすることが安上がりで安全
  • 脆弱性の対処をタイムリーに行う
  • 一般公開する必要のないポートやサービスはアクセス制御する
  • 認証強度を高める:管理者のソフトウェアの認証の強度を高める →以下を推奨
    • TelnetサーバとFTPサーバを削除あるいは停止し、SSH系サービスのみを稼働させる
    • SSHサーバの設定によりパスワード認証を停止し、公開鍵認証のみとする

8-2 成りすまし対策

成りすましの手口はネットワーク的な成りすましと、Webサイトのデザインだけを似せたフィッシングの手法がある。
  1. ネットワーク的な成りすまし
    • DNSに対する攻撃:
      • DNSサーバに対する攻撃によりDNSの設定内容を書き換える
      • DNSキャッシュボイズニング攻撃
      • 執行したドメインを第三者がく購入して悪用する
    • ARPスプーフィング:ARPの偽応答を返すことで、IPアドレスを偽装する手法
  2. フィッシング:正規サイトにそっくりな入力画面を用意してメールなどで利用者を誘導し、IDとパスワードや個人情報などを入力させて盗み取る手法
Webサイトの成りすまし対策として以下が有効である。
  • ネットワーク的な対策:
    • 同一セグメント内に脆弱なサーバは置かない
    • DNS運用の強化:DNSSECの導入
  • SSL/TLSの導入
  • 確認しやすいドメインの採用

8-3 盗聴・改ざん対策

盗聴・改ざんの経路を以下に示す。
  • 無線LANの盗聴・改ざん:無線LANを流れるパケットは適切に暗号化されていないと盗聴される可能性がある
  • ミラーポートの悪用
  • プロキシサーバの悪用:もともとあるプロキシサーバを操作できる場合や、通信路上にプロキシサーバを設置出来る場合、プロキシサーバを流れるHTTPメッセージを盗聴できる
  • 偽のDHCPサーバ:偽のDHCPサーバにより、DNSやデフォルトゲートウェイのIPアドレスを偽装できる場合がある
中間者攻撃:盗聴用の機器により通信を中継させるタイプのものがある。 通信の盗聴・改ざんの対策として、以下の注意点がある。 SSL利用時の注意点
  • 入力画面からHTTPSにする
  • クッキーのセキュア属性に注意
  • 画像やCSS、JavaScriptなどもHTTPSで指定
  • frame、iframeを使わない
  • ブラウザのデフォルト設定でエラー表示されないようにする
  • アドレスバー・ステータスバーを隠さない
  • コンテキストメニューを無効化しない

8-4 マルウェア対策

Webサイトのマルウェア対策とは、以下の2つの意味がある
  • Webサーバがマルウェアに感染しないこと→マルウェアがWebサーバ上で活動してる状態
  • Webサイトを通じてマルウェアを公開しないこと→Webコンテンツとしてマルウェアがダウンロード出来る状態
マルウェアの感染経路は、インターネット接続・外部媒体、持ち込みクライアント・電子メールが多い。 Webサーバのマルウェア対策は以下が重要
  • サーバの脆弱性をタイムリーに行う
  • 出所不明なプログラムをサーバに持ち込まない
  • サーバ上では運営に直接関係ない操作をしない
  • サーバにUSBメモリなどの外部メディアを装着しない
  • Webサーバのネットワークを執務スペースのLANと切り離す
  • サーバに接続するクライアントPCにウイルス対策ソフトを導入してパターンファイルを最新に保つ
  • クライアントPCに最新のセキュリティパッチを導入する

第9章 安全なWebアプリケーションのための開発マネジメント

安全なアプリケーションのための開発プロセスについて説明する
  • 企画段階の留意点 安全なアプリケーション開発に必要な予算の見積もり、確保することが重要
  • 発注時の留意点 RFPに記載するセキュリティ要件が重要になってくる →セキュリティバグに対する要求は漠然としてしまうと実効性に乏しくなってしまう。
  • 要件定義時の留意点 セキュリティバグ対策については受注者の開発基準をベースとすべきである。
  • 基本設計の進め方 実施すべき重要項目は以下の通り
    1. セキュリティ機能に対する具体化
    2. 方式設計として開発標準の詳細化、テスト方式の決定
    3. 画面設計時のセキュリティ機能の確認
  • 詳細設計・プログラミング時の留意点 基本設計に従って開発
  • セキュリティテストの重要性と方法 自力で診断する場合は「ウェブ健康診断仕様」という脆弱性診断を用いて判断する。
  • 受注者側テスト 以下の手法を行う
    • ソースコード検査
    • ツールによるブラックボックス検査
    • 手動によるブラックボックス検査
  • 発注者側テスト 予算に余裕がなければ先ほど出てきた「ウェブ健康診断仕様」を用いて行う。
  • 運用フェーズの留意点 このフェーズで重要なことは以下の2点
    • ログの監視
    • 脆弱性対処
以上で備忘録を終了する。

Usami Go

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です