■http://anond.hatelabo.jp/20100404213508

気がついたら、ホールとか、気がついたらワームとか、気がついたらトロイ

ってのは、この業界　少なくないからさ、それ自身は　仕方が無いと思うんだよ。

事故はしょうがない。

でもなぁ、

ウイルスだったら、ウイルス対策ソフトを入れてるかどうかは、事故なのか過失なのかの大きな分岐点になるよな。

今回みたいなサービスだったら、セキュリティーの試験をしたかどうか？は、事故なのか過失なのかの大きな分岐点になると思うんだよ。

で、どう考えても、これ、まともには試験されてない。

なんだろうな、チェックリスト作ればいいのかね？

最低限このぐらいは・・・リスト

＞パスワードを平文で保存しない

　保存する場合は、特別な手段をとらないと社員でもパスワードを読めないようにする。

　保存する場合は、ユーザーに電子的な手段でパスワードを回答しない。かならず、受取人指定の郵送とする。

＞電話対応で社員等がユーザーのパスワードを直接聞かない。

　ユーザーのパスワードが必要な場合は、無人システムに投入する等する

　ただ一般的には、住所氏名電話番号生年月日で代用することがほとんど

＞パスワードを暗号化する場合は、暗号化ではなくハッシュ化する。

　とにかく、パスワードを管理者・社員が取得できてはいけない。

　暗号化とハッシュ化の違いが分からないなら、勉強させる。知らない人間を担当者にしてはいけない。

＞パスワードをGETの引数に入れてはいけない。

　GETのパスワードはログに残るため。ログからパスワードが流出する

＞パスワードが必要な操作をユーザーに代わって行う場合

　ユーザーにパスワードを聞いていはいけない。

　ユーザーの代わりに管理者アカウントでその操作を行い、だれが、いつ、その操作を行ったかはシステムで記録する

　よく管理者アカウントが１つでだれだか操作したわからないというシステムがあるがナンセンス。

　かならず、いつ、だれが、というのはシステムで明確にログを取る。

　そして、ログを取っていることを社員に伝える

＞URLの後ろに、ユーザー毎　取引毎　セション毎のランダムなセッションキーが付いていると良い

　COOKIEも併用すること。URLはキャッシュ等の対策のため

＞セッションキーを他のユーザーの物に変えてログイン出来ないことを十回以上は確認する

　又は、何らかの理由でセッションキーのみでログインする場合は、十分に長い文字数にすること。

　数字を１つ２つ変えても他人のログがみられないように、十分にセッションキー同士を離れさせ

　機械的に、総当たりでログインが試みられて場合検出して遮断する機能を入れること。

　遮断装置が無いのに、セッションキーのみでのログインは、ガードしていないのと同じ。

＞ユーザー　パスワードを適当に変えて、他のユーザー名で同一パスワード　などの組み合わせが通らない事を１０組み以上は確認する。

＞一定時間以上操作がない場合は、自動ログアウトする機能をつける

　漫画喫茶など対策

＞クレジットカードなど課金情報は同一サーバーに持たない。可能な限り記憶しない

＞Proxyのキャッシュなどに残らないようにメタタグをつける

＞個人情報が含まれる場合はセッションはhttpsをつかう

Permalink | 記事への反応(1) | 23:17

ツイートシェア