読者です 読者をやめる 読者になる 読者になる

log

安全なwebアプリケーションの作り方 344-371

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

  • 認可制御
    • 認証された利用者のみに許可された機能/情報の閲覧/編集操作など、不備があるとぽろぽろ漏れるので気をつける。
    • 設計時にきちんとすると、テストもしやすい。
    • 権限マトリックスとか使って、ちゃんとユーザと権限を対応させておく!
    • ロールを持たせて、ある管理者に全部やらせる(複数人で1つのアカウントをいじる)とかはダメ
    • 認可不備が起こる原因はURL/hiddenパラメータ/クッキーを書き換えられないと思い込んでいることがおおい。これらが書き換えられても大丈夫なセッション変数に権限情報を格納すること!

  • ログ出力
    • (1) 攻撃や事故の予兆を把握、早期対策 (2) 攻撃や事故の事後調査 (3) アプリケーションの運用監査
    • ログ出力の要件とか、色々あるので p.366 参照。
    • ただ、後から突き合わせるのに大変だから、サーバーの時刻合わせは必要だよ。NTPとか使おう。
    • 実装はすでにライブラリ化されてるものがあるから、それ使ったほうが楽。log4j, log4php
    • 開発時にはdebugレベル、運用時にはinfoを指定すれば、コード変更することなくinfo以上の重要度ログのみ取得出来るし、危ない情報を残すこともない。