続: そろそろUTF-7について一言いっとくか - 葉っぱ日記
史上空前のEUC-JPブームはとりあえずおいておいて、今日も最強の文字コードであるUTF-7について。 これまで私の中では、UTF-7によるXSSを避けるためには、Shift_JISやUTF-8といった、IEが受け入れ可能なcharsetをHTTPレスポンスヘッダまたは<meta>で明記してやればよいという理解でした。 具体的には、HTTPレスポンスヘッダで Content-Type: text/html; charset=Shift_JIS とするか、生成するHTML内で <meta http=equiv="Content-Type" content="text/html; charset=Shift_JIS"> とすれば、UTF-7によるXSSは防げると思っていました。ところが、後者の<meta>によるcharsetの指定では、条件によってXSSが防げないことがあるということに気付きま
IE7でもCSSのexpressionが利用可能 - cloned.log
下位互換か需要の必要性があってか、IE7でもCSSのexpressionが使える。このexpressionというのはJavaScriptが書けてしまうので、XSSの事例とかでよく題材にされる。以下のページに解かり易く書いてある。 WebAppSec - WebAppSec Wiki - IEのexpressionとurl 最新のIE6とIE7では、url内にJavaScriptを書いても反応しないようだけど、expressionは使える。XSSの話は置いておいたとしても、どういう場面で効果的なんだろうか。いまいち使い方が想像できない。
4月のマイクロソフトセキュリティ更新を確認する
マイクロソフトが、月例のセキュリティ更新プログラムとセキュリティ情報を4月12日未明に公開した。 内容は、最大深刻度が最も深刻な"緊急"のものが3つ、その次のレベルの“重要”が1つ、警告が1つ。緊急のなかの1つは、セキュリティパッチがリリースされる以前に脆弱性、その存在を証明するためのサンプルプログラム、さらに、それをもとに悪意のプログラムも作られている、非常に危険なセキュリティホール「createTextRange()問題」に対する修正も含んでいる。これは、早急、かつ確実にインストールすべきセキュリティ更新だ。ただし、この更新には「ActiveXの動作を一部変えてしまう」という問題もある。 サーバー側のWebコンテンツ側に手を入れて、このセキュリティ更新を適用した場合でも、挙動の変わらないようにする方法は、特別企画記事：「4月の月例パッチ前に、Webコンテンツを修正する 」で説明した通り
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
