はじめに
情報処理安全確保支援士の対策として自分用に執筆していま す。 した。試験を受けたので公開してみます。
この記事はセキュリティ・執筆学びたての初心者が執筆しています。間違いがあるかもしれませんので、ぜひ各項目にある参考文献も確認してください。また、誤りがあればコメントで教えていただけると幸いです。
目次
SQLインジェクション
OSコマンドインジェクション
ディレクトリトラバーサル
セッションの管理不備による攻撃
クロスサイトスクリプティング
クロスサイトリクエストフォージェリ
HTTPヘッダインジェクション
メールヘッダインジェクション
クリックジャッキング
バッファオーバーフロー
SQLインジェクション
概要
データベースに送信する文字列の中にSQL文を注入することによって不正にデータベースを操作する攻撃。
攻撃例
ログイン画面でユーザIDとパスワードを入力する欄で以下のように送信するとします。
ユーザID: admin
パスワード: 123456
すると、サーバ側では
SELECT * FROM ~ WHERE id = 'admin' AND pass = '123456';
というSQL文が組み立てられ、実行されます。
ではここで、SQLインジェクションを行ってみます。以下のように送信するとします。
ユーザID: admin
パスワード: ' OR '1' = '1
すると、サーバ側では
SELECT * FROM ~ WHERE id = 'admin' AND pass = '' OR '1' = '1';
というSQL文が組み立てられ、実行されます。
もうお分かりの通りですが、'1'='1'で常に真となりパスワードを入力していなくてもログインできてしまいます。これが不正にデータベースを操作するSQLインジェクションです。
発生しうる脅威
- 非公開情報の漏洩
- 個人情報など漏洩してはいけない情報
- 情報の改ざん
- ウェブページやパスワードなどの改ざん
- 不正ログイン
- 上に示したような利用者に許可されている操作を不正に行う
- OSコマンドの実行
- システムの乗っ取りや他への攻撃の踏み台としての悪用
対策
- バインド機構を用いる
- エスケープ処理行う
バインド機構ですが、プレースホルダとも呼ばれます。また、動的プレースホルダと静的プレースホルダの2種類があります。
- 動的プレースホルダ
- アプリケーション側のデータベース接続ライブラリ内で値をエスケープ処理してプレースホルダにはめ込む
- 静的プレースホルダ
- プレースホルダのままSQL文をコンパイルし、データベースエンジン側で値を割り当てる
ちなみに、コンパイルしてからバインドしているため静的プレースホルダのほうが安全である。
プリペアドステートメント
プリペアドステートメントとは、SQL文において動的に生成する際に変わる部分(idやpassの値など)を変数のようにし、あとから代入することでSQLインジェクションを防ぐ仕組み。
以下はJavaの例文です
String query = "SELECT * FROM USERS WHERE username LIKE ?";
PreparedStatement statement = connection.prepareStatement(query);
statement.setString(1, parameter);
ResultSet result = statement.executeQuery();
参考文献
OSコマンドインジェクション
概要
ウェブサーバに送信する文字列の中にOSコマンドを注入することによって不正にOSコマンドを実行する攻撃。
攻撃例
ユーザ登録画面でメールアドレスを入力する欄で以下のように送信するとします。
メールアドレス: xxxx@abc.ac.jp
すると、サーバ側では仮登録メールを送信するために
sendmail xxxx@abc.ac.jp
が実行されます。
ではここで、OSコマンドインジェクションを行ってみます。以下のように送信するとします。
パスワード: xxxx@abc.ac.jp;rm- -rf /*
すると、サーバ側では仮登録メールを送信するために
sendmail xxxx@abc.ac.jp;rm- -rf /*
が実行されます。ここで、メールアドレスの後ろに;がくっついているので後ろのrmコマンドも実行されます。これにより不正に実行されたrmコマンドにより全てのファイルが削除されてしまいます。
発生しうる脅威
- サーバ内ファイルの閲覧、改ざん、削除
- 重要情報の漏洩や、設定ファイルの改ざんなど
- 不正なシステム操作
- シャットダウンやユーザアカウントの追加など
- 不正なプログラムのダウンロード、実行
- ウイルス、ワーム、ボット等の感染、バックドアの設置など
- 他のシステムへの攻撃の踏み台
- サービス不能攻撃や迷惑メールの送信など
対策
- 入力データのチェック => エスケープ処理
- WAFで遮断
- シェルを起動できる言語機能の利用を避ける
参考文献
ディレクトリトラバーサル
概要
外部から与えられるパラメータにウェブサーバ内の任意のファイル名を与えられ、意図しない処理を行わせる攻撃。
攻撃例
例えば、とあるサイトのリンクが
https://www.example.com/test1.txt
だったとしましょう。さて、今はtest1.txtを見ていますが公開されていないtest2.txtを見てみましょう。
簡単です。リンクのファイル名の部分を変更して
https://www.example.com/test2.txt
これで、公開されていないファイルにアクセスできました。これがディレクトリトラバーサルです。
発生しうる脅威
- サーバ内ファイルの閲覧、改ざん、削除
- 重要情報の漏洩や改ざん、設定ファイルの改ざんなど
対策
- 外部からのファイル名の直接の指定を避ける
- 固定のディレクトリを指定し、かつファイル名にディレクトリ名が含まれないようにする
参考文献
セッションの管理不備による攻撃
概要
【セッションハイジャック】
セッションIDを割り出したりすることで、利用者になりすます攻撃
【セッション固定化攻撃】
攻撃者のセッションIDで利用者にログインさせることで利用者になりすます攻撃
攻撃例
【セッションハイジャック】
ウェブサイトが発行したセッションIDを盗聴することによりセッションIDを取得し、盗んだセッションIDを用いてなりすましてログインする。
【セッション固定化攻撃】
攻撃者が自分用のセッションIDを発行し、利用者にセッションID付きのログインページのURLが張られたメールを送信する。利用者が騙されてログインすることによって攻撃者側のセッションIDがログイン状態になる。
発生しうる脅威
- ログイン後のユーザのみが利用可能なサービスの悪用
- 利用者が意図しない購入処理など
- ログイン後のユーザのみが編集可能な情報の改ざん、新規登録
- パスワードや掲示板への書き込みなど
- ログイン後のユーザのみが閲覧可能な情報の閲覧
- 個人情報、メールなど
対策
- セッションIDを推測困難なものにする
- セッションIDをURLパラメータに格納しない
- CookieにSucure属性をつける
- ログイン成功後に新しくセッションを開始する
- ログイン成功後に既存のセッションIDとは別
参考文献
クロスサイトスクリプティング
概要
ウェブアプリケーションに悪用するスクリプトを埋め込んで、利用者のブラウザ上で不正なスクリプトを実行する攻撃
攻撃例
ユーザが検索画面で<script>alert('12345')</script>を入力すると、適切な対策を行わないとjavascriptのアラートが実行されます。
発生しうる脅威
- 本物サイト上に偽のページが表示される
- 偽情報の流布やフィッシング詐欺など
- Cookieの取得
- セッションIDの取得や、個人情報の漏洩
- Cookieをブラウザに保存させられる
- セッション固定化攻撃など
対策
- ウェブページに出力するすべての要素に対してサニタイジングを行う
- URLを出力するとき、「http://」や「https://」で始まるURLのみ許可
「javascrpt:」で始まるものは許可しない
参考文献
クロスサイトリクエストフォージェリ
概要
Webアプリケーションの脆弱性を悪用する攻撃の一種です。攻撃者は、利用者が信頼するWebサイトから、意図しないリクエストをWebアプリケーションに送信させることで、利用者の同意を得ずにデータの改ざんや不正な操作を実行させる攻撃。
攻撃例
例として、オンラインショップでの買い物を想定する
- 利用者はウェブサイトにログインする
- 攻撃者が意図しない注文のリクエストを含むリンクを利用者へ送信
- 利用者がその悪意あるリンクをクリック
- ウェブサイトに「商品を購入し、配送先を攻撃者の住所に変更する」リクエストを送信
発生しうる脅威
- ログイン後の利用者のみが利用可能なサービスの悪用
- 不正な送金、利用者が意図しない商品購入、利用者が意図しない退会処理など
- ログイン後の利用者のみが編集可能な情報の改ざん、新規登録
- 各種設定の不正な変更、掲示板への不適切な書き込みなど
対策
- 処理を実行するページをPOSTメソッドでアクセスするようにし、「hiddenパラメータ」に秘密情報（トークンなど毎回ランダムなもの）を挿入されるよう前のページを自動生成し、その値が正しい場合のみ処理を実行
- Refererをチェックする
- 処理を実行する前に再度パスワードを入力させる
参考文献
HTTPヘッダインジェクション
概要
ウェブサーバに対して送信するHTTPリクエストに、改行コードを含む不正な文字列を紛れ込ませ、HTTPレスポンスを改ざんする。
攻撃例
http://~~/xxxxのxxxx部分がユーザ入力データとして、
【パターン１】
http://~~/%0d%0aLocation:xxxxを送信すると、
Location:http://~~/
Location:xxxx
となり、後ろのヘッダが優先されるのでLocationがxxxxになる。
【パターン２】
http://~~/%0d%0a%0d%0a<script>~~~</script>~~を送信すると、
Location:http://xxxx/
<script>~~
となり、ボディを改ざんされる
（改行二回でヘッダが終了される）
（%0d%0aは改行コード）
発生しうる脅威
- クロスサイト・スクリプティング攻撃により発生しうる脅威
- パターン２によりXSSが実行されるため
- 任意のCookie発行
- set-Cookieヘッダを注入されると、任意のCookieが発行され、利用者のブラウザに保存される
- キャッシュサーバのキャッシュ汚染
- 複数のレスポンスに分割し、任意のレスポンスボディをリバーシプロキシなどにキャッシュさせ、キャッシュ汚染を引き起こし、ウェブページの改ざんを行う
対策
- 直接出力せず、ヘッダ出力用APIを使用
- ユーザ入力データに含まれる改行を削除
- ユーザ入力データに開業が含まれたエラーにする
参考文献
メールヘッダインジェクション
概要
メール送信時にメールヘッダに悪意ある文字列を含めて送信することで件名などのメールヘッダや本文などを改ざんする攻撃
攻撃例
メールアドレスと応募内容がある応募フォームにて
メールアドレス：xxxx@abc.ac.jp%0d%0aSubject:送信完了%0d%0a%0d%0aご応募ありがとうございます。続けるには以下のリンクを…%00
応募内容：
と入力することで、本来送られるはずのメールが削除され、攻撃者によって悪意あるリンクへ飛ばされる可能性があります。
発生しうる脅威
- メールの第三者中継
- 迷惑メールの送信に悪用される
対策
- メールヘッダを固定値にして、外部からの入力は全てメール本文に出力
- 固定値に出来ない場合、メール送信用APIを使用する
- HTMLで宛先を指定しない
参考文献
クリックジャッキング
概要
ウェブサイト上に隠蔽・偽装したリンクやボタンを設置し、利用者を視覚的にだましてクリックさせるなど意図しない操作を誘導させる攻撃。
攻撃例
ニュースサイトの「記事を読む」ボタンを。別のウェブサイトの「ダウンロード」ボタンに見せかける。
発生しうる脅威
- ログイン後の利用者のみが利用可能なサービスの悪用
- 情報発信、退会処理など
- ログイン後の利用者のみが編集可能な設定の変更
- 利用者情報の公開範囲の意図しない変更など
対策
- HTTPレスポンスヘッダに、X-Frame-Optionsヘッダフィールドを出力し、他ドメインのサイトからのframe要素やiframe要素による読み込みを制限する
- 処理を実行する前に再度パスワードを入力させる
参考文献
バッファオーバーフロー
概要
悪意あるリクエストにより、ウェブサーバ側で任意のコードを実行したり、アプリケーションの異常終了をさせる攻撃
攻撃例
【スタック攻撃】
関数を実行した際に確保されるメモリと関数のリターンに使われる戻りアドレスを格納するメモリを超えるデータを注入されることによって、意図しない動作を引き起こす。
【ヒープ攻撃】
ヒープ領域に確保されたメモリ領域に、その大きさ以上のデータを書き込むことで、意図しない動作を引き起こす。
発生しうる脅威
- プログラムの異常終了
- 意図しないサービスの停止
- 任意のコード実行
- ウイルス、ワーム、ボット等への感染、バックドアの設置、情報漏洩など
対策
- 直接メモリにアクセスできない言語で記述する
- 直接メモリにアクセスできる言語で記述する部分を最小限にする
- 脆弱性が修正されたバージョンのライブラリを使用する
直接メモリにアクセスできる言語：C言語, C++など
参考文献