フィッシング詐欺＆ファーミング詐欺関連技術

セキュリティ

どうでもいいけどスペルはfishingじゃなくてphishingなんだってね。また同じくfarmingじゃなくpharming。検索しやすいからいいんだけど。
今回は詐欺する側の手口と詐欺に利用される業者側の対策を整理してみる。
　
手口についてはメール出して云々なんてテレビで見てくれっつーことで割愛。
進んだ人たちが使う技術を整理する。

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

Webフォームに入力されたデータに対する十分な処理がなされていないサイトが標的。入力データに悪意あるコードを混ぜると、下手なサイトはそのコードをそのまま出力結果に反映するため、クライアント環境が解釈して実行してしまう場合がある。これを利用してクライアント環境でｺﾞﾆｮｺﾞﾆｮする攻撃手法。
具体例を出すと、送信された内容を確認のためそのまま出力するサイトなどが攻撃対象としてわかりやすい。
以下の内容で登録してよろしいですか？とか言って住所や氏名を列挙してくれるサイト。こういうサイトの中には、入力された内容をバカみたいにそのまま表示してくれる奴があって、下みたいになる。
入力データは　

名前　<s> <font size=24> hoge 
住所　 どこか

とする。
賢いというかまっとうなサイトなら

以下の内容で登録してよろしいですか？
名前　<s> <font size=24> hoge 
住所　どこか 
　・・・以下略

となるが、お馬鹿なサイトだと

以下の内容で登録してよろしいですか？
名前　 hoge
住所　どこか
　・・・以下略

となってしまう。
この程度のHTMLタグならギャグで終わるが、うっかりjavascriptとかかかれた日にはエライことにもなりかねない。
どこぞの良くないサイトにcookieを送信するスクリプトとか含まれたら見事にセッションハイジャックが実現してしまう。非常によろしくない。
そして何より具合が悪いのは、本物のサイトに入力しているのに攻撃が成立してしまうということ。たとえばクーポンコードのところにこれを入力しておいて、「このクーポンコードで8割引にするので消さないでください」とか言われた場合、ウチの家族なら信じかねないｗ　URLだけ確認して安心しかねない。とてもやばい。サイト管理者側がちゃんと対策しておくことが大事。
　

対策

で、管理者様はどんな対策をすべきかという話。
方向性は簡単。入力データを処理する段階で不正なコードをすべて無力化すればOK。
具体的にどうするかといえば、所謂「エスケープ処理」と言われる、入力データを純粋に文字列（実行コードとしてではなく、特殊文字も何もかも忠実に再現したテキスト）として表示する処理を行うのが一つの手法。
もう一つは入力時にデータの形式や長さ、値の大きさなどをチェックして不正なものをキックするという手法。
前者は、上にある「まっとうなサイト」の例の如くタグもスクリプトも全部テキストに変換して表示するやり方。これだと攻撃者は悔しがることしかできない。
後者はもっと早い段階で、期待しないデータ入力をすべて拒否するやり方。つまり年齢の欄に　なんて書かれてもどうしようもないから、数値以外のデータが入力されたら
　年齢欄には半角数字で入力してください
みたいなメッセージを表示するやり方。これだと登録時のエラーも防げるので一石二鳥。住所とかの欄で半角文字を拒否するサイトが多いのも最近はこの手法の一環なのではないかと思う。ちなみに長さっていうのは、ローマ字氏名やIDみたいな半角英数を許容せざるを得ない入力欄で使える。攻撃コード並みに長い名前ってのは寿限無寿限無五劫の擦り切り海砂利水魚の（略でもない限りあり得ない。故に杉田君には我慢してもらって異常に長いデータを排除する訳である。
　

DNSポイゾニングとその類似手法

どちらかというとファーミング詐欺と呼ばれる手口。
こちらは正しいURLを入力してもニセサイトに転送され、そこで登録情報が盗まれるという奴。
具体的な手法としては、DNSのキャッシュを書き換える（DNSポイゾニング）や、ユーザーのhostsファイル（DNSに問い合わせない静的な名前解決用の設定ファイル）を書き換える、などの手法がある。
これを使われると名前解決の段階でニセサイトのIPアドレスを噛まされて知らずに誘導されてしまうことになる。この手口もなかなか悪質で、普通なら毎回nslookupしてipアドレス直打ちでサイトに接続する、石橋たたいてヒビ入れるぐらい用心深い人でないとまず気づかない。
くわばらくわばら

対策

DNSキャッシュの汚染やhostsファイルの書き換え自体がまずあっちゃいけないことなのだが、管理者様から見るとこれらは管理外のファクターな場合が多い。しかし無知なユーザーさんてのは概してわがままでおまえが対策しろと言う。仕方ないのでサイト側としても対策を講じる。
で、その対策手法というのがSSLとか電子証明書の類を導入すること。これらは接続したサーバーが第3者にも認められた正当なサーバーであることを証明する。つまりこいつを取得していれば、少なくとも「この証明書が発行されていないサーバーはウチのじゃない」と言えるし、ユーザーに注意を促すこともできる。確認しないユーザーなんていっぱいいるだろうけれど、少なくとも手段は提供できる（責任回避？）
なんか話が変な方向に行きそうなので整理すると、
早い話が「このサーバーは本物です」ということが示せれば良いわけで、ユーザーもその証明を確認した上でつなぐようにすれば安心してやりとりできる。
というところから、第三者機関による認証を受けたことを示す「電子証明書」が有用であると言うこと。
SSLを使えば、サーバーの証明と通信の暗号化が一緒に行えるのでなお安全。
ただし、最近はこの証明書自体が正当かどうかを確認しないと痛い目を見るので注意。たとえば　このサーバーはA社のものと証明します。by A社　って証明書は、自分で書いて自分でハンコ押してるだけなので簡単に偽造できてしまう。所謂オレオレ証明書ってやつです。
信頼できる証明書というのは、認証機関C社（これは国なり組織なりが認めたまっとうな業者ね）により発行された「このサーバーはA社のものと証明します。by C社」　って証明書。
まあ、この辺はSSLや電子証明書について詳しく学ぶと出てくるので詳しくはそっちで。