HTTPSを使ってもCookieの改変は防げないことを実験で試してみた
寺田さんのブログエントリ「他人のCookieを操作する」には、通信路上の攻撃者がいる場合は、SSLを使っても、Cookieの盗聴を防ぐことはできるが、Cookieの改変を防ぐことはできないと指摘されています。いかにも寺田さんらしい簡にして要を得たエントリで、これに付け加えることはあまりないのですが、残念ながらまだ読んでいない人が多そうだと言うことと、より広い読者に向けて具体的に説明した方がよいだろうと考えました。 そこで、通信路上に攻撃者がいる典型例として、公衆無線LANの偽AP（アクセスポイント）があるケースを題材として、「HTTPSを使ってもCookieの改変は防げない」ことを説明します（Secure属性使うと盗聴は防げますが、改変は防げません）。長いエントリなので結論を先に書いておきます。 Secure属性がないCookieはHTTPSでも盗聴できる Cookieの改変についてはSe
他人のCookieを操作する - T.Teradaの日記
少し前の話ですが、Googleが自身のWebサイトの脆弱性発見者に対して、報酬（現金 500 USD以上）を支払うプログラムをはじめています。 Google Online Security Blog: Rewarding web application security research 過去にも、脆弱性の発見者に報酬を支払うプログラムはありましたが、Webブラウザ等のソフトウェアの脆弱性が対象でした（参考）。 今回のプログラムでは、Webアプリの脆弱性が対象だというところが特色です。しかも、実際に運用されている本番のGoogleサイトの脆弱性が対象です。その脆弱性の発見者に報奨金を払うということは、（一定の制約は設けていますが）基本的に自由に本番サイトの検査をしてよいといっているわけです。 実際にやってみる Webアプリの診断をやっているものにとっては、これ以上のお小遣い稼ぎはない！と思
安全なセッション管理を実現するために
ログイン前とログイン後でセッションIDが変化しない セッション固定攻撃が成立する最後の条件はログイン前とログイン後でセッションIDが変化しないことだ。セッションIDを変化させるためには明示的な実装が必要となるから、意識して実装されていない限り条件が成立する可能性は高いといえるだろう。 ほかの条件については、独自に機能拡張されたアプリケーションサーバやフレームワークを使用するなど、複雑な対策が必要となるが、最後の条件だけは、容易な実装で対策することが可能である。 対策： ・ログイン成功時にセッションIDを再発行する セッションIDを変化させるには、ログインが成功したらセッションIDを再発行させればよい。再発行の時点でセッションIDは攻撃者にとって未知の値となるため、セッション固定攻撃は成功しなくなる。具体的には以下のような実装となる。 /** ログイン処理を実行して成功したらセッションを再発
Androidの標準Webブラウザでセキュア属性付きのCookieの扱いがPCやiPhoneと異なる件について - susumuis Info
Android用のWebサイトを作っていてはまったので、報告します。対象はブラウザ上で動くWebアプリの話で、ネイティブアプリではありません。 Googleで検索しても、ネイティブアプリ関連の情報は出てきますがWeb開発の情報が意外とすくなかったので、少しでもお役に立てれば幸いです。 概要 Android標準ブラウザ（Dolphinブラウザなども含む）で、セキュア属性付きのCookieの挙動がiPhoneのブラウザや、PCのChromeなどと異なります。 Cookieやセキュア属性の概要はこちらなどをご参照ください。http://itpro.nikkeibp.co.jp/article/COLUMN/20080221/294407/ PCやiPhoneのブラウザの場合、WebサーバがSet-Cookieレスポンスヘッダを返した場合、例え、そのCookieのセキュア属性が設定されていても、ブ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
