第10回 スクリプトインジェクションが無くならない10の理由 | gihyo.jp
SQLインジェクション対策は非常に簡単です。しかしブラウザに対する「スクリプトインジェクション」はなかなか無くなりません。スクリプトインジェクションが無くならない10の理由をあげてみます。 複雑な攻撃経路と対策 前回紹介したように、ブラウザに対するスクリプトインジェクション攻撃の経路は3種類あります。エスケープ方法も数種類あります。すべての出力を完全にエスケープできればセキュリティ維持も容易になりますが、タグや属性を出力したい場合もあるため、必ずしもすべての出力をエスケープできるわけではありません。さらに攻撃手法にも、サイトをまたがった攻撃、直接攻撃、間接攻撃などパターンがあります。エスケープできないデータへの不正なスクリプトの挿入を防ぐには、データの起源までさかのぼり安全性を確保しなければなりません。ブラウザに対するスクリプトインジェクション対策はデータベースサーバへのSQLインジェクシ
サイト脆弱性をチェックしよう！--第5回：XSSの脆弱性を検査する方法
印刷する メールで送る テキスト HTML 電子書籍 PDF ダウンロード テキスト 電子書籍 PDF クリップした記事をMyページから読むことができます 前回までは安全なウェブアプリケーションを作成する手法をいくつか説明してきた。今回からは代表的な脆弱性についての検査方法を説明していきたい。まずは、クロスサイトスクリプティング（XSS）の脆弱性について、その検査方法を紹介する。 XSSとは、入力として受け取ったデータに含まれている「Javascript」などのスクリプトやタグが、それらが有効な形で出力（HTTPレスポンス）に含まれているために、ブラウザが意図しない動作や表示を行ってしまう脆弱性だ。 この脆弱性を使った攻撃の被害者はサイトを利用している利用者であり、サイトが直接的な被害に遭うことはない。この脆弱性を利用すると、攻撃者が意図した通りにブラウザをコントロールすること（たとえば、
Kazuho@Cybozu Labs: E4X-XSS 脆弱性について
« 安全な JSON, 危険な JSON (Cross-site Including?) | メイン | JSONP - データ提供者側のセキュリティについて » 2007年01月10日 E4X-XSS 脆弱性について Firefox でサポートされている JavaScript 拡張 E4X (ECMA-357) では、JavaScript 内に XML とほぼ同様のマークアップ言語を記述できるようになっています。しかし、マークアップ言語の解釈にはいくつかの違いがあり、この点をついたクロスサイトスクリプティングの可能性が (相当に小さいものの) 存在します。攻撃者は、 ウェブアプリケーションに E4X として解釈した場合に実行コードとして解釈されるコードを注入 (XSS) し、 1 のコンテンツを <script> タグを用いて参照するような別のウェブサイトを用意し、攻撃対象にアクセスさせ
yohgaki's blog - いろいろ変わったXSSがありますが...
(Last Updated On: 2007年10月12日)私が知らなかっただけかもしれませんが、これにはかなり驚きました。いろんな所で問題が指摘されていますが、ECMAScriptにXML機能を追加したのはどうなんでしょうね…. 確かにかなり便利なのですが以下のコードでスクリプトが実行されることはほとんど知られていないでしょうね。 <script> 123[”+<_>ev</_>+<_>al</_>](”+<_>aler</_>+<_>t</_>+<_>(1)</_>); </script> 好むと好まざる関係なくFirefox 1.5から使えるのでWeb開発者は知っておかなればならないです。 日本語訳 http://www.ne.jp/asahi/nanto/moon/specs/ecma-357.html 原文 http://www.ecma-international.org/pu
JavaScriptエスケープについて論考 - hoshikuzu | star_dust の書斎
http://d.hatena.ne.jp/hoshikuzu/20060130#P20060130BARSFAKE http://d.hatena.ne.jp/amachang/20071010/1192012056 (IT戦記 - 一行で IE の JavaScript を高速化する方法) はじめに 次のような限定されたケースにおいてなのですが。説明上の都合でこれを課題Ａと呼ぶこととします。 <SCRIPT TYPE="text/javascript"> <!-- var strA = "$data"; // ・・・以下サイト運営者による処理記述例 alert(0); //--> </SCRIPT>上記のようなケースに限定してのオハナシですけれど、$dataをエスケープする方向でのXSS対策として金床さんなどによってかつて論議されて、このままでは使えそうにないと棄却されたJavaScr
第8回 Wikiのセキュリティ | gihyo.jp
○:実行される ×:実行されない (バージョンは執筆時点での最新版, OSはWindows XP) ご覧のとおり、ブラウザによって異なる結果になっています。HTMLの構文解析はブラウザによって解釈の異なる部分もあるため、解析しきれないというのが現実です。また、今後各ブラウザがいつ仕様変更されるかもわかりません。 次に以下をご覧ください。攻撃者は以下のようなHTMLを挿入してくることが考えられます。 <H2/onmouseover=alert('xss')>見出し</H2> <H2 onmouseover=alert('xss')>見出し</H2> <H2 style="{javascript:expression(alert('xss'))}">見出し</H2> <H2 style="{a:expression(alert('xss'))}">見出し</H2> <H2 style="{ja
2007-09-28
≪某メジャーなブラウザには既知既存のブラックリストに載っていないXSSベクターが存在しており、報告したので開発陣担当者には知られているはずと期待しているが、修正がはいらず１年近く放置されてる。≫という状況を伝え聞きました。私には詳細もPoCもわかりませんけれども、相当な危険物とのこと、聞いています。ブラックリスト方式でXSSを回避するシステムは要注意です。 JavaScriptオフでブラウジングしましょう。なんとかしる→各方面！ 以上、義憤を感じて書いてみました。 便利。 http://0xcc.net/blog/archives/000184.html http://www.macchiato.com/unicode/chart/
もいちどイチから！ HTTP基礎訓練中 第1回 XSSは知ってても、それだけじゃ困ります？ ― ＠IT
分かってるつもりではあるけれど…… クウはベンチャー企業で働くWebアプリケーションのエンジニア。でもそこは小さなベンチャー企業、セキュリティのことは分かっていながらも、動くものを納品するので精いっぱい……。今日は納品のため、客先でミーティングに参加していた。そしてお客様から受けた指摘は、こんな一言だった。 お客さん 「……で、このWebアプリケーション、セキュリティは大丈夫なんだよね？」 クウ 「は、はいっ！ もちろんです！」 お客さん 「じゃあ、これからもよろしく頼むよ」 クウ、ユウヤ 「よろしくお願いしますっ！」 無事、お客さんとのミーティングを終えたクウとユウヤの2人は、近くの喫茶店で一息いれることにした。 クウ 「最近はセキュリティのことを聞かれることがかなり増えてきましたねぇ」 ユウヤ 「ああ、そうだね。営業の段階から『セキュリティはどう担保されているんだ？』なーんてことをいわ
Perlを使って脆弱性を検証する：CodeZine
はじめに 今回はXSSの脆弱性をチェックするPerlスクリプトを作成したいと思います。すべてのXSSによる脆弱性が回避できるわけではありませんが、テストコード作成のヒントになれば幸いです。 対象読者 Webアプリケーション開発者で、XSSのテストケースを作成したい方。 必要な環境 Perl 5.8以上が動作する環境。基本動作の確認はMac OS Xを利用しました。次のPerlモジュールを利用するので、あらかじめインストールしておいてください。 Template::Toolkit Web::Scraper Test::Base またCGIを使用するので、ApacheなどのCGIが実行できるWebサーバを用意してください。 解説内容 ソースコード解説 まず最初にソースコードの解説をします。 xss.pl
"週"記(2007-09-07)
_ [webappsec] 徳丸浩の日記 - そろそろ入力値検証に関して一言いっとくか - Webアプリケーション脆弱性対策としての入力値検証について とてもよくまとまってると思います。では、現状はどうなのか、というのを過去〜最近の経験から。 「住所欄や掲示板への投稿本文欄など、実質的に文字種を制限できない」値に対してはエスケープするなど正しく実装されてることが多いです。それが要件として明記されているのか、単にエスケープしないとデータが壊れるからか、プログラマが意図的に行っているのか、理由はよくわからないですけど。 問題がよく見つかるのは、「電話番号とか、価格とか、メールアドレスのように文字種や桁数などが限定される」値や、もっと値が限定できるはずの「hidden値やselectboxで選択された値」の方だったりします。 なので、次は何に注意して開発をすればいいかと聞かれたら、(当たり前の)
セキュリティ専門家、Web 2.0サイトの危険性を指摘--LinuxWorldにて
米国時間8月7日に開催されたLinuxWorldで、SPI DynamicのシニアセキュリティエンジニアMatt Fisher氏は、Web 2.0の脆弱性に関して演説した。Black Hatにて、同僚のBilly Hoffman氏およびBrian Sullivan氏が先週指摘した点と大きく変わらないものの、Fisher氏の演説では、ただのデスクトップブラウザのようなツールのみを用いて、犯罪者がオンラインで何をなし得るのか、複数の新たな例が紹介された。非営利団体MITREによると、容易に仕掛けられるということもあり、クロスサイトスクリプティング攻撃が、現在最大の脅威となっている。 Fisher氏は特に、ソーシャルネットワーキングサイト（SNS）の危険性を指摘した。SNSはユーザーコンテンツで成り立っているため、ユーザーがHTMLコードを自由にアップロードできてしまう。しかもほとんどのケースで
「クロスサイトスクリプティング対策の落とし穴」へのツッコミ - 猫と重金属？技術系
はじめに クロスサイトスクリプティング対策の落とし穴 この記事を数十人の人がブックマークしていたものの あまりに酷い内容なのでちょっと辛辣なコメントでのブックマークを残してみたのですが、その後もこの記事への（付けられているタグを見る限り肯定的な）ブックマークは止まず。これはちょっとはっきり問題点を指摘した方がいいかな…と思ってこうした記事を書く次第。 ツッコミ開始 典型的な例は，「テキストを出力する前に"<"と">"を取り除く」方法があります。 そんなの「典型的」ではありません。どう考えてもhtmlspecialchars等でエスケープするほうが「典型的」です。変な「典型的」を捏造しないで下さい。 「<」「>」を絶対に使わないような箇所（例えば郵便番号とか）ならば取り除いても良いでしょうが、一般論としては、「<」「>」という文字をプログラマが自分の都合で勝手に取り除く事は許されません。「>
TwitterのXSS対策は変だ: Twitterのクロスサイト・スクリプティング(XSS)対策は変だ - 徳丸浩の日記(2007-08-29)
_ Twitterのクロスサイト・スクリプティング(XSS)対策は変だ Twitterが流行している。私もヘビーユーザとは言えないものの、結構愛用している(http://twitter.com/ockeghem)。このTwitterのXSS対策が変だなと思う事象があったので報告する。 あらかじめお断りしておくが、TwitterにXSS脆弱性がある(実際にはあったようだが)という報告ではなく、対策の方法がおかしいという報告である。 まずは、どうも変だと思うようになった事例を紹介する。 事例1 モバイル版の二重エスケイプ 私は主に、通勤などの移動中に、W-Zero3で閲覧・書き込みしている。モバイル版(http://m.twitter.com/)を主に利用しているが、「<」などの記号が二重にエスケープされていることに気がついた。 twitter.comでの表示 m.twitter.comでの表
アンチ「サニタイびんぷ」: 画像版サニタイズ言うな(2) - 徳丸浩の日記(2007-08-21)
_ 画像版サニタイズ言うな(2) 前回のエントリーの後、mod_imagefightのコマンドライン版を作ったりして、検証してみました。まだ検証途中ですが、今回はBMP形式についてのアンチmod_imagefightについて紹介します。 まず、BMP形式のヘッダは以下のようになります(カッコ内はバイト数)。 0000:MARK(2) ='BM' 0002:ファイルサイズ(4) 0006:予約1(2) =0 0008:予約2(2) =0 000A:ビットマップ開始位置(4) 000E:ヘッダサイズ(4) =0x28 0012:イメージ横幅(4) 0016:イメージ高さ(4) 001A:プレーン数(2) =1 001C:ピクセルあたりのビット数(2) 1,4,8,24 001E:圧縮形式(4) =0,1 0022:圧縮後のイメージサイズ 0026:水平解像度(4) 002A:垂直解像度(4)
第8回 クロスサイトスクリプティング対策の落とし穴 | gihyo.jp
今回は熟練したWebアプリ開発者なら常識のクロスサイトスクリプティング対策の落とし穴を紹介します。 JavaScriptを排除しているつもりで排除に失敗？！ 最近はSanitize（サニタイズ）という言葉の代わりにValidation（検証）という言葉をよく聞くようになったと思います。Sanitizeの意味を辞書で調べると「汚れている物をきれいにすること」とされています。この意味の通り汚れた変数をきれいにして使えば安全に利用できるとする考え方に基づくのがサニタイズ手法です。典型的な例は、「テキストを出力する前に"<"と">"を取り除く」方法があります。 例1 "<"と">"をereg_replaceで取り除く $safe_text = ereg_replace($_GET['text'], '[<>]', ''); この$safe_textを <a href="/script.php?t
HTML::StripScriptsでXSS対策をする - Kentaro Kuribayashi's blog
先日公開した「はて☆すたアンケート」にて、アンケートの説明文をはてな記法で書けるよう、機能追加を行った。その際、Template::Plugin::Hatenaを用いた。これは、はてな記法パーサであるText::Hatena（正確には、そのヴァージョン0.16以下）を、Template::Toolkitのプラグインとして使えるようにしたものである。 はてな記法は、それ自体で全ての文書構造を表現できる、あるいは、はてなダイアリのシステム自体は、はてな記法のみしか許容しないというものではなく、たとえば画像を貼る際には、普通にimg要素を書く必要があるし、また、その他の要素についても、記法が用意されていないものについては、「はてなダイアリーのヘルプ - はてなダイアリー利用可能タグ」に掲載されているものに限り、自分でタグを書くことができる。これは自由度を高める反面で、XSSを誘発し得る潜在的なリ
Atom や RDF を利用したXSS - 葉っぱ日記
Internet Explorer の悪名高い Content-Type: 無視という仕様を利用すると、Atom や RDF/RSS を利用してXSSを発生できることがあります。条件的に対象となるWebアプリケーションは多くはないと思いますが、それでもいくつか該当するWebアプリケーションが実在することを確認しました。以下の例では Atom の場合について書いていますが RDF/RSS でも同様です。 例えば、http://example.com/search.cgi?output=atom&q=abcd という URL にアクセスすると、「abcd」という文字列の検索結果を Atom として返すCGIがあったとします。 GET /search.cgi?output=atom&q=abcd Host: example.com HTTP/1.1 200 OK Content-Type: ap
XSSワームが増加、高度化の傾向
McAfeeによると、クロスサイトスクリプティング（XSS）の脆弱性を突いて4大Webメールに感染するコンセプト実証ワームも出現しているという。 Webアプリケーションのクロスサイトスクリプティング（XSS）の脆弱性を突いたワームが増加し、高度化の一途をたどっているという。セキュリティ企業のMcAfeeが7月19日のブログで報告した。 McAfeeによると、XSSワームは古くは2002年に話題になったことがある。これは、Hotmailに存在するというXSSの脆弱性を悪用すれば、感染したユーザーのアドレス帳に登録された全員に電子メールを送信できるというものだった。 この種のワームは2006年になって増加し、WikiやYahoo! MailといったWebサイトのXSS脆弱性を突いた「Samy」「Yamanner」などのワームが出現。WebページのXSSの脆弱性を探し出す自動ツールも登場している
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
http://megalodon.jp/new/xss.html
http://barmagy.com/blogs/infinite_loop/archive/2007/07/20/498.aspx