当 Blog を SSL 対応させたので手順や修正が必要になった点などをまとめ
10年間運営されてきた自分の Blog を SSL 対応させるにあたって、その手順や、SSL 化したことで修正をしなければならなくなって大変だった点などを簡単にまとめてみようと思います。 なぜか先週末の夜中に急に思い立って、この Blog のドメイン用に SSL 証明書を購入し、急遽 SSL 対応 （HTTPS でアクセスできるように） してみたわけですが、その手順やら、SSL 化したことでちょっと手直ししないといけなくなって大変だった点などをまとめて見ようと思います。 ちなみに、まだリダイレクトや HSTS （HTTP Strict Transport Security） はドメインに対して有効にしていないので、現状は HTTP / HTTPS どちらでもアクセスできる状態。もうちょっと検証した上で HSTS を有効にして所謂、常時 SSL 化する予定。 10年間以上運営してきた Web
書籍『Webアプリケーションセキュリティ対策入門』のCSRF脆弱性 | 徳丸浩の日記
図のように、大垣本のCSRF対策方式（以下、「大垣方式」と表記）では、トークン（同書ではフォームIDと表記）をランダムな鍵として生成（②）し、それをフォームの隠しフィールドとDBに保存します（③、④）。ユーザーがフォームをサブミット（⑤）すると、送信されてきたトークンがDB上に存在するか確認（⑥）し、あればトークンを削除（⑦）して、サーバー上の処理に進みます。⑥でトークンがDBにない場合は、エラーとして処理には進みません。 一般的なCSRF対策手法との違い 大垣方式が一般的なCSRF対策と異なる点は以下の2点です。 フォームの2重投稿防止機能を兼ねている トークンがセッション変数ではなくDBに保存される トークンの有効範囲は? トークンがDBに保存される場合、トークンの有効範囲が気になるところです。大垣本および第二版のソースを見ると、トークンを保存するテーブルの定義は以下の通りです。 CR
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
