そのやり方でクロスサイトスクリプティング対策は完全ですか？
何かと物騒なニュースの多いWebアプリケーションのセキュリティ。 特にクロスサイトスクリプティング脆弱性（以下「クロスサイトスクリプティング」といいます）は、対策が難しいだけでなく、セッションハイジャックなどを組み合わせることで他のユーザーの情報を得られるなど攻撃者にとっての メリットも大きく、攻撃は増加の一途をたどっています。 クロスサイトスクリプティングとは？ クロスサイトスクリプティングとは、悪意のあるコードがWebサイトの訪問者のブラウザに送られてしまう脆弱性のことをいいます。 クロスサイトスクリプティング自体でも、ブラウザを強制的に停止させるなどの実害を訪問者に与えることができますが、もっと怖いことは、訪問者のクッキーなどを盗み出し、 ログイン状態を擬似的に作り出して、個人情報やクレジットカード番号など、重要な情報が盗まれる可能性があるという事実です。 プログラマがしっかりすれば
JavaScript のリテラルに任意の文字列を出力してみる | 水無月ばけらのえび日記
更新: 2008年1月27日 Web アプリケーションのセキュリティガイドラインには、たいていの場合「スクリプト内に動的生成の文字列などを出力してはならない」という掟があったりするのですが、それにあえて背く場合のお話。 こんな感じの HTML 断片があったとします。 <script type="text/javascript"> <!-- foo.bar = <%= value %>; //--> </script> そして、この「<%= value %>」の部分に、ユーザが検索文字列として入力した任意の値を入れるというのが課題です。もちろん、そのまま出力すると XSS であっさり死亡するので、何らかの処理をしてから出力する必要があります。ちなみに、ユーザが何を入力したのか正確に知りたいので、任意の文字を削除したりすることはできない (削除してしまうと仕様を満たせない) と考えてください。
文字コードとXSS - おおいわのこめんと(2005-12-26)
■ [Security] 文字コードとXSS (書きかけ) 例によってセキュリティホールmemoより。厄介ですねぇ……。 キチンと全文書に文字コード指定をしておく マイナーな文字コードで送信するときは、対応環境と影響を考えておく。 不安なら ASCII 完全上位互換の文字コード (ASCII の有効バイトは常に ASCII と同じ意味を持つ EUC-JP、UTF-8 など) を使う。 cross-site injection で META が埋め込めるとかは論外。 位は比較的簡単だし、やっておかないといけないかな。 で、ちょっと気になっているのとしては、とりあえず、UTF-7 はやばやばなのは明らかとして、 ISO-2022-* への派生している議論はちょっとずれている気がしている。 とりあえず、 Bugzilla.jp の 4868: ASCIIと互換性のない文字コードはユーザーの指定で
2008-01-18 - hoshikuzu | star_dust dairy - about UTF-7 XSS Cheat Sheet
おくればせながら下記を拝見しました。 UTF-7 XSS Cheat Sheet Specify charset clearly (HTTP header is recommended) Don't place the text attacker can control before <meta> Specify recognizable charset name by browser. 上記のような対策を必要とするサイトでは放置しておけばUTF-7系のXSS以外でもXSSの危険性は存在しうると思われます。ですので… あと、ヤマガタさんの反応を読みながら思ったんですが、一般的なXSS対策で「<」「>」などを「<」「>」にエスケープするように、機械的に「+」を「+」にエスケープしてやれば、万が一のときでもUTF-7によるXSSを防げるような気もしたんですけど、あまり深く
UTF-7によるXSSからの防御方法 - 葉っぱ日記
たぶん UTF-7 XSS Cheat Sheet を読んだ人の感想: http://twitter.com/nyaxt/statuses/596330132より 残念ながら違います。伝え方がヘタクソでごめんなさい。 UTF-7によるXSSを防ぐには、以下の対策をとれば大丈夫です。 文字エンコーディング(charset)を明示する(できればHTTPレスポンスヘッダがよい) HTTPレスポンスヘッダではなく、<meta> で指定する場合には、<meta> より前に攻撃者がコントロール可能な文字列をおかない 指定する文字エンコーディング名は、ブラウザが確実に認識できる名称とする この3点を守っている限り、UTF-7を利用したXSSは発生しません。 iframeを使用するのは、攻撃者の作成した罠ページです。ターゲットとなるページのcharsetが不明瞭な場合、罠ページ内でターゲットとなるページを
a threadless kite - 糸の切れた凧
ここは、管理人yamagataが方針未定のまま、何となーく思いついたことを思いついたままにだらだらと書き付ける日記帳です。ふんわりほんわかな感じでお願いします。
UTF-7 XSS Cheat Sheet
Countermeasures against XSS with UTF-7 are: Specify charset clearly (HTTP header is recommended) Don't place the text attacker can control before <meta> Specify recognizable charset name by browser. For more information about UTF-7 trick, see "Cross-site scripthing with UTF-7". These XSS patterns are tested on IE6 and IE7. Yosuke HASEGAWA <hasegawa@openmya.hacker.jp> Last modified: 2008-01
Merry XssMas – hackademix.net
Looks like 2007 improved XSS awareness in the “mainstream” media outlets too. The Register recently published a report about the Orkut XSS worm. It’s not the first time, here’s a list of XSS worms and some already hit The Register‘s columns, but the level of understanding is visibly getting better. This is clearly good, because XSS worms are becoming more and more common. While at this moment we c
2007年のクロスサイトスクリプティングを振り返って - 葉っぱ日記
最近あちこちで「日記書くのサボってるよね」とか言われたので、サボってるわけじゃなくって書くネタがないだけだけど、無理やり2007年のXSSを振り返ってみるというネタで書いてみます。以下、著名サイトで見つけたXSSです。 産業技術総合研究所のXSS 404応答のページにてcharsetの指定がないため、UTF-7を利用したXSSが可能でした。ただし、ページ中に日本語を含むため、CVE-2007-1114を利用しIE7にてUTF-7で書かれたiframeを経由した場合のみXSS可能でした。ですので、実際の脅威にはつながりにくいと思います。届出:2007年4月11日、修正完了:2007年6月5日 sourceforge.jpにおけるXSS cvs.sourceforge.jpにおける404応答のページにてcharsetの指定がないため、UTF-7によるXSSが可能でした。ログインした状態ではセッ
JVNDB-2007-000820 - JVN iPedia - 脆弱性対策情報データベース
Google が提供する Google Web Toolkit（GWT）には、クロスサイトスクリプティングの脆弱性が存在します。 Google が提供する Google Web Toolkit（GWT）は、Ajax アプリケーションを Java ベースの環境で開発するためのオープンソースのフレームワークです。 Google Web Toolkit の benchmark reporting system には、クロスサイトスクリプティングの脆弱性が存在します。 この脆弱性情報は、情報セキュリティ早期警戒パートナーシップに基づき下記の方が IPA に報告し、JPCERT/CC がベンダとの調整を行いました。 報告者：株式会社セキュアスカイ・テクノロジー 福森 大喜 氏
"週"記(2007-12-15)
_ [webappsec] </xssed> Domain: devnull.jp （blueタン、thanks!!） tDiary の category.rb に問題があるみたい。 他のサイトにも影響があるだろうということでblueタンがIPAにも通報してくれて、開発者も認識済みらしいので、近々正式に対策されたものが出てくるでしょう。 ちなみに自分のところはどうしてるかというと、自分でちょっといじってしまいました。本質的な対策じゃないけど、参考にどうぞ。 --- category.rb.old 2007-12-14 17:50:24.000000000 +0900 +++ category.rb 2007-12-14 17:51:27.000000000 +0900 @@ -339,7 +339,7 @@ @mode = :all end - if /\d{4}/ === @year.t
サイボウズの複数製品にXSSなど4件の脆弱性
サイボウズのグループウェアなどに、クロスサイトスクリプティング（XSS）、HTTPヘッダインジェクションなど4件の脆弱性が発見された。 情報処理推進機構(IPA)セキュリティセンターとJPCERTコーディネーションセンター(JPCERT/CC)は12月11日、サイボウズのグループウェア「サイボウズ Office」などにクロスサイトスクリプティングなど4件の脆弱性が発見されたとして、JVN(Japan Vulnerability Notes)に情報を公開した。 発見された脆弱性は、クロスサイトスクリプティング（XSS）に関する2件とHTTPヘッダインジェクション1件、DoS（サービス妨害）1件の計4件。対象製品は「サイボウズ Office」「サイボウズ ガルーン」などで、製品によっては複数の脆弱性が見つかっている。CVSSによる脆弱性の深刻度は4.3で、いずれも警告レベル。 Office 6
画像ファイルによるクロスサイト・スクリプティング(XSS)傾向と対策
補足 この記事は旧徳丸浩の日記からの転載です（元URL、アーカイブ、はてなブックマーク1、はてなブックマーク2）。 備忘のため転載いたしますが、この記事は2007年12月6日に公開されたもので、当時の徳丸の考えを示すものを、基本的に内容を変更せずにそのまま転載するものです。 補足終わり 最近、画像ファイルを用いたクロスサイト・スクリプティングが注目されている。本稿では、画像を悪用したXSSについて説明した後、対策方法について解説する。 画像によるXSSとはどのようなものか Internet Explorer(IE)の特性として、コンテンツの種類を判別する際に、レスポンスヘッダ内のContent-Typeだけでなく、コンテンツの内容も判断基準にしている。このため、Content-Typeが例えばimage/gif(GIF画像)となっていても、中身がHTMLであればHTMLと解釈して表示する。
イメージコピー版イメージファイト: うまく動いてないようですが - 徳丸浩の日記(2007-12-06)
_うまく動いてないようですが cybertさんのブログから IE仕様？をついた画像ファイルを使用したXSSというのがあります。なかなか決定的な対策がなく、私も困っています。画像の再コンバートとか、画像のファイルヘッダを確認するのも。コメントとかカラーパレットとかで、決定的なものがありません。 が、ちょっと作ってみたのが、 1．空の画像を作って 2．ユーザのアップロードしてきた画像を空の画像にコピーする これだといけそうな気がしたので作っていました。 [PHPで画像XSSの一味変わった対策より引用] えーっと、さっそく試してみましたが、意図通りに動いていないようです。パレットにJavaScriptを仕込んだ画像を食わせると、出力された画像にもJavaScriptが残っていました。 「JavaScriptを埋め込んだ画像を作ってみました」で紹介した画像だとJavaScriptが消えるのですが、
クイズ:XSSとCSRFはどこにありますか? - ockeghem's blog
先の日記(XSSはブラウザ上でスクリプトが動き、CSRFはサーバー上でスクリプトが動く - ockeghem(徳丸浩)の日記)は、仕込んだネタがあたって多くの方に読んでいただいた。細かい内容については、頂戴した批判や反省もあるが、このテーマに対して多くの関心を集めることができたのは良かったと思う。今回も、手を変え品を変えて、XSSとCSRFの違いを説明しよう。ということで、今回はクイズ仕立てにしてみた。 といっても、非常に簡単なクイズだ。 認証を必要とする会員制サイトmaitter.comで、個人情報を入力する画面がある。典型的な、入力(A)-確認(B)-登録(C)という画面遷移（下図）を想定した場合、 XSSが発生しやすい画面を一つあげよ CSRFが発生しやすい画面を一つあげよ というものだ(入力画面は初期入力のみ想定)。エラー時の挙動などは指定されていないので想定しないものとする。 解
クロスサイトスクリプティング(XSS)とCSRFの違い早分かり - ockeghem(徳丸浩)の日記
昨日の日記で、DK祭りで使われている脆弱性がXSSかCSRFかという問題になった。どうも、XSSとCSRFがごっちゃになっている人もいるように見受けるので、簡単な整理を試みたい。 XSSとCSRFには似た点がある。 どちらも「クロスサイト」という言葉が先頭につく なりすましのようなことが結果としてできる どちらも受動型攻撃である それに対して、もちろん違う点もある。専門家から見れば「似てるも何も、そもそも全然違うものですよ」となるのだろうが、現に混同している人がいるのだから紛らわしい点もあるのだろう。 私思うに、XSSとCSRFの決定的な違いは、以下の点ではないだろうか。 XSSは攻撃スクリプトがブラウザ上で動くが、CSRFはサーバー上で動く このため、XSSでできる悪いことは、すなわちJavaScriptでできることであって、攻撃対象のCookieを盗み出すことが典型例となる。一方、CS
twitterにクロスサイトスクリプティング(XSS)脆弱性があればパスワードを変更できる - ockeghem's blog
秋のDK収穫祭などで騒がれている、いわゆるDK祭り。 さすがの私も、今夜半の祭りにはmaitter。 私のtwitterが荒らされていたのだ。 http://blog.livedoor.jp/dankogai/archives/50959103.html 現象から見てセッションハイジャックされたと思われるが、原因となる脆弱性が小飼弾氏の主張どおりCSRF(Cross Site Request Forgeries)だったのか、パスワードは窃取されたのか、元々のパスワードが類推しやすいものだったのかなど、議論を呼んでいる。 私は、現象からみて、原因となる脆弱性はCSRFではなく、XSSだったと思う*1。twitterにXSS脆弱性があれば、セッションハイジャックにより、第三者が小飼弾氏になりすまして発言するところまでは可能だ。しかし、一般的にはXSSではパスワードまでは窃取できない。id:ha
はてなブログ | 無料ブログを作成しよう
ネイルで使う材料で、DIY時の木割れやネジ跡を派手にしたらかわいい OSB合板でちょっとしたボックスをつくりました。 ビス止め下手すぎて木を割ったり穴あけすぎたりした場所に、好きな派手色の樹脂を詰めてパテ代わりにしてみました。 ちょっと某HAYっぽみ出て可愛かったので、自分用にメモです。 手順 塗装 派手色グミジェルで失敗部分…
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
About Secunia Research | Flexera
アップロード画像のXSS脆弱性について - はてなダイアリー日記
