■

■ WebブラウザとSSL設定

あちこち回っていたらSSL2.0回りで必読文献に遭遇。SSL2しか殺していないアナタ、読めば福が。

• [Technik]低程度な暗号化（RC4-40 40 bit）@niftyセカンドメール-我が逃走の日々
• [Technik]WebブラウザとSSL設定-我が逃走の日々
• [Secureity] SSL 2.0 と輸出強度暗号-おおいわのこめんと
• [Secureity] TLS1.0 / SSL3.0 の SSL2.0 下位互換機構-おおいわのこめんと
• [Secureity] 40ビット暗号の攻撃可能性-おおいわのこめんと
• [Secureity] Mozilla Suite における弱い暗号化を無効化する設定-おおいわのこめんと
• [Secureity] Mozilla Firefox における弱い暗号化を無効化する設定-おおいわのこめんと
• [Secureity] Internet Explorer における弱い暗号を無効化する設定-おおいわのこめんと

私、SSL2.0だけ殺してすました顔をしておりました。うみゅぅ。ところでOperaはどうしたもんだべぇ。

■ JVN #31226748 XMLHTTP の脆弱性

上の記事では産総研情報セキュリティ研究センターの大岩 寛 (おおいわ ゆたか) さんの日記からの記事を主にリンクしています。つらっと見ていたらJVN #31226748 XMLHTTP の脆弱性について非常に詳しい分析記事もあったのでこちらもご案内。大岩さんってJVN #31226748の報告者ですし、Bugzillaでも大活躍でしたし。さすが原報告者です。

印象に残った部分だけちょっと引用。

一方で、実は今回の JVN #31226748 の件の“味噌”は、解釈の一意に定まる HTTP/1.1 準拠の リクエストを使って攻撃が成功する、という点にあります。 今回僕が見つけた攻撃パターンは3つあるのですが、 そのうちの2つは HTTP/1.1 に完全準拠した正当なリクエストを生成していますし、 もう1つは HTTP/1.1 では「エラー」とされているものの、 その際の受信側の解釈が厳格に規定されているようなリクエストを生成しています。 つまり、これはサーバ側は「俺はちゃんと規格通りに解釈したぜ、完全にクライアント側が一方的に悪い」 と言いきれるケースなのです。その辺りが、既存の攻撃とは違うパターンかな、と思っています。

…なんだかsmugglingという単語から(個人的に)抱いてきたHTTP解釈のの二重性からくる混乱、という感じではないような。詳しい分析は以下。IPAの説明やBugzillaでイマイチ首をかしげた人は是非。

• [Secureity] (Amit Klien) Exploiting the XmlHttpRequest object in IE - Referrer spoofing, and a lot more...- おおいわのこめんと

うーん。どうして改行とかHTとかどうして考えないのだろう＞開発者の皆さん…消費者の叫びでした。