セキュリティ対策法
セキュリティについて学んだ。
早速まとめてみる。
〇Webアプリケーションに対する代表的な攻撃手法
▼バッファオーバーフロー
バッファに対して許容量を超えるデータを送りつけてシステムを機能停止にしたり、意図的にバッファをオーバーフローさせ、あふれでたデータを実行させてしまう攻撃。
※Webアプリではあまりない【対策】
・入力チェック （入力データ長チェックなど）
▼クロスサイトスクリプティング
ユーザー入力フォームから入力された値をそのまま利用し、ページを生成するアプリケーションあると、そのフォームに悪意あるSQL文やHTMLタグ、JavaScriptを埋め込まれクライアントのCookieの値などを暴露・盗難されたり、タグなどを挿入させてページ内容を改ざんされたりする。
また、認証を行っているようなサイトでは、セッションが乗っ取られる危険性がある。
（セッションハイジャック）【対策】
入力チェックとサニタイジング
【サニタイジングする特殊文字】
・ ＜ → <
・ ＞ → >
・ ” → "
・ ’ → '
・ & → &
【場合によってはサニタイジングが必要な文字】
・ (); スクリプトタグの中に入る可能性がある場合
・ + UTF-7エンコーディングを使用する場合
※出力文字列から削除するか、上記のように変換して出力
【動的に生成すると危険なタグ】
・通常のテキスト部分
・タグ属性値
・URL属性
・イベントハンドラ属性・ → 〜部分のスクリプトはコメントではない
・スタイル属性
・外部スタイルシートへのリンク
※上記部分へユーザ入力値を設定するような場合は要注意！
【php言語による対策例】
$safe_text = htmlspecialchars($danger_text);
▼パラメータ改ざん
アプリケーションがURLパラメータや、POST、Cookieに入れた値を書き換えて、サーバに送り返す攻撃。
これにより価格改ざん（データ改ざん）や、他人への成りすまし攻撃を受ける可能性がある。
【対策】
・パラメータチェック （有効値のみOKとする仕組み）
・セッション変数を利用する
・データベースでパラメータ値を管理する
・パラメータ値のハッシュ値を使う
▼バックドアとデバッグオプション
バックドアは開発者が不正に作り込んだ裏口。
デバックオプションは開発時のデバッグ用のコードがそのまま残ってしまっているもの。
【脆弱性が存在する可能性がある箇所】
完全に開発者に依存すりため推測は不可能。
使途不明のパラメータが存在する場合、この脆弱性が隠れている可能性がある。
【対策】
開発段階のソースコードレビューなどで見つけ出すしかない。
▼強制的ブラウズ
バックアップファイルや作業ディレクトリ、隠れたファイルなどを推測し、直接アクセスする攻撃。
認証後のページに直接アクセスして、未認証で認証必要サイトを見たりする。
【脆弱性が存在する可能性がある箇所】
認証があるアプリケーションであれば、認証後に使われるアプリケーションすべてに強制ブラウズの脆弱性が存在する可能性がある。
【対策】
・不要なファイル・ディレクトリを全て削除する
・重要なファイル（個人情報・パスワード）を公開ディレクトリに置かない
・画面遷移図で認証チェックが必要な画面を区別できる状態にして、その部分に共通のチェックコードを入れる
▼セッションハイジャック
攻撃者が他のクライアントのセッションIDを不正に取得することにより、そのクライアントにしか見れない情報が見られてしまう。
【セッションIDの不正取得の方法】
・推測する → セッションIDに連番などを使っていると容易に推測されてしまう。
・総当りで有効なセッションIDを見つけ出す。
・クロスサイトスクリプティングの脆弱性を利用して盗む。
【対策】
・推測されにくいセッションIDにする（桁数を多くする。ハッシュ関数などを使用する）
・プログラム言語で容易されているsession関数を利用する。
・クロスサイトスクリプティング対策を十分に行う。（これが原因の盗難が多数）
・SSL通信を用いてデータを暗号化し、さらに発行するCookieにsecureオプションを付与する。
・セッションの必要のないページに移動したら、セッションをこまめに破棄する。
・セッションが盗まれた場合の対策も必要。
→セッションタイムアウトの時間を短くする。（デフォルトは大抵20分くらい）
→認証で使用している場合は、重要な操作時にパスワードを再入力させる。
▼セッションフィクセイション
攻撃者が用意したセッションID(sid:1234)で、サーバにログインするようなリンクを持つwebページやHTMLメールをクライアントＡに送り、ログインするように仕向ける。
クライアントＡはセッションID(sid:1234)で、ID・パスワードとともにサーバーにログイン要求を送信。
サーバーにクライアントＡがログインし、セッション(sid:1234)が確立。
これで攻撃者はセッションID(sid:1234)でサーバーにアクセスできるようになり、クライアントＡに成りすましてコンテンツを盗み見ることが出来るようになる。
【対策】
・Webシステムがユーザ指定のセッションIDを受け入れないサーバソフトを利用する
・ユーザ認証前にセッションIDを発行する場合は要注意
・セッションIDはアプリケーションで生成してそれを使う
・認証後のページにもセッションIDだけでなく、セッション変数にユーザIDなどを格納して、毎回それを確認するよう徹底する
▼ディレクトリトラバーサル
指定されたディレクトリの外にあるファイルを読み込ませる攻撃
WebブラウザからのURL指定ではDocumentRootで指定されたディレクトリよりも上にあるファイルにはアクセス出来ないが、Webアプリケーションでは通常どのファイルにもアクセスできる。
これを利用してWebアプリケーションに「../../../etc/passwd」のようなパラメータを渡すことで不正にアクセスする攻撃である。
【脆弱性が存在する可能性がある箇所】
URLパラメータやユーザ入力値で指定されたファイルにアクセス・表示するアプリケーション
【対策】
・入力チェック
想定された文字またはファイル名以外は受け付けないようにする。
ファイルを表示するだけのアプリケーションなら英数字だけを受け付けるようにすれば問題ない。
▼SQLコマンドインジェクション
ユーザ入力値に基づいて、データベースサーバに対してクエリーを発行するようなWebシステムが攻撃対象。
入力値にSQL文が挿入され実行されることにより、ユーザ認証ロジックの回避、DB格納情報の漏洩、改ざん、破壊などされる。
【攻撃に使われる特殊文字】
・ ’ （文字列を囲う記号’’から出てしまう）
・ ； （複数のSQL文を区切るための記号｝
・ -- （この記号の先が勝手にコメントアウトされてしまう）
・ \ （特殊記号の意味を無くしたり、特殊記号を定義する記号）
【対策】
入力チェックの徹底
・文字種（数字・英字・限られた記号など）
・桁数
・フォーマット（文字列の構成形式がある程度決まっているもの ex.03-0000-0000）
サニタイジング
・エスケープすべき文字
’ → '' （2個にする）
； → 排除する
\ → \\（2個にする）
% → \% （LIKE句のワイルドカードは\を付ける）
_ → \_
・準備済みSQL文の利用（プレースホルダ、又はバインドメカニズム）
【PHP言語による対策例】
pg_escape_string($string)・・・（PostgreSQLの場合）
mysql_escape_string($string)・・・（MySQLの場合）
▼OSコマンドインジェクション
悪意のシェルコマンドをWebアプリケーション経由で実行されることを許してしまうことにより、機密データの漏洩、データの改ざん、データの破壊、サーバ乗っ取りが行われる。
【外部コマンドの実行関数】
- Perl
exec(), system(), command
- PHP
exec() システムコマンドを実行
system() システムコマンドを実行・表示
shell_exec() シェルコマンドを実行・結果を取得する
passthru() システムコマンドを実行し、そのまま出力
popen() 他プロセスへのパイプをオープンする
command システムコマンドの実行
- Java
java, lang, Runtime, exec()
- C言語
exec(), system()
【対策】
入力値チェックとサニタイジングを実施
→実行OKなコマンドしか受け付けないようにする。
【PHP言語による対策例】
$safe_text = escapeshelling($text);
system($safe_text)
▼クライアント側コメント
HTMLファイルの中にコメントとして残されている情報を見られること。
コメントの中に個人情報漏洩に繋がる重要な情報が含まれていることがある。
【対策】
開発段階のソースコードチェック。定期的な点検が必要。
▼エラーコード
不正な入力を行うことによりアプリケーションに誤作動をおこさせ、エラーメッセージを表示させる攻撃。
SQLエラーでは生成されたSQL文のどの部分が不正なのか具体的なエラーを出してくれる場合があるため、攻撃が成功される可能性が高くなる。
【脆弱性が存在する可能性がある箇所】
ユーザ入力を使って内部処理を行う箇所。アプリケーションがあった場合、
登録処理の部分で発生することが多い。
【対策】
入力チェック
サニタイジング
エラーハンドリング
エラーが発生した場合は作り込みのエラーページを表示させる必要がある
デフォルトのエラーページを表示させてはならない。
サーバ設定で不要な情報（サーバのバージョン情報など）を出さない
▼HTTPレスポンススプリッティング
不正な入力により、サーバからのHTTPレスポンスを２つに分割させ悪意あるレスポンスを受けさせることにより、サイトの成りすましを行ったり、被害者のWebブラウザのキャッシュを汚染させたり（コンテンツ・スプーフィング）、クロスサイトスクリプティングを仕掛けたり、と多様な攻撃が可能になる。
【脆弱性が存在する可能性がある箇所】
ヘッダー情報などを元に、たとえば言語に基づいて異なるページにリダイレクトさせるようなつくりのWebサイトで悪用される恐れがある。
【対策】
HTTPヘッダとして出力する箇所に「%0d%0a」つまり改行文字（CR/LF）を入れないようにする。
ユーザ入力文字列をHTTPヘッダとして利用する際に無害化（文字列から削除する）
ホワイトリスト方式を用いて、許可された文字以外は全て削除すればなお良い。
▼入力チェック三原則
１、サーバー側でチェックする
２、すべてのパラメータをチェックする
３、セッションは毎回チェックする
