あなたのWebアプリケーションは安全ですか？ 〜 インジェクション編 〜

セキュリティ

この記事は最終更新日から1年以上が経過しています。

インジェクション

  • HTTPリクエスト送ると、Webアプリケーションは、さまざまなシステムに出力処理を行う場合があります
    • データベースにデータを書く
    • シェルを実行する
    • メールを送る
    • ブラウザに返信する
  • 上記に共通することは、何らかの文字列を処理しているところ
    • DBへの処理だと、SQL
    • HTTPメッセージ処理だと、HTML

これらに不備があると脆弱性が発生します
これらの脆弱性がインジェクンションに分類されます

代表的な攻撃を以下にまとめます

SQLインジェクション

  • DBを利用しているWebアプリケーションで、SQLの呼び出しに不備がある場合に発生する脆弱性

  • 検索画面があって、検索フォームに「ドラえもん」と入力する

  • すると以下のようなURLをリクエストする
http://example.com/search?q=ドラえもん

  • 上記リクエストからSQLを生成する処理が走る
SELECT * FROM animeTbl WHERE title='ドラえもん' and delete_flag = 0;

  • もしインジェクションが発生するWebアプリだと「ドラえもん’ –」ように入力すると見られちゃまずいデータが見られることになります
http://example.com/search?q=ドラえもん' --

  • なぜなら以下のようにSQLが解釈されてしまうから
SELECT * FROM animeTbl WHERE title='ドラえもん' --' and delete_flag = 0;

  • 上記のSQLだと、delete_flagというものが無効になるので、delete_flagに関係なくデータが見えてしまう
  • これを応用すると、さまざまなデータが見れてしまうことになります！

コマンドインジェクション

  • OSのシェルで動作するコマンドを不正に実行できてしまう脆弱性

  • SQLインジェクションと同様です

  • OSコマンドを実行するようなWebアプリケーションがあった場合、URL等に不正な文字列を入れられてしまうと、叩かれては行けないコマンドが叩かれてしまいます。

  • 正常なURLの形 これで、ドメインの管理者を表示するようなWebアプリがあったとします
http://example.com/whois?domein=hoge.jp

  • 上記の処理の内容は以下になります
<?php
$domain = $_GET['domain'];
system("/usr/bin/whois $domain");

  • 上記の処理だと、以下のURLで悪用できてしまう
http://example.com/whois?domein=;cat /etc/hosts

  • 見られていはまずいサーバー情報が見られてしまう。。

CRLFインジェクション

  • HTTPレスポンスヘッダーや、メールヘッダーに改行コード(CR+LF)を挿入することで、意図しないヘッダーフィールドを追加することができる脆弱性
  • 以下に詳細

HTTPヘッダーインジェクション

レスポンスフィールドに攻撃者が改行コードなどを挿入することで、任意のレスポンスヘッダーフィールドや、ボディを追加することができる脆弱性

  • 考えられる影響
    • 任意のURLにリダイレクトされることで、悪意のあるWebサイトに誘導される
    • 任意のCookieが生成されることで、セッションフィクセイション攻撃に利用される
    • 任意のHTTPボディが生成されることで、Webページに表示され内容が改変される
  • セッションフィクセーション攻撃
    • 攻撃者が指定したセッションIDをユーザーに強制的に使わせることができる脆弱性(また別な回で書きます)
  • リダイレクトをさせるようなWebアプリがあった場合
http://www.example.com?cat=100 => http://pc.example.com/?cat=100

  • もしインジェクションが発生するWebアプリだと以下のURLを打ち込むと、悪意のあるサイトへリダイレクトさせる等の悪用ができる
http://example.com?cat=%0D%0ALocation:%20http://waru.jp/

  • 脆弱性があるとレスポンスヘッダが改竄されてしまう
Location: http://pc.example.com/?cat=【ここに改行が入る】
Location: http://waru.jp/

  • 下のLocationが優先されてしまう

HTTPレスポンス分割攻撃

複数のHTTPレスポンスを作り出すことで、キャッシュサーバーや、プロキシ・サーバーに偽のコンテンツをキャッシュさせ、他のユーザーにも影響をあたえるという脆弱性

  • 考えられる影響
    • キャッシュサーバーや、プロキシサーバーに悪意のあるコンテンツをキャッシュとして残し、他のユーザーにも影響を与える
  • 上記で紹介したリダイレクトと同じで、レスポンスヘッダを同じように改竄する
    • そのときに、URLにレスポンスヘッダを書き込む
  • 改竄内容がレスポンスヘッダの中に2つのレスポンスを返す！という書き方をすると、レスポンスが分割されてしまいます

  • もし、通信経路の途中にキャッシュサーバー等があった場合に、2つ目の悪意のあるキャッシュが残せてしまう
  • キャッシュが汚染されて、他のユーザーにも被害が出る可能性がある

メールヘッダーインジェクション

メールメッセージのヘッダー部分に攻撃者が改行コードを挿入することで、任意のヘッダーフィールドやボディを追加することができる脆弱性

  • 考えられる影響
    • 宛先や件名などを書き換えられたメールが送信される
    • スパムや悪意のある本文を書いたメールが送信される
    • 悪意のあるファイルを添付してメールが送信される

クロスサイトスクリプティング(XSS)

攻撃者が仕掛けた罠にユーザーがはまることで、ユーザーのブラウザ上で悪意のあるHTMLタグやJavaScriptなどが動いてしまう脆弱性

構文の破壊がすべてのインジェクションの原因

  • 上記で説明したように、構文を処理するところで悪用されてしまいます。
  • なので、受け取った文字列を適切に処理させてやることが必要となります。
  • あなたの作ったアプリでは、構文が破壊されるようなところがないか？というのを確認しましょう

参考著書

  • 脆弱性診断スタートガイド: 上野宣さん

この記事を書いた人

にょこた
PM（プロダクトマネージャー）目指して奮闘中、プログラムから、アーキテクト設計、サービス検討から、チームマネジメント、DevOps、いろいろやってます。

セキュリティ