JavaScriptの文字列リテラルでXSS - T.Teradaの日記
たまに以下のようにJavaScriptの文字列リテラルに値が入るアプリを見ることがあります。 <script> var foo="●"; ... </script> 値は「●」の箇所にHTMLエスケープされて出力されます（下の方の例も同じ）。 こんなケースでどうXSSするか？という話です。 簡単にXSSできるケース 以下のパターンだとXSSするのは簡単です。 <script> var foo="●"; var bar="●"; ... </script> ?foo=\&bar=-alert(123)//のような値を与えるだけです。 難しいケース 次はこんなパターンを考えます。 <script> var foo="●"; var bar="●"; ... </script> こうなると難易度はぐっと上がります。というよりも、ほとんどの場合はXSSできません。 しかし、状況次第ではXSSできる
漢は黙ってXSSフィルタ | 水無月ばけらのえび日記
公開: 2010年2月28日1時10分頃 とあるサイトでXSS脆弱性らしきものを発見。いつもはこんな感じの3段階で脆弱性を確認しています。 「"><s>test」を入れて打ち消し線が出ることを確認する「"><script>alert(document.cookie)</script>」を入れてみる。IE8ではXSSフィルタで蹴られるが、ソース上に<script>が出ていることを確認する (「<script>」という文字列だけ消す、というような処理があるかどうか確認するため)実際にスクリプトが動作することを確認最後に実際にスクリプトの動作を確認するわけですが、IE8ではXSSフィルタを無効にしなければならず、それが非常に面倒くさいです。Firefoxの場合、NoScriptを入れているとやっぱりXSSフィルタが効いてしまいます。というわけで、XSSフィルタのないGoogle Chromeを使
htmlspecialcharsのShift_JISチェック漏れによるXSS回避策
補足 この記事は旧徳丸浩の日記からの転載です（元URL、アーカイブ、はてなブックマーク1、はてなブックマーク2）。 備忘のため転載いたしますが、この記事は2009年10月9日に公開されたもので、当時の徳丸の考えを示すものを、基本的に内容を変更せずにそのまま転載するものです。 補足終わり このエントリでは、PHPのhtmlspecialchars関数の文字エンコーディングチェック不備をついたクロスサイト・スクリプティング(XSS)脆弱性について、PHP側のパッチが提供されない状況での回避策について説明します。 何が問題か PHPにおいて、XSS対策にはhtmlspecialcharsによって記号をエスケープすることが行われますしかし、htmlspecialcharsを利用していても、Shift_JISの先行バイトを利用して、XSSが発生する場合があります。 例えば、以下のようなINPUTがあ
Supplementation of Bug #49785
Written by Kousuke Ebihara <ebihara@tejimaya.com>. And thanks to Hiroshit Tokumaru and t_komura. 1. Hiroshi Tokumaru Reports About "How level does htmlspecialchars() check invalid encodings?" Original entry is http://www.tokumaru.org/d/20090930.html [ja] He inspected that the following enhancement is really fixed. 08 Nov 2007, PHP 5.2.5 (snip) - Fixed htmlentities/htmlspecialchars not to accept p
Re:htmlspecialcharsに関する残念なお知らせ - 平々毎々（アーカイブ）
<追記 date="2009/10/10"> 岩本さんはレポートを2つ上げていたのだが http://bugs.php.net/bug.php?id=49785 http://bugs.php.net/bug.php?id=49814 1つ目の方で対応してもらえたようです。よかった。 私はPHPはぜんぜん詳しくないし、OSSへのバグレポートの経験は1回しかないので、はずしているかもしれない。 htmlspecialcharsに関する残念なお知らせ - 岩本隆史の日記帳（アーカイブ） 外国語ならなおさら、できる限りのことをしないと伝わらない – 秋元 こんな感じの内容だったらよかったのかな？せっかくいろんな人が検証したりしてたのに無視されるのももったいない。 PHPのhtmlspecialchars関数について、UTF-8以外の文字エンコーディングでは妥当性チェックが不充分であり、場合によっ
Firefox新セキュリティ、XSS防止コンテンツセキュリティポリシー登場 | エンタープライズ | マイコミジャーナル
Firefox web browser - Faster, more secure & customizable MozillaでSecurity Program Managerを務めるBrandon Sterne氏は6月19日(中国時間)、Mozilla Security BlogにおいてShutting Down XSS with Content Security PolicyのタイトルのもとでContent Security Policyと呼ばれる取り組みを発表した。同氏は発表以来Content Security Policyの策定と実装に取り組んできており、9月30日(中国時間)、A Glimpse Into the Future of Browser Securityにおいてその完成が近づいていることを報告している。 Content Security Policyはサーバサイド側
Shift_JIS では、htmlspecialchars() を使用しても XSS が可能な場合がある - t_komuraの日記
以下のページに関連して、htmlspecialchars() を使用している場合でも XSS が可能かどうか少し調べてみました。 http://www.tokumaru.org/d/20090930.html その結果、いくつかのブラウザで文字エンコーディングに Shift_JIS を使用していた場合、XSS が可能なことを確認しました。 テストコードは以下の通りです。リンクにマウスポインタを乗せると埋め込んだ Javascript が実行されます。 <?php $_GET['a1'] = "\xf0"; // \xf0 - \xfc で可能 $_GET['a2'] = " href=dummy onmouseover=alert(document.title) dummy=dummy"; header( "Content-Type:text/html; charset=Shift_JIS
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
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
XSS Protection by Default in Rails 3.0
[cvs] Diff of /php-src/ext/standard/html.c
http://twitter.com/i0n1c/status/4705129319