InfoQ

News

インターネットエクスプローラのクッキーのリミットが50に増加

作者 Gavin Terrill, 翻訳者 編集部 投稿日 2007年9月4日 午前3時29分

コミュニティ
Architecture
トピック
JavaScript,
セキュリティ
タグ
Internet Explorer,
Firefox
マイクロソフトは一つのドメインごとに許容するクッキーの数をFireFoxと同等の20から50に増加した。マイクロソフトでプログラムマネージャを務め、Fiddler HTTPデバギングプロキシの仕掛け人であるEric Lawrenceがこのリリースについて語った
過去にIEのクッキージャーは一つのドメインにつき最大で20のクッキーを保存した。もしサーバーから20以上のクッキーが送られてきたら古いクッキーはブラウザによって自動的に排除されていた。排除されたクッキーはウェブサイトの設定を消去したり、ショッピングバスケットを空にしたりといった問題を引き 起こしていた。
その20のクッキーリミットはNetscapeの予備仕様書"Client Side State-HTTP Cookies”にまで遡る。このInternet Explorerにおけるクッキーの増加は一見それが向上したように聞こえる一方、増加したリクエストサイズと遅くなったアップロードスピードを考慮に入れるとパフォーマンス性に関する重大な問題が出てくる。
不幸にもクッキーはドラマチックなほどにHTTPリクエストのサイズに影響を与える。というのもユーザー達のブラウズを大幅に遅らせてしまうのだ。たくさ んのWebユーザが非対称型帯域幅を用いて2倍から5倍のアップロードスピードでダウンロードを行っている。これはいくつかの場合でHTTPのリクエス トサイズは全体的な移行の時間を考慮したときサーバのレスポンスのサイズよりも重要な要因となるということだ。
Ericはこれらの問題に対応する3つの方法を述べている。
  1. 自分のクッキーのサイズを最小限にすること 例えばより短い変数を使用する
  2. 異なるドメインから静的なコンテンツを取り入れること そうすればクッキーはリクエスト内には送り込まれない
  3. 自分のクッキーのサイズを最小限に抑えることパスによってクッキーを制限するところである
最後の方法はただ一つのドメインで実行できるということを省いたら2つ目のものに似ている。もし1つのパス内でクッキーにアクセスを必要とする全てのペー ジを維持することができれば、パス内のリクエストだけに送られるべきクッキーを特定するパスの特性を利用することができる。これはパス以外から送られたリクエストが、不必要なクッキーを運ばないように強制するようにするのだ。
アタックを和らげるためのクライアント側のスクリプトからのクッキーアクセスを制限することを提案している。
もし自分のクッキーが自分のサーバーだけに使われ、スクリプトがクッキーへのアクセスを必要としなければ、クロスサイトスクリプティングアタックによるクッキー泥棒からサーバーを守るためにはHttpOnlyアトリビュートを使用すればいい。
HttpOnly特性はインターネットエクスプローラ6SP1にて取り入れられている。またそれはFirefox 3にてサポートされる予定で、現在Firefox Add-Onとして入手可能となっている。
ブックマーク
digg+,
reddit+,
del.icio.us+,
dzone+,
Hatena

No comments

返信

特集コンテンツ一覧

トップスポーツチームの監督に教わる秘訣

この論文では、氏が発見した原則を要約し、その原則をいかにしてソフトウェア開発に応用するかを説明します。

事例研究:Dutch Railwaysのプロジェクトにおける分散拠点でのスクラム・プロジェクト

この記事では、私達がどのようにして大規模(240人月、10万行強)でインドとオランダの開発者も参加したスクラム・プロジェクトを成功させたのかを示しています。

Agile2008チーム参加レポート - 帰国そして変化

Agileカンファレンスに「参加者としてだけでなく、発表者として参加しよう」を掲げたチームgoyattomは、サブミッションを提出し、7つのセッションが日本から選択されました。参加者はカンファレンスで各々の発表や、各セッションへの参加、諸外国のエンジニアとの出会い、ステージ上で DearXPを熱演などの様々な思い出を抱えて、無事日本に戻ってきました。

SilverlightとJavaのインターオペラビリティ

マイクロソフトのRobert Bellが、SilverlightとJavaを使用したインターオペラビリティのシナリオを紹介し、サンプルコードを例にとってアーキテクチャの手引きを提供します。

Agile2008 チーム参加レポート - カンファレンス参加編

Agileカンファレンスに「参加者としてだけでなく、発表者として参加しよう」を掲げたチームgoyattomは、サブミッションを提出し、7つのセッションが日本から選択されました。サブミッションが選択された人、そうでない人も含めて、個々の目的意識の確認、膨大なプログラムから聞きたいセッションの選択、旅行の準備、プレゼンテーションの準備の期間を終えて、無事当日を迎えました。

Agile2008 チーム参加レポート - 動機/準備編

筆者はアジャイルソフトウェア開発についての年に一度の国際会議であるAgile2008に初めて参加してきました。今年の日本からの参加者の数は14名にも及び、発表者は5名、受け持ったセッションは8つに及び、例年にない活躍を見せました。なぜ今年のAgile2008では、これほど多くの日本人が参加し発表に至ったのか? そのレポートをお届けします。

Javaトラブルシューティングメルマガ総集編 2008/08~09

エスエムジーでは、Java全般を対象にしたトラブルシューティングサービス「JaTS」を提供しています。この記事では、前回に引き続き、JaTSにて蓄積したトラブル事例とその解決ノウハウの一部をお送りしている「Javaトラブルシューティングメールマガジン」(JTSMM)の総集編として、過去2ヶ月のトラブル事例と追加情報をダイジェストとして提供いたします。

モデル駆動アプローチがうまく機能しない(しなくなる)8 つの理由

この記事では、モデル駆動アプローチがうまく機能しない、または機能しなくなることによって期待した結果が実現できなくなる 8 つの理由について書きたいと思います。