現在はテクニカルエンジニア(情報セキュリティ)挑戦中です。不正アクセス対策ヤフーがYahoo!IDのログイン履歴をユーザーが確認できるサービスを公開したようです。ログイン作業を行った日時やサービス名などを過去60件分確認できるため、身に覚えのないログインがないか確認するのが目的のようです。セキュリティ対策の一つの方法として、試験にも出てくる話なんですが、そういえばYahooには無かったような気がしますね。履歴を確認する方法は大きく分けて2つあって、一つは履歴一覧を出力すること、もう一つは前回アクセスした日時をログイン後に表示すること。この2つを組み合わせることで、不正アクセスの確認だけでなく抑止にも繋がりますが、あくまでもアクセスログが改ざんされていないことが前提となります。12:34自宅のデータサーバとして使っているTeraStationが壊れました。(あまりのショックに、私も壊れそうです)バックアップの重要性を考え、RAID構成のデータサーバを使っていたわけですが、まさか本体が壊れるとは考えていませんでした。RAID5の場合、データが各ディスクに分散されるので、本体が壊れるとデータが復元できなくなります。分散することのデメリットを身をもって体験しました。修理に出したのですが、データが残ったまま帰ってくる可能性は低いような気がしています。今後は、耐久性に優れているMOなんかと併用する必要がありそうです。22:59セキュリティ技術AAで図解!ずばり一目で全く解らないコンピュータセキュリティこれ、面白いです。用語と元ネタの解説ページもあるので、訳が分からない人はそっちを見てもいいかも。実は私もベクターでオンラインソフトを公開していたりするので、他人事ではなかったりします。公開している関係で、ベクターより対策完了の通知が来ていたので、その中から対策内容を引用します。今回の事件があったのが9月27日、対策完了が11月15日なので実に1ヶ月半もの時間が掛かっています。正直な感想として、あまり迅速な対応ではなかった印象があります。そもそもウイルスの発生源が社内であったことを考えると、あれだけのソフトをダウンロードできるようにしていながら対策されていなかったことがありえないですね。・リスクに対する検討が不足していた・技術的な側面からの対策および確認が不足していた(単一のウイルス検査ソフトメーカーの製品に頼っていた等)・社内のセキュリティ対策が徹底されていなかった・事故発生時の対策マニュアルに不備があったなどの問題点があったように思います。単一のウイルス検査ソフトメーカーの製品に頼っていたというのは驚きですね。セキュアドでもこの手の問題が出ることがありますが、未知のウイルスへの対策は極めて重要になります。価格.COMのときも、確か同様の問題点が指摘されていたように思います。23:26セキュリティ技術SQLインジェクションと並んで試験に出る頻度の高い「クロスサイトスクリプティング」もまとめておきます。Injection)とも言います。不正なJavaScriptが実行されることにより、クッキー情報が漏洩する極めて単純な脆弱性です。通常、この不正なJavaScriptは攻撃対象とは別のサイトになるため、クロスサイトスクリプティングと呼ばれています。リスクとしては、クッキーを利用してセッション管理を行うサイトの場合にクッキーが漏洩することにより、セッションを乗っ取られることで他人へのなりすましが成立してしまうことです。具体的に言うと、クッキーの中にセッションIDが保存されているとき、このセッションIDを盗むことができれば簡単に他人になりすますことができます。別の例えをすると、他人の家の鍵を入手することと同じなので、鍵さえ持っていればいつでも入ることができますし、正面から鍵を使って侵入するため防犯システムでも感知されなくなります。これと同様に、セッションIDを盗まれてなりすまされると、サーバサイドでは不正なアクセスなのかを判断することができなくなってしまいます。alert('Hoge')あるいはalert('Hoge');のように入力し、その確認画面でダイアログが表示されるときに脆弱性が存在すると言えます。セッション管理を行っていないサイトでは特に気にしなくて良い場合もあります。この脆弱性を防ぐためには、基本的にはプログラムでの作りこみが必要となります。(※ASP.NETの場合は不正なタグやスクリプトを入力するとシステムエラーにすることもできます)一般的な方法は、表示する際にタグやJavaScriptを無効にする文字変換処理を加えることで、これをサニタイズと言います。このサニタイズ処理は表示する直前に行うことが効果的です。入力直後に変換した場合、文字数チェックが正常にできなくなったり、再入力時にサニタイズ前の状態に再変換しなければならなくなるからです。12:13セキュリティ技術セキュアドの午後2で、SQLインジェクションに関する問題が出題されていたので、少しまとめておこうかと思います。SQLインジェクション(SQL-Injection)は、直訳すると「SQLの挿入」という意味になります。簡単に説明すると、WEBで入力した値を元にSQLを組み立てるようなプログラムがあったとします。"'";などというコードがあったとします。'1'='1"と入れると、生成されるSQLは以下のようになりますね。'1'='1'"そうすると、USER_TABLEの全件が対象となってしまいます。プログラムで1件だけ取得することを前提としている場合には、先頭のレコードのユーザでログインすることになります。先頭レコードが管理者権限だったら(最初に管理者を登録するシステムは多いと思うので、可能性は高い)、たったこれだけの手法で管理者権限が奪われることになります。この攻撃は上記のとおり、非常に簡単な手法なのですが、実際に対策を実施しているサイトは少ないとされています。セキュアドの午後2では、この問題が発覚する前に「エラー画面にSQL文が表示された」という兆候が現れていました。(まあ試験なので)プログラマの視点からすると、デバッグ時の効率を考えSQL文を表示したのでしょうが、これは極めて危険な考え方です。攻撃者に攻撃するためのヒントを教えるようなものだからです。'1'='1と入力すると、ユーザを全削除することも可能になってしまいます。デバッグ時に表示するのはいいとしても、リリースバージョンでは表示しないように設定すべきでしょう。ログファイルに出力している場合、そのログファイルは外部からアクセスできないようにしておく必要があります。実際のプログラムでの対策方法ですが、大きく分けて2つの手法があります。・SQL制御用のタグをサニタイズする・パラメータクエリを使用する[SQL制御用のタグをサニタイズ]については、クロスサイトスクリプティング対策と似た考え方ですが、「'」を「''」のように二重化することでデータベースサーバ側で文字列として認識してくれるようになります。('だけでなく、他の文字列もサニタイズが必要ですが、データベースによって方法が多少異なります。)[パラメータクエリを使用]は、最良の方法だと思いますが、IN句が表現できないなどの問題も存在します。IN句の取り扱いについては、サニタイズの手法と組み合わせるか、テーブル形式のXMLをパラメータにセットできるデータベースであれば結合演算させることで同じ結果を求めることが可能です。パラメータクエリの利点として、セキュリティ以外にも速度が速くなるなどの効果が得られる場合もあります。いずれにしても、プログラマは知っておく必要があり、事故が起こってから知らなかったでは済まない事態になることも少なくありません。テストを行う際にも、この点を押さえた攻撃テストを行う必要があります。今年で個人事業12年目です。IT導入や技術のアドバイザーをやっています。どんな小さなことでもご相談ください。