Yahoo！IDのログイン履歴を確認可能に　不正アクセス対策

ヤフーがYahoo！IDのログイン履歴をユーザーが確認できるサービスを公開したようです。
ログイン作業を行った日時やサービス名などを過去60件分確認できるため、身に覚えのないログインがないか確認するのが目的のようです。

セキュリティ対策の一つの方法として、試験にも出てくる話なんですが、そういえばYahooには無かったような気がしますね。

履歴を確認する方法は大きく分けて２つあって、一つは履歴一覧を出力すること、もう一つは前回アクセスした日時をログイン後に表示すること。
この２つを組み合わせることで、不正アクセスの確認だけでなく抑止にも繋がりますが、あくまでもアクセスログが改ざんされていないことが前提となります。

自宅のデータサーバとして使っているTeraStationが壊れました。（あまりのショックに、私も壊れそうです）

バックアップの重要性を考え、RAID構成のデータサーバを使っていたわけですが、まさか本体が壊れるとは考えていませんでした。
RAID5の場合、データが各ディスクに分散されるので、本体が壊れるとデータが復元できなくなります。
分散することのデメリットを身をもって体験しました。

修理に出したのですが、データが残ったまま帰ってくる可能性は低いような気がしています。
今後は、耐久性に優れているMOなんかと併用する必要がありそうです。

AAで図解!ずばり一目で全く解らないコンピュータセキュリティ

これ、面白いです。
用語と元ネタの解説ページもあるので、訳が分からない人はそっちを見てもいいかも。

ベクターがウイルス感染事故の再発防止策を完了、5つの問題点に対応

実は私もベクターでオンラインソフトを公開していたりするので、他人事ではなかったりします。
公開している関係で、ベクターより対策完了の通知が来ていたので、その中から対策内容を引用します。

> 【1】ウイルス検出能力の向上
> 【2】未知のウイルスへの対応
> 【3】公開サーバへのファイル転送処理
> 【4】公開準備サーバの独立性の確保
> 【5】ウイルス検出時の対応方法の整備

今回の事件があったのが9月27日、対策完了が11月15日なので実に1ヶ月半もの時間が掛かっています。
正直な感想として、あまり迅速な対応ではなかった印象があります。

そもそもウイルスの発生源が社内であったことを考えると、あれだけのソフトをダウンロードできるようにしていながら対策されていなかったことがありえないですね。
客観的に見て、
・リスクに対する検討が不足していた
・技術的な側面からの対策および確認が不足していた（単一のウイルス検査ソフトメーカーの製品に頼っていた等）
・社内のセキュリティ対策が徹底されていなかった
・事故発生時の対策マニュアルに不備があった
などの問題点があったように思います。

特に、単一のウイルス検査ソフトメーカーの製品に頼っていたというのは驚きですね。
セキュアドでもこの手の問題が出ることがありますが、未知のウイルスへの対策は極めて重要になります。
価格.COMのときも、確か同様の問題点が指摘されていたように思います。

SQLインジェクションと並んで試験に出る頻度の高い「クロスサイトスクリプティング」もまとめておきます。

クロスサイトスクリプティング(Cross Site Scripting：略称 XSS)は別名ジャバスクリプトインジェクション(JavaScript Injection)とも言います。
不正なJavaScriptが実行されることにより、クッキー情報が漏洩する極めて単純な脆弱性です。
通常、この不正なJavaScriptは攻撃対象とは別のサイトになるため、クロスサイトスクリプティングと呼ばれています。

リスクとしては、クッキーを利用してセッション管理を行うサイトの場合にクッキーが漏洩することにより、セッションを乗っ取られることで他人へのなりすましが成立してしまうことです。
もう少し具体的に言うと、クッキーの中にセッションIDが保存されているとき、このセッションIDを盗むことができれば簡単に他人になりすますことができます。
別の例えをすると、他人の家の鍵を入手することと同じなので、鍵さえ持っていればいつでも入ることができますし、正面から鍵を使って侵入するため防犯システムでも感知されなくなります。
これと同様に、セッションIDを盗まれてなりすまされると、サーバサイドでは不正なアクセスなのかを判断することができなくなってしまいます。

脆弱性が存在するかどうかは、入力画面より
javascript: alert('Hoge')
あるいは
alert('Hoge');
のように入力し、その確認画面でダイアログが表示されるときに脆弱性が存在すると言えます。
ただし、セッション管理を行っていないサイトでは特に気にしなくて良い場合もあります。

この脆弱性を防ぐためには、基本的にはプログラムでの作りこみが必要となります。
（※ASP.NETの場合は不正なタグやスクリプトを入力するとシステムエラーにすることもできます）
一般的な方法は、表示する際にタグやJavaScriptを無効にする文字変換処理を加えることで、これをサニタイズと言います。
このサニタイズ処理は表示する直前に行うことが効果的です。
入力直後に変換した場合、文字数チェックが正常にできなくなったり、再入力時にサニタイズ前の状態に再変換しなければならなくなるからです。

セキュアドの午後２で、SQLインジェクションに関する問題が出題されていたので、少しまとめておこうかと思います。

SQLインジェクション(SQL-Injection)は、直訳すると「SQLの挿入」という意味になります。
簡単に説明すると、WEBで入力した値を元にSQLを組み立てるようなプログラムがあったとします。

極端なプログラムをC#で書くとすると、

string sqltext = "SELECT * FROM USER_TABLE WHERE USER_ID = '" + User.Text + "' AND PASSWARD = '" + Password.Text + "'";

そこで、入力用のテキストボックスに
User.Text ← "Hoge"
Password.Text ← "' OR '1'='1"
と入れると、生成されるSQLは以下のようになりますね。

SELECT * FROM USER_TABLE WHERE USER_ID = 'Hoge' AND PASSWARD = '' OR '1'='1'"

プログラムで1件だけ取得することを前提としている場合には、先頭のレコードのユーザでログインすることになります。
もしも先頭レコードが管理者権限だったら（最初に管理者を登録するシステムは多いと思うので、可能性は高い）、たったこれだけの手法で管理者権限が奪われることになります。
この攻撃は上記のとおり、非常に簡単な手法なのですが、実際に対策を実施しているサイトは少ないとされています。

セキュアドの午後２では、この問題が発覚する前に「エラー画面にSQL文が表示された」という兆候が現れていました。（まあ試験なので）
プログラマの視点からすると、デバッグ時の効率を考えSQL文を表示したのでしょうが、これは極めて危険な考え方です。
なぜなら、攻撃者に攻撃するためのヒントを教えるようなものだからです。
（多少の知識があれば、表示されている内容からデータベース構造の予想がつきます）

テーブルが分かっている場合、
Password.Text ← "';DELETE FROM USER_TABLE WHERE '1'='1
と入力すると、ユーザを全削除することも可能になってしまいます。
デバッグ時に表示するのはいいとしても、リリースバージョンでは表示しないように設定すべきでしょう。
ログファイルに出力している場合、そのログファイルは外部からアクセスできないようにしておく必要があります。

さて、実際のプログラムでの対策方法ですが、大きく分けて2つの手法があります。
・SQL制御用のタグをサニタイズする
・パラメータクエリを使用する

[SQL制御用のタグをサニタイズ]については、クロスサイトスクリプティング対策と似た考え方ですが、「'」を「''」のように二重化することでデータベースサーバ側で文字列として認識してくれるようになります。（'だけでなく、他の文字列もサニタイズが必要ですが、データベースによって方法が多少異なります。）

[パラメータクエリを使用]は、最良の方法だと思いますが、IN句が表現できないなどの問題も存在します。
IN句の取り扱いについては、サニタイズの手法と組み合わせるか、テーブル形式のXMLをパラメータにセットできるデータベースであれば結合演算させることで同じ結果を求めることが可能です。
パラメータクエリの利点として、セキュリティ以外にも速度が速くなるなどの効果が得られる場合もあります。

いずれにしても、プログラマは知っておく必要があり、事故が起こってから知らなかったでは済まない事態になることも少なくありません。
テストを行う際にも、この点を押さえた攻撃テストを行う必要があります。