セキュリティについて(まとめ)

こんにちは、よしときです!今回はセキュリティについて書籍にて学習したのでそのまとめを行いたいと思います。 使った書籍はこちら それでは章ごとに見ていきたいと思います。    

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

この章では導入として脆弱性とは何かというところから説明をはじめて、脆弱性が生まれる理由、セキュリティバグとセキュリティ機能の違いが説明されています。   まず脆弱性とは「悪用できるバグ」のことであり、経済的損失、利用者が回復不可能なダメージを受ける、サイト利用者に嘘をつくことになる、ボットネットワーク構築に加担することがあり、それを防ぐ必要があります。また、法的要求を満たすためでもあります。 脆弱性が生まれる理由として
  1. バグによるもの
  2. チェック機能不足によるもの
が挙げられています。 セキュリティバグとセキュリティ機能の違いは一方はバグであり、もう一方は通信路を暗号化するように積極的に安全性を強化する物です。  

第二章 実習環境のセットアップ

この章では本の実習環境をセットアップをします。この本では脆弱性を体験できる環境をVMware上の仮想マシンを用いて行います。そのツールのセットアップ方法となります。 環境はLinux,Apache2.2,PHP,PostgreSQL,Sendmail等メールサーバーを使う物として書いており、今回は使用OSがMacなのでこちらは省略いたします。  

第三章 WEBセキュリティの基礎

この章はWEBアプリケーションセキュリティの基礎となるHTTPやクッキー、セッション管理などの知識、同一性元ポリシーという考え方について説明されています。 まずHTTPとクッキー、セッション管理について、
  • どのような順序で動いているかの説明
    • リクエストメッセージ、レスポンスメッセージ、ステータスライン、レスポンスヘッダの説明
  • POST,GET方式の使い分け
    • GETは参照のみに用いる、POSTは機密情報の送信に用いる
  • HTTP認証の流れ
    • Basic認証をつかってみる
  • クッキーとセッション管理について
    • クッキーとはサーバー側からブラウザに対して名前=変数の組を覚えておくように指示するもの
    • セッション管理はクッキーが保持できる値などに制限があるため、また、秘密情報保持の為につかわれるものです。さらにそこからクッキーについての説明があります。
次に同一生成元ポリシーについてとなります。同一生成元ポリシーとはネットワークアクセスの制限であり、サンドボックスで制限されます。サンドボックスとはこれらのように制限をかける仕組みのことです。 ここから実際に同一生成元ポリシーについてのJavaScriptを例に説明が続きます。 同一生成元である条件として
  1. URLのホストが一致している。
  2. スキームが一致している
  3. ポート番号が一致している
の三つが挙げられています。   この節でブラウザを介して受動的攻撃をうけるという手法とその制限について説明されたことになります。  

第四章 WEBアプリケーションの機能別に見る

この章がこの本の中心となる章で、WEBアプリケーションの機能毎に発生しやすい脆弱性パターンについて、原理から対策方法まで説明されています。 まず、WEBアプリケーションの機能と脆弱性の対応からはじまります。 脆弱性の発生箇所として例が挙げられていてそれらをまとめると
  • 脆弱性には処理に起因する物と出力に起因するものがある。
  • 入力に起因する脆弱性はない
  • 出力に起因する脆弱性には「インジェクション」という単語がつくものが多い
となります。そこで、「インジェクション系脆弱性」とはデータの中に引用府やデリミタなどのマークが混入させられ、その後の文字列の構造が変化させられてしまうものです。   次に入力処理についてで、入力された処理についての処理についての説明があります ソースをみて流れを説明しています。そこから入力値の検証の説明となります。 流れとして大まかに
  1. 入力値検証はアプリケーション仕様に基づいて行う
  2. 文字エンコーディングの検証
  3. 制御文字を含む文字種の検証
  4. 文字数の検証
となり、その実地の手順として
  1. 設計段階で各パラメータの文字種および最大文字数を仕様として決める
  2. 設計段階で入力値検証の実装方針をきめる
  3. 開発段階では仕様に従い入力値検証を実装する
となります。   つぎは表示処理に伴う問題としてXSS(クロスサイト・スクリプティング)の説明となります。 XSSとは外部からの入力などに応じて変化する箇所があり、その部分のHTML生成の実装に問題があると起こる脆弱性のことで、成りすまし被害や、個人情報を盗まれる恐れがあります。 XSSは表示方法の間違いが主な発生要因なので正しいHTMLを生成することがXSS解消の第一歩となります。XSS脆弱性は後からの対処が大変な労力がかかることも書かれています。   次にSQL呼び出しに伴う脆弱性です。前述したインジェクションのひとつSQLインジェクションについてかかれています。これは全てのページが影響をうけ、情報漏洩からデータ改ざんなど様々な影響に繋がってしまうので絶対回避すべき脆弱性です。こちらもソースで攻撃方法の説明があり、そこから原因と対策の説明があります。 原因は前述した「文字列リテラル」、数値項目にたいするSQLインジェクションが挙げられ、対策としてプレースホルダとしてSQL分を組み立てること、リテラルを正しく構成することなどが挙げられています。なかでも静的プレースホルダ(文がそのままデータベースエンジンに送られ、次にバインド値が送られる。エンジン側で値を当てはめた後に文が実行される)を推奨しています。   次は「重要な処理」の際に混入する脆弱性で、「重要な処理」とは取り消しが出来ないような重要な処理のことについて説明されています。 まずCSRF(クロスサイト・リクエストフォージェリ)についての説明で、これは、利用者の意図したリクエストであることを確認するべき所でその確認処理が抜けていると勝手に「重要な処理」を実行される可能性があり、それCSRF脆弱性と呼びます。 CSRF対策は設計段階から盛り込む必要があり、対策が進んでいない項目でもあります。 対策としてあげられるのは
  • CSRF対策の必要なページを区別する
  • 正規利用者の意図したリクエストを区別するよう実装する
となります。   次はセッション管理の不備についてで、セッションハイジャックについて書かれています。 セッションハイジャックとはセッションIDが第三者に知られると成り済ましてアクセスする可能性があり、それを悪用することです。 セッションハイジャックをされてしまう要因として
  • セッションIDの推測
  • セッションIDの盗み出し
  • セッションIDの強制
が挙げられ、それぞれ概要が書かれています。 それぞれ対策としてまとめると
  1. セッション管理機構を自作せずWEBアプリケーション開発ツールのものを使う
  2. クッキーにセッションIDを保存する
  3. 認証成功時にセッションIDを変更する
  4. 認証前にはセッション変数に秘密情報を保存しない
となります。これらは設計の段階から計画的に行うことで少ない箇所で対策することが出来ます。   次はリダイレクト処理にまつわる脆弱性とあり、リダイレクト処理時におこる脆弱性として
  • オープンリダイレクタ脆弱性
  • HTTPヘッダ・インジェクション脆弱性
が挙げられています。 オープンリダイレクタ脆弱性とはリダイレクトする機能(リダイレクタ)の中で任意のドメインにリダイレクトできるものをオープンリダイレクタと呼び、その際に知らないうちに別ドメインに遷移する場合にフィッシングという詐欺に悪用される可能性があることです。 対策として
  • リダイレクト先のURLを固定にする
  • リダイレクト先のURLを直接指定せず番号指定にする
  • リダイレクト先のドメインをチェックする
とあります。 次にHTTPヘッダ・インジェクション脆弱性とは、リダイレクトやクッキー発行など外部からのパラメータをもとにレスポンスヘッダを出力する際に発生する脆弱性で、改行などを挿入する攻撃によって
  • 任意のクッキーの生成
  • 任意のURLへのリダイレクト
  • 表示内容の改変
  • 任意のJavaScript実行によるXSSと同様の被害
という影響があります。 対策として
  • 外部からのパラメータをHTTPレスポンスヘッダとして出力しない
  • リダイレクトやクッキー生成を専用APIに任せる、ヘッダ生成するパラメータの改行文字をチェックする
のいずれかを実地することです。   つぎにクッキー出力にまつわる脆弱性で、クッキーの不適切な利用について説明されています。 脆弱性の例として「クッキーのセキュア属性不備」があげられています。これはクッキーのSecureという属性をつけないと盗聴される可能性があるというものです。 対策としてあげられるのは
  • セッションIDのクッキーにセキュア属性をつける
  • トークンを用いた対策
があげられています。   つぎはメール送信についての問題で、メールヘッダインジェクション脆弱性、hiddenパラメータによる宛先保持、メールサーバによる第三者中継という三つの問題について取り上げています。 メールヘッダインジェクション脆弱性は宛先や件名などヘッダフィールドに改行を挿入することによって改ざんする攻撃手法です。hiddenパラメータによる宛先保持は送信先アドレスを任意のアドレスに変更することによって悪用される可能性があることです。メールサーバーによる第三者中継はアプリケーション起因のものではなく、一つの脆弱性として説明だけされています。 さて、上記の対策をみていきます。 まずメールヘッダインジェクションでは
  • メール送信には専用のライブラリを使用する
その上で
  • 外部からのパラメータをメールヘッダに含ませないようにする
  • 外部からのパラメータには改行を含まないようにメール送信時チェックする
という対策をとります。   ファイルアクセスにまつわる問題についてを見ていきます。 ファイルを取り扱う際に以下の問題があります。
  • WEBサーバー内のファイルに対する不正アクセス(ディレクトリ・トラーサル)
  • OSコマンドの呼び出し(OSコマンドインジェクション)
ディレクトリ・トラーサルとは外部からパラメータの形でサーバー上のファイル名を指定できるアプリケーションで、ファイル名に対するチェックが不十分であると、意図しないファイルに対して改ざん、削除が出来るという脆弱性のことをいいます。 対策として
  • ファイル名を外部から指定することができる仕様を避ける
  • ファイル名にディレクトリ名が含まれないようにする
  • ファイル名を英数字に限定する
とあります。 次にOSコマンドインジェクションはアプリケーションよりシェル経由でOSコマンドを呼び出す際に、問題があることをいいます。 これら脆弱性があると、外部の攻撃者から様々な攻撃を受けることとなり、非常に危険であると言えます。 対策としては
  • OSコマンド呼び出しを使わない実装方法を選択する
  • シェル呼び出し機能のある関数の利用を避ける
  • 外部から入力された文字列をコマンドラインのパラメータに渡さない
  • OSコマンドに渡すパラメータを安全な関数によりエスケープする
とあります。これらは採用すべき順に並べていいます。 どの対策を採用すべきかは設計フェーズで方針を決定します。   ファイル不アップロードにまつわる問題として挙げられるのが
  • アップロード機能に対するDoS攻撃
  • サーバー上のファイルをスクリプトとして実行する攻撃
  • 仕掛けを含むファイルを利用者にダウンロードさせる工芸
  • ファイルの制限を超えたダウンロード
という攻撃です。 そのうちアップロードファイルによるサーバー側スクリプト実行という問題があります。 これは名前の通りで利用者がアップロードしたファイルをスクリプトとしてWEBサーバー上でじっこうされ影響が出ます。 対策としては、スクリプトとして実行可能な拡張しを利用者が指定できること、ファイルを公開ディレクトリに保存すること、これらどちらかをつぶすことになります。 次にファイルダウンロードによるXSSです。 これはダウンロードの際にファイル形式を誤認識することでJavaScriptを実行してしまうもので、自動でアップロードされてしまうなどの危険があります。 対策はアップロード時に
  • 拡張子が許可されたものかをチェックする
  • 画像の場合はマジックバイト(画像の中身)も確認する
ダウンロード時に
  • Content-Typeを正しく設定する
  • 画像の場合は、マジックバイトを確認する
  • 必要に応じてContent-Dispositionヘッダを設定する
という対策を撮る必要があります。   次にインクルードにまつわる問題とあり、アプリケーションが意図しないファイルを指定することにより脆弱となることがあります。対策として
  • インクルードするパス名に外部からのパラメータを含めない
  • インクルードするパス名に外部からのパラメータを含む場合は英数字に限定する
とあります。 これらは影響の大きな脆弱性の為、十分な対策を推奨されています。   最後に共有資源に関する問題として 競合状態の脆弱性についてかいてあります。 共有資源とは複数のプロセスから同時に利用している変数、共有メモリ、ファイル、データベースなどのことです。 競合状態の脆弱性の例として
  • 別人の個人情報などが画面に表示される
  • データベースの不整合
  • ファイルの内容破壊
です。 対策として挙げられているのが
  • 可能であれば共有資源を使用しない
  • 共有資源に対して排他制御を行う
   

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

この章では題名の通り代表的なセキュリティ機能として、認証、アカウント管理、認可、ログ出力について説明されいています。 まず認証についてです 認証とは利用者が確かに本人であることを確認することです。 その対策と注意点として以下が挙げられています
  • ログイン機能
  • 総当たり攻撃への対策
  • パスワードの保存方法
  • 自動ログイン
  • ログインフォーム
  • エラーメッセージ
  • ログアウト機能
次にアカウント管理について説明されており以下の機能について注意点を説明しています
  • ユーザ登録
  • パスワードの変更
  • メールアドレスの変更
  • パスワードリマインダ
  • アカウントの停止
  • アカウントの削除
認可、制御についての説明と成ります。 認可とは認証された利用者にのみ権限を与えることです。認可不備があると個人情報漏洩や権限の悪用などの問題に直結してしまいます。 そこで認可制御の正しい実装方法として
  • このスクリプト(画面)を実行してよいユーザか
  • リソースに対する操作の権限があるか
を確認することだと記されています。   ログ出力についてです。 ログ出力が重要である理由は
  1. 攻撃や事故の予兆をログから把握し、早期に対策するため
  2. 攻撃や事故の事後調査のため
  3. アプリケーション運用監査のため
の3点です。 ログの中でもアプリケーションログのエラーログ、アクセスログ、デバッグログについて説明されており、その使い方などが説明されています。有効なログを取得する為には4W1Hの項目を取得し、安全性を確保することが重要とされています。    

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

六章は文字コードとセキュリティとなっており、WEBアプリケーションの脆弱性の中には文字コードの扱い起因するものが多くあり、そのために文字コードの基礎から脆弱性が生まれる原因と対策の概要を説明されています。   まずは語句の説明としていくつか挙げられています。 文字集合とはその名の示すように文字をあつめたものです。それを各文字に符号をつけて識別したものが文字集合とよばれます。その例としてUnicodeやISO-8859-1などがあります。 文字エンコーディングとは文字集合についた符号の符号化のことです。例はShift-JISやUTF-8です。   文字コードによる脆弱性として
  • 文字エンコーディングとして不正なバイト列による脆弱性
  • 文字エンコーディングの扱いの不備による脆弱性
  • 文字集合の変更に起因する脆弱性
が挙げられています。以下は文字コードを正しく扱うためのポイントが4つ挙げられています。
  1. アプリケーション全体を通して文字集合を統一する
  2. 入力時に不正な文字エンコーディングをエラーにする
  3. 処理の中で文字エンコーディングを正しく扱う
  4. 出力時に文字エンコーディングを正しく指定する
これらを注意して脆弱性を対策することが大切だと説明されています。    

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

この章では携帯電話特有の脆弱性問題として、認証とセッション管理の問題を取り上げています。   まず、ゲートウェイの説明からです。 ゲートウェイは以下の役割をもつものです
  • 携帯電話網からインターネットへの橋渡し
  • 携帯IDの付与
  • クッキー保持
  • 絵文字への変換
などです。これらは携帯電話事業者によって変わることがあります。   携帯のブラウザの機能の特徴として
  • クッキーが使えない
  • JavaScriptが使えない(一部)
  • Refererなどリクエストヘッダの制限
  • HTTPレスポンスの容量制限
があります。これを前提にセキュリティについて見ていきます。 その中にクッキーが使えないことによりURL埋め込みのセッションIDによる問題があります。 この方法には成り済ましのリスクがあり、使わないようにするべきですが、携帯では使わざる得ないことがあります。そこで対策を説明しています。以下が対策になります。
  • クッキーが使える機種にはクッキーを使う
  • 外部ドメインに極力リンクしない
  • 外部リンクにはクッションページを挟む
  • ログイン後にセッションを開始する
  • 検索エンジン対策
そして、携帯電話は今後も環境が変化していくのでその都度対策を行うべきとあります。    

第八章 WEBサイトの安全性を高める為に

八章ではWEBアプリケーション意外の側面から、WEBサイトの安全性を高めるための施策の全体像を説明されています。   まずWEBサーバーへの攻撃経路と対策として、基盤ソフトウェア(OSやWEBサーバー)の脆弱性をついた攻撃があります。さらに不正ログインなどの攻撃も考えられます。それらの対策として以下が重要であるとせつめいがあります。
  • サービス提供に不要なソフトウェアは稼働させない
  • 脆弱性の対処をタイムリーに行う
  • 一般公開する必要のないポートやサービスはアクセス制限する
  • 認証強度を高める
つぎに成り済まし対策について考えていきます。 まず事例として まずDNSに対する攻撃、ARPスプーフィング、フィッシングが挙げられています。 そしてその対策として
  • ネットワーク的な対策
    • 同一セグメント内に脆弱なサーバーを置かない
    • DNS運用強化
  • SSL/TLSの導入
  • 確認しやすいドメインの採用
が挙げられています。   次に盗聴・改ざんの対策としては正規の証明書を導入してSSLを運用することに尽きる。とあり、その注意点として入力画面からHTTPにすることであると書かれています。   次はマルウェア対策です。マルウェアとはウィルスなど不正プログラムのことで、その感染経路の実態図があります。そこから対策を挙げており、その概要は
  • サーバーの脆弱性対処をタイムリーに行う
  • 出所不明なプログラムをサーバーに持ち込まない
  • サーバー上では運営に直接関係のない操作をしない
  • サーバーにUSBメモリなど外部メディアを装着しない
  • WEBサーバーのネットワークを執務スペースのLANと切り離す
  • サーバーに接続するクライアントPCにウィルス対策ソフトを導入してパターンファイルを最新に保つ
  • Windows UpdateなどによりクライアントPCに最新のセキュリティバッチを導入する
となります。    

第九章 安全なWEBアプリケーションの為の開発マネジメント

最後に安全なWEBアプリケーション開発のための開発プロセスについて説明されています。 流れとしてはまず、開発マネジメントにおけるセキュリティ施策の全体像をおさえ、次に開発体制についての書かれています。そして開発プロセスの留意点を挙げて、基本設計、詳細設計の時の留意点が挙げられています。 そしてその他としてウェブ健康診断仕様の紹介、受注者側テスト、発注者側テスト、運用フェーズの留意点について軽く触れられています。 これらは実用に関しての留意点が主で、その具体的な方法については書かれていません。   以上。長いものでしたが、PHPのソースコードは省いて、かつ重要な点のみをまとめてみました。

id-entity.jp

コメントを残す

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