7payに学ぶセキュリティを意識した設計の大切さ
7payの不正利用のニュースが世間で話題になっています。
7payの事件からセキュリティがいかに大事な事なのか分かると思います。
システム開発会社社長の「セキュリティよりも利便性」という考え方が7payシステムの設計に影響している可能性も否定できません。
システムの仕様を考えるときに大切なセキュリティについて書いていこうと思います。
セキュリティとして考えなければならない事
ここで書くことが全てではありません。
必要最低限どのシステムでも必要になる項目の一部だけ紹介しておきます。
各種入力値のチェック
GETであろうがPOSTであろうが入力されたパラメータのチェックは必須です。
決して入力された値をそのまま使ってはいけません。
受け取ったIDでそのまま処理したり（乗っ取り等）、受け取ったパラメータをDBへそのまま入れようとたり（SQLインジェクション等）、ファイル名に使ったり（不正アクセス）、ループ回数の決定に使ったり（無限ループや高負荷など）等、何かしら処理を行う事全てに注意が必要です。
そもそもユーザIDに関しては今のセッションから分かるので入力パラメータや引き回すパラメータとして必要ないはずです。
受け取ったパラメータの適正な範囲のチェックや特殊文字のエスケープ処理などは必須です。
基本的な考え方としては受け取ったパラメータで悪さする・異常の出る方法はないか探して潰していく感じです。
大抵のフレームワークでは大元の共通処理で行ってくれている場合が多いですが、常にどんな処理でも必要な考え方です。
各種出力値のチェック
画面に表示するパラメータはもちろんのこと表示されない出力値も注意が必要です。
不必要な内部IDの露出も避けるべきです。
ユーザIDは現在のセッションから分かるようにしておき、引き回さないでよいようにするべきです。
セッションIDはなるべく推測しづらく長い物がいいと思います。
もちろん出力するパラメータの文字列のエスケープ処理も必須です。
不正アクセス
認証の連続間違いは回数や間隔などは制限するべきですし、今回問題になっているパスワードの再設定機能もセキュリティをよく考えて仕様を設計するべきです。
仕様的な脆弱性は如何ともしがたいです・・・。
またサポートが使う管理機能へのアクセスはサービス部分とは分離してネットワーク層レベルでもアクセス制限が必要です。
そして、各ページ、機能へは基本的に同じエントリーポイント用のスクリプトへのアクセスにした方がよく、機能ごとに直接スクリプトを叩くような設計は避けた方がよいです。
表にさらすスクリプトはエントリーポイント用のスクリプトファイルだけにしましょう。
たまに設定用のスクリプトをURL上から叩けてしまう場所に設置しているシステムを見かけますが避けるべきです。
一般的に使われているフレームワークを使用していればあまり心配ないと思います。
フレームワークを使っていても理解の足りない人がいると直接スクリプトファイルを設置して機能を実装してしまうかもしれませんので注意して下さい。
まとめ
7payのシステムからいくつかセキュリティ的なことを書いてみましたが、全然これだけではありません。
基本的に悪意を持ったユーザが使う前提でシステムを設計し処理を実装するという考え方が必要になります。
開発者は常に悪者の立場で「こういうパラメータを渡したらこういう不正ができる」などのような思考をしながら、それを防ぐような設計や実装をする必要があります。
いまのフレームワークでは主なことは基底の処理で自動的にやってくれますので、そういう思考がなくても開発できてしまう現場が多いのかもしれません。
それ以上に7payのシステム開発会社は技術的にも会社的にも開発体制や手法的にも経営的にも、とても古い時代の化石的システム会社なのではないかという雰囲気が漂っています。
7payのようなことにならないためにも会社の技術者も常に情報を仕入れて取り入れて、時代に合わせてアップデートしていく必要があります。
7payを反面教師にシステム開発のセキュリティの大切さも意識して学んでいきましょう。