「安全なWebアプリケーションの作り方」を読んでセッションを復習してみた - As a Futurist...
タイトルが長くて略称があれば知りたい感じの「安全な Web アプリケーションの作り方」を暇を見つけて読んでいます。今まであいまいなままだった部分を順を追って説明してくれるので、本当に助かります。Web アプリ作りの初心者は卒業したかなーという人は必ず目を通しておくと良いと思います。 Cookie を用いたセッションについて復習 「HTTP はステートレスで」とかいう話はよく聞きますが、じゃあどうやってセッション管理するのがいいの？って話をよく考えると体系的に聞いたことがなかった！というわけで、この本で文字通り体系的に学び直すことができました。 その中でも、「セッション ID の固定化」という話題はちゃんと分かってなかった部分があったので、こちらのサイトを参考に PSGI なアプリケーションを作ってみました(僕の書いたアプリ自体はその他の脆弱性に溢れていますがｗ)。コードはエントリの最後に。
CSRF 防止用トークンの自動チェックの問題と解決 | tech | perl - 氾濫原
自分が作るウェブアプリケーションでは基本的に以下のような規則を守るようにしている GET だけで副作用 (DB書きこみなど) を伴う処理をしないこと POST 時には自動的に CSRF 防止用トークンをチェックすること これだけで単純な CSRF はまず防げくことができるからだ (実際は CSRF 防止用トークンの生成方法が多少問題になるが、作るウェブアプリケーションによって、どれほど厳密にすべきかが違うため、そのたび考えてやりかたを変えてる) このような設計をした場合、全ての POST するフォームに input type="hidden" とかで CSRF 防止用トークンを埋めこむ必要がある。ウェブアプリケーションフレームワークによっては、防止用トークンを埋めこむところも自動的にやってしまうものもあるが、外部サーバへ POST するフォームなんかを作ったとき (ASP型の外部サービスと
パスワード管理について「安全なWebアプリケーションの作り方」で学んだので実装してみた - As a Futurist...
前回半分くらい読んで積読になってしまっていた「徳丸本」こと「安全な Web アプリケーションの作り方」を週末に読みきりました。本当にいい教科書だと思いますので、脱初心者を目指す人は読んでみると良いと思います。 特に今までぼんやりとしか理解していなかった「パスワード管理」について非常に体系的に分かりやすく説明されていたので、せっかくなので Plack アプリで実装してみました。ソースは gist に貼っておきました。 基本的には徳丸本にあったとおりに実装しています。 パスワードはハッシュをかけた値を DB に保存 但し単純なハッシュ関数だと漏洩したときにクラックされる(=逆方向に解析される) そこで 2 つの対策を組み合わせる salt 値 user_id と固定値を利用して salt 値を作りパスワードに付加してハッシュを取る もし同じパスワードのユーザがいてもハッシュ値は異なる ストレッ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
