おさかなラボ - strictなシステムに対するSession Fixation対策
Session Fixationについては話題になって久しいので今さら解説するまでもないと思う。……と思ったらそうでもなさそうなのでちょっと書いてみる。 Session Fixationとは何か 一般に、Session Fixationとして話題にのぼるのは、PHPなどにおける以下のような手法である。 http://www.example.com/index.php?PHPSESSID=abcde こうすることで、(対策の取られていない)PHPは、セッションIDを’abcde’と解釈してしまう。セッションIDは本来サーバーが発行するはずのものであるが、URIに埋め込むことでクライアント側からセッションIDを指定することが出来てしまうものである。 この「セッションIDが任意のものに設定可能である」ことを利用した攻撃をSession Fixation攻撃と呼ぶ……と解釈している人は以
おさかなラボ - クロスサイトリクエストフォージェリ対策
過去の議論はこちら 一般的に言われている対策と実際の有効性についてはこちら 一般にCSRFはセッションの利用に伴う脆弱性なのだから、予測不能な文字列を生成してhiddenとセッション内(PHPセッションの場合$_SESSION内)に入れておき、完了画面でこの2つを照会する方法が簡便で堅牢だと考えられる。(要はセッションを使ったワンタイムトークン方式)。 この対策だけでも充分だが、hiddenを横取りされた場合に発生する脆弱性に備え、Cookieでも比較を行う。 実際のコード // 確認画面 session_start(); (認証など略) $uniq_id = md5(uniqid(rand(),1)); // 推測不可能な文字列を生成 $_SESSION['uniq_id'] = $uniq_id; // セッションに保存 setcookie('uniq_id',
おさかなラボ - 携帯電話からセッションIDの漏洩を防ぐ
携帯電話向けWebアプリの脆弱性事情はどうなっているのか@高木浩光＠自宅の日記 より リンク先のWebサイトには、Refererと共に端末IDもリクエストヘッダとして送信されているわけで、セッションID入りURLと端末IDがセットで流出するのだから、当然、同じHTTPリクエストを送るだけの方法でなりすましアクセスされてしまう。 URIにセッションIDを含める方法では、悪意のあるサイトにリンクを張るだけでRefererヘッダからセッションIDが取り放題となる。また、悪意のあるサイトにアクセスしたユーザーは端末IDもHTTPヘッダに含めそのサイトに送信してしまう。端末IDは簡単に詐称することが出来るので、端末IDをチェックしてもセッションハイジャックの防止線にはならない、というお話。 私は携帯端末は専門ではないので細かいことは良くわからないのだが、以下を前提にして、携帯電話からセッション
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
