安全なwebアプリケーションの作り方 344-371
- アカウント管理
- ユーザ登録
- SQLインジェクション、メールヘッダインジェクションが混入しやすい。
- メアドの受信確認をちゃんとする!本人確認大事。
- でも、トークンを発行してそれ付きのURLを踏ませてってのは、ユーザに「メールで来たURLを踏む」という経験を与えるのでフィッシングに引っかかりやすくなる?
- 確認番号送って入力してもらうのが一番いいけど、メールでURL踏むのが一般的な気がするなぁ
- ユーザIDの重複も防止したほうがよい(というか当たり前) 前パスワード違えば登録出来て、間違って他人のに入れたりするのがあった。あとは論理削除してるから一意制約つけられないとか
- CAPTHAで自動登録防止しよう
- パスワード変更
- 変更と同時に現在のパスワードを確認→変更時にはメールでその旨を通知する。
- こうすると少なくともCSRF脆弱性は防げる。SQLインジェクションはがんばる。
- メアド変更
- 新規メアドへの受信確認→再認証→新旧メアドへの通知
- 乗っ取られてたらわかるのでちゃんと通知することが大事
- パスワードリマインダ(パスワードリセット)
- 管理者向けと利用者向けを分ける
- 管理者向けはマスターってかadminだけど、結局脆弱性の温床??にもなるのでものによっては実装しなくてもよい。
- 管理者:本人確認→「仮」パスワード発行→ユーザがパスワード変更
- 「仮」パスワードのしくみを作っておく(このパスワードではパスワード変更しか行えない、とか)
- 利用者:本人確認(メアド認証&&秘密の質問)→パスワード通知→変更
- このパスワード通知、平文で送ったりしない!!!仮パスワードを発行するか、パスワード変更画面に直接遷移するリンクを送るかのどっちか。
- 実装上では、登録されてないメアドでもエラーにせず、ログで知らせるとか、悪用可能なところをちゃんと潰す。
- アカウント停止
- まあそのまま
- アカウント削除
- 取り返しのつかない処理なので、意思確認とCSRF対策のためにパスワード再認証したほうがよい。
- ユーザ登録
- 認可制御