wasbook reading #9

「体系的に学ぶ安全なWebアプリケーションの作り方　脆弱性が生まれる原理と対策の実践」読書会の第9回。
年内の読了は絶望的に…。今回読んだのは以下の範囲。

5章代表的なセキュリティ機能
- 5.2 アカウント管理
- 5.3 認可
- 5.4 ログ出力

5章代表的なセキュリティ機能

5.2 アカウント管理

アカウントの管理は、セキュリティに直結する。そして面倒。以下のような注意点が挙げられていた。

メールアドレスの受信確認
ユーザ ID の重複防止
ユーザの自動登録への対処(任意)
パスワードに関する注意

最近だとメールアドレスを登録して、確認のメールが来て、そこにあるURLをクリックして、メールアドレスの確認を行うことが多い。
パスワードの変更は特に注意が必要だと思う。現在のパスワードを確認し、パスワードを変更した場合はメールで通知する必要がある。またパスワードを忘れるひとは必ずいるので、その場合もパスワードを変更する必要がある。正しい変更方法を考えるのは難しい。本書ではいくつかの方法が紹介されているので、実装することがあれば参考にしたい。これ、気を使うよね。

5.3 認可

認可によって、権限が与えられる。この画面を表示できるか、この機能を利用できるか、といったことは権限の有無で決まってくる。
やってはいけないのは、画面や機能へのリンクの表示を切り替えるだけのもの。権限によってリンクの表示/非表示が変わるけど、直接アクセスしてみるとちゃんと利用できてしまうようなもの。もちろん直接アクセスして使えないはずの機能が使えてしまうのはまずい。
というわけで、ちゃんとそれぞれの機能や画面で制御を行う必要がある。まずは以下の内容を確認することが重要になる。

このスクリプト(画面)を実行してよいユーザであるか
リソースに対する操作(参照、変更、削除など)の権限はあるか

5.4 ログ出力

なにか起きた時のために、ログは大切。でもあまり多く出てきても困るし、少なくても困る。
ここからさきは個人的な見解。
Webシステムであれば、アクセスログはしっかりだして、アプリケーションのログは少なめでもいいかなと。障害が発生した時、ピンポイントで原因のわかるログがでていたら嬉しいけど、そんなことはあまりないし、だったら少なめでいいかなと。
# 障害対応だと、日常的にスタックトレースがでているようなシステムも…
個人的には、ログ出力のレベルを簡単に切り替えられることが、けっこう重要だと思っている。なにか起きたら、多めにログをだすようにさくっと変えられる、とか。
そしてなにより、ちゃんとログの設計を行なっていることが大事だと思う。後回しにされていたり、適当になっていることも多そうなので。

まとめ

最近はOAuthやOpenIDで、認可や認証が行われることが多いけど、やっぱりユーザ管理を実装しなくてはならないこともある。ひとつ間違えると、非常に大きな問題になるので、しっかり設計して実装する必要がある。
また開発者の視点で考えると、どうやって実装するかも大事だけど、どうやってテストするかというのも大事だと思う。単純にログイン出来るかというだけでなく、アカウントロックされるか、パスワードはしっかり保護されているかといったことを十分に確認する必要がある。
ま、簡単には覚え切れないので、実装するときには読み返そうとおもう。

wasbookに関するものは、こちらのタグで。