[ThinkIT] 第1回：Webアプリケーション開発者が知っておくべきセキュリティ (2/3)ここでは、Webアプリケーションのセキュリティ実装として、IPAへの届出件数の多かった脆弱性や攻撃による影響度が大きい脆弱性を主に取り上げ、それらに対する根本的解決および保険的対策を示します。 SQLインジェクション OSコマンド・インジェクション クロスサイト・スクリプティング セッション管理の不備 パス名パラメータの未チェック/ディレクトリ・トラバーサル メールの第三者中継
[Teeda]ログインとかセッションについて (みしんの日誌 社内ブログ開発議事録)
ブログなんで管理者画面が必要となります。そのためには認証機構が必要となります。それをTeedaではどうしようかということの調査メモ。(なんで、どうするかはまだ決まってないし、試してもいない) まず、ログイン情報をセッションに持たせるかどうかって話だけど、Teedaの説明ページで、以下のように書いてある。 Teedaの状態維持のポリシー、それは状態をなるべくTeedaで持たないということです。 状態はHTML側に埋め込むまたは、サーバサイドのpersistence層で保管するようにしてください。 HttpSessionというライフサイクルがよくわからないものに頼らない方法を Teedaでは推奨しています。 だけど、ログイン情報みたいにリクエスト毎に確認しなきゃいけないものに関してはセッションで管理したほうがつくりや管理が簡単になるのではないかと。で、そんなことを思う人はいて、メーリングリ
安全なセッション管理を実現するために ― ＠IT
HTTPを使用したWebアプリケーションにおいて、安全なセッション管理を行うことは難しい問題である。タブブラウザによる画面の複数起動や、Webブラウザの戻るボタン／更新ボタンの押下といった、予期しない画面遷移に起因するバグの発生に頭を悩ませることは多いだろう。 大きな問題が発生しないならば、画面遷移の仕様上の制限をクライアントに許容してもらう選択肢もあるだろうが、不正な画面遷移を利用したセキュリティホールが存在するならば、放置しておいてよい問題ではなくなる。今回はセッション管理を安全に行うための基本的な注意点について解説していこう。 セッション固定攻撃とは何か セッション固定攻撃（Session Fixation）という脆弱性を耳にしたことはあるだろうか。脆弱性そのものの詳しい解説は本稿の趣旨ではないため割愛するが、簡潔に説明すると、以下のような手順を踏むことによりセッション情報がハイジャ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
