※クライアントサイド ＝ Javascriptのdocument.cookieで作成。 ※サーバーサイド ＝ レスポンスヘッダーのSet-Cookieで作成。 ※いずれも、HttpOnlyフラグ無し、Secureフラグ無し。 この結果は、先の公式ブログで言及されていたとおりの挙動です。 クライアントサイド（Javascript）で作成したCookieのみ、有効期限が最大で7日に制限されています。 サーバーサイド（Set-Cookie）で作成されるCookieは制限を受けません。 参考画像： Safari 12.1 Beta3 でBingのCookieを表示。 Javascriptが作成したCookie "SRCHHPGUSR" の有効期限は、表示日時から7日後に制限されている。 その他のサーバーサイドCookieは有効期限の制限を受けない。 ITP2.1の影響 ITP2.1が本来ターゲット
最近、セッションフィクセイション脆弱性に対する関心がなぜか高まっています。同脆弱性は割合地味な脆弱性であり、話題になることはあまりありません。そこで、関心の高いこの時期に、セッションフィクセイション脆弱性の影響を受けやすいサイトについて説明し、注意を喚起したいと思います。 セッションフィクセイション脆弱性とは セッションフィクセイション（セッションIDの固定化）脆弱性は、なんらかの方法で利用者（被害者）のブラウザ上でセッションIDを強制的に指定して、その後利用者がログインしたタイミングで、攻撃者が「ログイン済みのセッションID」を知ることができるという脆弱性です。「安全なウェブサイトの作り方(改訂第五版)」P17から図を引用します。 図の「2.何らかの方法で自分が取得したセッションIDを利用者に送り込む」手法は、安全なウェブサイトの作り方では説明されていません。そこで、以下に「セッションI
なにげにしらなかったんだけど、 IEで別ドメインのiframeを読み込むと、 そのiframe内のcookieが有効にならない。 そーゆーときは、HTTPのレスポンス時リクエスト時のヘッダーに 下記のkey＆valueを出力しておけばOKらしい。 ("P3P", 'CP="CAO PSA OUR"')こーするだけで、あらふしぎ。IEがCookieを保存して意図した挙動をしてくれるじゃん。 この宣言の意味 P3P コンパクト ポリシー ヘッダーを追加し、ユーザーのデータを使用して悪質な操作が実行されないことを宣言すればCookieが有効になるみたい。Internet Explorer が適切なポリシーを検出すると、Cookie の設定が許可されます。 その、宣言の条件とは下記の３つ。 CAO サイトはユーザー自身の連絡先情報へのアクセスを提供すること PSA データはオンラインの個人に接続さ
Firefox3で「サードパーティのCookieも保存する」をオフにする。 防げる。 いずれのブラウザにもサードパーティ製のcookieを制限するオプションがあるが、Firefox3以外だと、フレーム内表示された場合に「新規にcookieを保存しない」だけで保存済みのcookieは送信してしまう。 軽く調べてみたところ、次のようになった。(間違ってたら教えてください) サードパーティのcookieの新規保存 サードパーティの保存済みcookieの送信 表示中のドメインのcookieの保存/送信 IE6,7,8(デフォルト) x o o IE6,7,8(セキュリティ高) x x x Opera9.6(デフォルト) o o o Opera9.6(制限) x △ o Safari(制限/デフォルト) x o o Safari(全て受け入れる) o o o Firefox2(デフォルト) o o
なぜPHPアプリにセキュリティホールが多いのか? 【スクリプトインジェクション対策08】自動ログインを実装しない。実装する場合は正しく実装する 自動ログイン機能は便利ですが、セキュリティ上のリスクを確実に増加させます。安全性が重要なサイトでは自動ログイン機能は実装すべきではありません。 自動ログイン機能を実装する場合、正しく実装しなければなりません。 間違った自動ログインの実装方法 セッションIDクッキーの有効期限を長くする 固定の自動ログイン鍵をクッキーに保存する 自動ログイン鍵をすべてのページで送信する 自動ログインの実装にはセッションID以外の予測不可能なランダム文字列を利用します。複数のWebブラウザから自動ログインできるようしたい場合、ユーザIDと自動ログイン鍵、その鍵の有効期限を保存したテーブルを作成して鍵を管理します。 正しい自動ログインの疑似コードは次のようになります。 /
スクリプトインジェクションや盗聴によりセッションIDを盗んで利用するまでにはある程度時間が必要です。セッションIDの有効期限が短ければ、セッションIDが悪用される前に有効期限が切れて悪用できない可能性が高くなります。 しかし、セッションIDの有効期限が短すぎると、フォームの入力中に有効期限が切れてしまう等の問題が発生します。一般的なWebサイトであれば30から60分前後で有効期限が切れるようにするとよいでしょう。 例：セッションを60分で無効化 // $_SESSION['last_update']は初期化済み if ($_SESSION['last_update'] PHPの場合、「セッションIDの有効期限切れ＝ユーザセッションの無効化」をしなくてもセッションIDを変更できるsession_regenerate_id関数が用意されています。 session_regenerate_id関
言うまでもなくログイン処理はセキュリティ上最も重要な処理です。しかし、ログイン処理が正しく行われていないサイトも少なくありません。例えば、PayPalのログインページがスクリプトインジェクションに脆弱であったことは有名です。ログインページがスクリプトインジェクションに脆弱であると、簡単にユーザ名とパスワードを盗めてしまいます。PayPalのログインページはHTTPSで保護されていましたが、スクリプトインジェクションに脆弱ではHTTPSは何の役にも立ちません。 ログインページがスクリプトインジェクションに脆弱であるのは論外であるとしても、ログインの実装方法が正しくない場合が少なくありません。ログインに成功した場合、新しいセッションIDを割り当てるべきです。これは、「セッションIDを頻繁に変更する」のエントリでも解説したように、セッションIDの盗聴や固定化などから防御するために行います。 W
2007年11月29日07:15 カテゴリ書評/画評/品評 Immortal Session の恐怖 さすがの私も、今夜半の祭りにはmaitter。 私のtwitterが荒らされていたのだ。 荒らし発言は消してしまったが、にぽたんがlogを残してくれている。 nipotumblr - Dan the cracked man 一部で言われているように、本当にパスワードが抜かれたかどうかまでは解らない。が、状況としてはnowaがベータテスト段階で持っていたCSRF脆弱性をついた荒らしにそっくりだった。 にぽたん無料案内所 - こんにちはこんにちは！！ この時も、私のnowaのメッセージに荒らしが入った。パスワードを変更しても暫く荒らしが続いていた点も似ている。 ここでの問題は、 bulkneets@twitter曰く(直接リンクは避けます) 問題は本人が気付いてもパスワード変えてもセッション残
マッシュアップ、という言葉が現れる前からSCRIPTタグを使ってブログを飾るさまざまなブログパーツがありました。最近では、アマゾンの Amazonおまかせリンク や Google Analytics のように企業が提供するツールでもHTMLの中からSCRIPTタグで読み込んで利用することが増えています。 クッキーの問題 そういったブログパーツを利用するためには、使用しているブログサービスが、エントリの本文やブログのサイドバーなどにSCRIPTタグを入れることを許可している必要があります。しかし、ページの中に任意のスクリプトを書けるようにすると、クッキーを発行するドメインを別にする等の対策をしなければ、同じブログサービスを利用しているユーザがそのページを閲覧したときに認証用のクッキーを盗み出せるようになってしまいます。 そこでSCRIPTタグを利用できるブログサービスが、このクッキー盗難問題
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く