「AppGoat」を利用したセキュリティ勉強のまとめです。
#XSS攻撃 (クロスサイトスクリプティング)
Webページに対し不正なスクリプト文を埋め込み、それを利用者の元で表示させて被害を与える攻撃。
###危険性
- Webページの改ざん
- 情報の窃取(フィッシング)
- セッション情報の改ざん
また、XSSには主に3つのタイプがある。
###1.反射型
不正なスクリプト文を含んだリクエストが、送信者の元で実行されるタイプ
####流れ
-
スクリプトをパラメータに含ませたURLをサービスを利用しているクライアントの元へ送る
-
URLにアクセスし、パラメータをサーバに送る
-
パラメータ内の不正なスクリプトを含んだHTMLを出力し、それを返されたクライアントの元で実行
例えばアンケートサイトなどで、nameタグに脆弱性があったとする。
その状態で、以下のURLにアクセスするとパラメータ内のスクリプトが実行されてしまう
http://example.com/enquete?name=<script>alert("不正スクリプト");</script>
###2.格納型
不正なスクリプト文をサーバ内に格納し、アクセスした利用者のブラウザで実行させるタイプ
####流れ
-
DBにデータを格納しているWebサイトで、不正なスクリプト文を入力、格納
-
利用者が正規のURLを使ってアクセスした場合でも、DB内に格納されたスクリプトがページに出力され、クライアントの元で実行
- 反射型と違い、修正を行うまでほぼ永続的に実行される
####3.DOMベースのXSS
javascriptを利用して動的にDOMを操作するページにおいて、エスケープ漏れ等の脆弱性を狙って不正なスクリプトを実行させる攻撃
-
反射型や格納型と違い、スクリプトの実行及びHTMLの生成は、サーバ側ではなくクライアント側で行うため、ログが残らず発見しにくいという特徴がある
-
動的に内容を変えるページの増加に伴い、脆弱性を突くこの攻撃手段も増えつつある
###原因
-
入力値やパラメータに対し、エスケープ処理を行っていないため。
- エスケープ処理：言語において特別な機能を持つ文字を、特に機能を持たない普通の文字列として扱うための処理
###対策方法
-
反射型
パラメータの値を表示する前にエスケープする -
格納型
入力された値をDBに格納する前にエスケープする -
DOMベースのXSS
javascriptで内容を書き換えるときは、毎回エスケープする
#SQLインジェクション
不正なSQL文を実行することで、データベースを不正に操作する攻撃
###危険性
- 本来取得すべきでないDBの情報が不正に取得される
- 不正取得された情報でサービスにログインされる
- DBの改ざん、データ削除
- OSコマンドが不正に実行される
###原因
- 入力値に対し、エスケープ処理を行っていないため。
###対策方法
静的プレースホルダによるSQL文の組み立てを行った上でクエリを実行する
(入力された情報を直接文字列結合しない)
####例
$fuga = ?_GET["fuga"]; //GETされた値
//「?」パラメータでSQLステートメントを用意
$stmt = $db->prepare("SELECT * FROM hoge WHERE fuga = ?;");
//配列の値を渡してからステートメントを実行
result = $stmt->execute(array($fuga));
また、DBを操作できるアカウントに権限を設け、普通のページからでは操作できないようにすることも対策の一つ。
#CSRF (クロスサイトリクエストフォージェリ)
何らかのオンラインサービスにログイン中の被害者に対し、偽のURLを踏ませることで不正なリクエストを送信させる手法。
###危険性
主に正規ログインしたユーザーのみが行える操作が意図しない形で行われてしまう
- サービスの不正利用
- 各種設定の変更
- 個人情報の取得
###原因
- ログイン状態(セッションを確立した状態)なら認証を行わずに、各種操作ができてしまうから。
###対策方法
- 予測不能なトークン(疑似乱数)を設定する
- 大きな操作をする際、PWなどによる認証を促す
#バッファオーバーフロー
確保しているメモリの容量(バッファ)に対し、それを上回る値を書き込むことでオーバーフローを引き起こし、システムの機能停止や誤作動を狙う攻撃手段。
###特徴
-
主に「C」や「C++」における脆弱性
- 割り当てられているメモリの許容値内に入力値が収まっているかチェックせず、そのままメモリに書き込みをしてしまうため
-
「Java」や「php」等の言語
- メモリを直接操作することは無いため、ライブラリ等の脆弱性が無い限りはこの攻撃を受ける可能性は低い
###危険性
- プログラムの異常終了
- メモリ上のデータの改ざん、破壊
- 外部からのシェルコマンドの実行
###原因
- 入力値をチェックせず、そのままメモリに書き込みをしているから。
###対策方法
- 入力値チェックを行い、不正な値を弾く
- 領域溢れが起きた時点でプログラムを強制終了させる
- シェルコードを送り込めないようにする
#ディレクトリ・トラバーサル
Webに公開しているサーバーの中にある、公開していないデータを不正に閲覧したり操作する攻撃。
###危険性
- 公開していないファイルの閲覧による情報漏えい
- サーバー上のデータの改ざん、破壊
###原因
- ファイルにアクセス制限を設けていない
- 「/」で階層を遡れる設計
###対策方法
- 特定のファイルに対し、外部からのアクセスを制限する
- ファイルを指定するパスに、ディレクトリの名称を含めないようにする
- 階層を意味する「/」を受け取らないようにする
#OSコマンド・インジェクション
Webアプリ上で入力されたユーザからのリクエストを、実行可能な文字列としてシェルに渡すことで、OSに任意のコマンドの実行命令を行わせる攻撃。
###危険性
- 不正にOSコマンドを実行されることで、ファイルの改ざんやシステム全体を操作される(OSコマンドで実行されることが全て可能)
###原因
- エスケープ処理をかけていない
- ファイル名の書き換えなどで、OSコマンドを利用していること
###対策方法
- 入力された値にエスケープ処理をかける
- 可能な限りOSのコマンドを利用せずに、言語やフレームワーク内の関数を利用する
#セッション管理の不備(セッションハイジャック)
ユーザを識別するための「セッションID」に以下のような不備があったとする。
- 推測されやすいID
- IDの漏洩
- IDの固定化
その場合、攻撃者が利用者のセッションを使用して被害者になりすます、といった被害が起こりゆる。
###危険性
- サービスの会員になりすまし、ログインが必要なサービスの不正利用が行われる
###対策方法
#####推測
-
せッションIDの生成規則を推測されにくいものにする
- (推奨)言語に含まれている関数を利用して生成
- 暗号論的疑似乱数生成器を利用して桁数の長いIDを生成する
######漏洩
- URLにGET形式でIDを埋め込まない (POSTやhiddenで受け渡しを行う)
- Cookieに記録する際はsecure属性を指定し、HTTPS通信のときのみデータの受け渡しを行う
#####固定化
- ワンタイムセッションIDの生成 (頻繁にセッションIDを変更する)
- XSS等の攻撃と組み合わせて使用されることがあるので、そちらの対策も同時に行う
#認証制御や認可制御の欠落 認証確認が不十分であることから、権限の無い人間に、本来操作できないはずのファイルの操作や閲覧が行われてしまうこと
###原因
- 各ファイルやディレクトリ、DBに適切な権限を付与していない
- ログイン時に、第三者が知りうる情報のみで認証が行われている場合
- 認証に失敗した際に、どこが間違っているか教えてしまう
- IDとPWで認証している場合、「PWだけが間違っている」と表示するとIDの存在が知られてしまう
- 攻撃者にヒントを与えてしまいかねない
###危険性
- 攻撃者が本来行うことのできない操作をすることで、非公開の情報が漏洩、改ざんされる
###対策
- 適切な権限を付与する
- ログイン及びセッション情報の照合
- 利用者本人しか知らない情報を認証に利用する
- 何が間違っているか具体的に教えない
-「 ID、もしくはパスワードが間違っている」等
#HTTPヘッダ・インジェクション
HTTPヘッダレスポンスの情報を書き換えることで、本来とは違う偽のページを生成する
###原因
PHP 5.3.10以前の改行コードの脆弱性
###危険性
- Cookieの不正発行による成りすまし
- 出力内容の改ざん、それによるフィッシング詐欺
- サーバのキャッシュ汚染
###対策
- レスポンスヘッダでは、外部からのパラメータを出力しないようにする
- 言語にある専用のAPIで、リダイレクトうやCookie出力を行う
- ヘッダに入力された改行を弾く
#クリックジャッキング
Webサイトのボタンや説明を偽装することで、被害者に正規のサイトを操作しているように思わせつつ、意図していない操作を行わせる手法
###原因
- HTTPレスポンスヘッダの欠陥
###対策
- HTTPレスポンスヘッダに「X-FRAME-OPTIONS」を付ける
#メールヘッダ・インジェクション
メールヘッダを改ざんするリクエストを送り、送信先や本文の改ざんを行う攻撃
###危険性
- 意図しないアドレスへのメール送信
- メールの改ざんにより、危険なサイトへアクセスしてしまう
- スパムメール、ウイルスの受信
###対策
- 本文チェックを行い、外部からのパラメータを含まないようにする
- 改行コードを受け付けないようにする
#その他
-
##エラーメッセージの脆弱性
-
存在しないページを参照した際に、エラーメッセージとしてファイルやDBの情報が出力される
- Webサイトが構築されている環境が攻撃者に知れ渡ってしまう
####対策
-
実行環境の設定を変えることで、エラー出力を無効化
-
リリース以降はデバッグ機能を無効化
-
##オープンリダイレクト
Webページがリダイレクトする際、リダイレクト先のページを書き換えることで被害者を偽のサイトにアクセスさせて、情報を窃取する手法
####危険性
- 送信先が偽のサイトだとしても、入力ページ自体は本物のページなため、被害者が気付かず情報を入力してしまう可能性が高い
####原因
- リダイレクト先のチェックを行っていない
####対策
- リダイレクト先のURLをチェックする
- クッションページを設けて、クライアントにも間違いないか確認させる