IE8のXSSフィルタが裏目に出る例 - 2009-06-22 - T.Teradaの日記
IE8のXSSフィルタは、WebアプリにXSS脆弱性があったとしても、それが発動する可能性を減らしてくれるものです。 しかし、そのXSSフィルタが裏目に出るようなこともあります。 例えば、以下のような静的なHTMLファイル（test.html）を作ってWebサーバにおきます。 <h3>ie8 test</h3> <!-- 1 --> <script> var u=document.URL; </script> <!-- 2 --> <script> u=u.replace(/&/g,'&').replace(/</g,'<'); </script> <!-- 3 --> <script> document.write('URL:'+u); </script> 上のページは静的なページで、DOM Based XSSの脆弱性もありません。ですが、被害者のユーザがIE8を使っている
JavaScript Hijack/JSON Hijackのぜい弱性
今回で，ratproxyで検出できる特徴的なぜい弱性の解説は終わりです。最終回となる今回は，JavaScript Hijackについてです。JavaScript Hijack，そしてJSON Hijackは，JavaScriptファイルやJSONデータ内に含まれる情報を盗む攻撃です。ratproxyは，この攻撃を成立させてしまうぜい弱性を見付けやすくなっています。 JavaScript Hijack まず最初にJavaScript Hijackについて説明しましょう。JavaScript Hijack攻撃にぜい弱になるのは，個人情報などの機密情報を内容として含むJavaScriptファイルを動的に生成しているアプリケーションです。筆者が過去の検査で実際に見たケースには，以下のようなものがありました。 （index.htmlの一部） <script src="greeting.cgi"></
JavaScriptスクリプトに潜むXSSのぜい弱性も検出
今回は，ratproxyが検出する特徴的なぜい弱性として，JavaScript関数に関するものを紹介しましょう。DOM（document object model）の仕組みを使ったクロスサイト・スクリプティング（XSS）のぜい弱性（DOM Based XSS）です。 DOM Based XSSは，XSSの中では比較的新しいタイプのぜい弱性で，業界団体のサイトなどで紹介されています。ここでは詳細な説明は割愛しますが，簡単に言うと，Webサーバーを経由させずに標的ユーザーのブラウザ上で悪意あるスクリプトを実行させられるぜい弱性です。 ぜい弱性のある簡単なサンプルJavaScriptコードを以下に示します。これは，かつてBugzillaで発見されたぜい弱性です。 このコードでは，locationがそのまま（エスケープされずに）HTMLに出力されています。そのため，locationに「<scrip
[セキュリティ]javascript://のXSS 00:17 - 2008-07-30 - T.Teradaの日記
こんな場合、普通はjavascriptやdataスキームなどを使ってXSSさせるのでしょう。 <a href="ここにHTMLエンコードされて入る">link</a> しかし、このアプリは「javascript://...」のように、先頭からアルファベット数文字が続き、その直後に「://」が付いている値以外は、エラーではじいてしまいます。 この「:」のあとの「//」が曲者です。 dataスキーマを試してみましたが、「//」があるとどうやらダメらしいということで、javascriptスキームで頑張ってみます。 まずはこんな感じです。 <a href="javascript://hoge[0x0A]alert(111)">link</a> 「//」が行コメントの開始になるため、[0x0A]（LF）や[0x0D][0x0A]（CRLF）を入れてみて、その後に動かしたいJavaScriptコードを
![[セキュリティ]javascript://のXSS 00:17 - 2008-07-30 - T.Teradaの日記](https://cdn-ak-scissors.b.st-hatena.com/image/square/3ce21f422dafba32f7c257ef3ed09227bfdd2c5e/height=288;version=1;width=512/https%3A%2F%2Fogimage.blog.st-hatena.com%2F10257846132711010800%2F10257846132711092219%2F1548045373)
入力値検証の話 - T.Teradaの日記 - 2007-09-08
Webアプリケーションのセキュリティ対策としての入力値検証について議論されています。 そろそろ入力値検証に関して一言いっとくか: Webアプリケーション脆弱性対策としての入力値検証について - 徳丸浩の日記(2007-09-05) 思ったことをいくつか書きます。 徳丸さんの日記は、ユーザがテキストボックスなどで自由に値を入力できる住所などのデータを主に対象としたものだと思う。 ただ、ユーザの自由な入力を起源としないデータも存在する（ここでは「システム起源のデータ」と呼ぶ）。 hidden、リンクURLに埋め込まれているGETパラメータ、Cookieなどには、この手のデータが入ることが多い。 システム起源のデータの多くは、ある型に従うことが期待されるもので、原則的に入力値検証をすべきもの（BMPの「ピクセルあたりビット数」と同じような感覚）。 システム起源のデータも、エスケープさえすればイン
T.Teradaの日記 HTML Purifierを試した
Webメールでは、受信したHTMLメールのタグを残して、クライアントサイドスクリプト（JavaScriptなど）のみを除去するサニタイズ処理を行ないます。 このようなスクリプト除去処理は、Blog、掲示板などでも行なわれる、比較的ポピュラーなものであるため、それ用のライブラリがいくつか存在します*1。 HTML Purifierもその一つです。PHP4/5で動作します。バージョン1.0.0のリリースは2006年9月ですから、比較的新しいものです。私は昨年末に初めて触ってみました（バージョン1.3.2です）。 これまでのものと比べて、非常によく出来ているなと思いましたので、日記に書いてみます。 HTML Purifierの概要 特徴としては、以下が挙げられると思います。 ユニコード対応 UTF-8のHTMLに対応（既存のライブラリの多くはlatin1を暗黙の前提としていました）。EUC-JP
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
