地味に書きためていくWeb開発セキュリティのキホン

XSS対策

  • インターネットから送られてくる入力値は絶対に信用しない。（post /get に留まらず、URLそのもの、Headerの中身や、画像のexif情報なども！）

  • 情報を出力する時のescapeは、文脈にあわせて変える。htmlに出す場合とJavaScriptに出す場合、CSVに出す場合、JSONに出す場合でescapeの方法が変わる！

  • echoする時は、基本全部にescape。コントローラ側の文脈に依存する「この変数にそもそもescapeは必要か？否か？」に任せると、後で技術的負債化する！ 　そうではなく「ここの出力方法が適切か？」を一目でチェックできるようにすると簡単にチェックできる。あとから数千個、数万個をチェックする人の身になってコードを書く。

  • 外部からの引数で、処理を分岐する場合は、必ず値を比較して想定する文字に一致した時のみ処理するように書く。 　絶対に、そのままの値を引き回さないこと。 　リフレクションとかevalとか、動的呼び出しを覚えてたての頃は、楽しくて、複雑な処理を書きがちなので、より注意すること！

例：条件に一致した場合変数に置き換えてしまうなどで、入力値をそのまま使いまわさない

 $cmd = param['cmd'];
 if ($cmd && $cmd == "delete_all" ){
    $cmd = "delete_all";
}else{
    // raise error
}

validationのキホン

  • JavaScriptはユーザビリティのためのチェック、セキュリティのための値チェックは絶対にサーバサイドで！！

  • 範囲以外やnull以外もチェック。文字列長や文字列フォーマットは適切か？をチェックする。

  • 攻撃者はJavaScriptのvalidationやフォーマットチェックは回避することができることを前提にしてサーバサイドの値受けを考える。

  • 数字を期待するところに文字列が入った場合、記号が入った場合は必ず想定してコードを書く。

セッションクッキー系

  • クッキー認証のキーは、何かあったら必ずサーバサイドでexpireできるようにしておく。

  • クッキー認証のキーは、ユーザーの意思でexpireできるようにしておく。（ex. ログアウトするとクッキーとサーバ側の情報両方がexpireする）

  • クッキーは盗まれるものとしてサーバサイドのセッション復帰方法を考えよ。 （どこまで譲れるか。個人情報は再ログインを求める）

  • セッションクッキーが盗まれた時、認証クッキーが盗まれた時、それぞれのパターンとリスクを検討しておくべき。

  • Webはセッションクッキーは盗まれない前提で設計されている。それが故にXSSはリスク！ 　（セッションクッキーはブラウザを閉じたらexpireすることを前提に、セキュリティが担保されていることになっていることに注意！）

アップロードされたファイル処理

TODO

SSL系

TODO httponly属性推奨するのとSSL証明書あるならSecure属性も絶対推奨