シングルクォートもきちんとエスケープする - 素人がプログラミングを勉強していたブログ
追記2：2007-10-11 - hoshikuzu | star_dust の書斎を見ると、下に書いてるような対策では不十分なようだ。 追記：エスケープすべき文字は、Re: JavaScript内（文字列）にデータを出力する場合の適切なエスケープ手順｜freeml byGMOなどを参考に。 シングルクォート(')をエスケープせずXSSの原因になっているサイトをけっこう見かけたので、どういう時問題になるのか書いておく。 JavaScriptの文字列を動的に埋め込む場合。 <script> var q = 'hoge"fuga'; document.getElementById('word').appendChild(document.createTextNode(q + 'の検索結果')); </script> のように、変数に代入する文字列を動的に作っている場合、RubyのCG
XSSを修正しないという事 (Kanasansoft Web Lab.)
今読み返すと、あちこちに変な日本語が混じっていますね。 訂正するのも嫌らしいのでそのままにしておきます。 はてなブックマークというサービスで、当エントリーに対してついたコメントに返信していきます。 このエントリーには、「XSSの危険性をわかっていない人に理解してもらう」というのが前提としてありました。 そして、「技術の疎い人にも理解して動いてもらう」という願いもありました。 このために、「多少の誤解を与えたとしてもなんとなく理解してもらう」事を重要視しています。 これを踏まえて以下記述します。 「#」ではじまるのがはてなブックマークのコメントです。 #2008年10月24日 g616blackheart ガードが堅いと言われた……どうしてだろう？ #2008年10月24日 anigoka なんかガードが堅いて言われちゃったんだけど、なに,オレが非コミュだって言いたいの！？ 申し訳ないです。
Greasemonkeyの共通な落とし穴を避ける - minghaiの日記
Greasemonkeyの過去においてのセキュリティ上の問題の解説。 Greasemonkeyだけに限らず、JavaScriptによるユーザ拡張を作成している全ての方に対して一読の価値があるドキュメントだと思われます。 原文：O'Reilly Media - Technology and Business Training Greasemonkeyの共通な落とし穴を避ける Greasemonkeyのセキュリティの歴史があなたの今にどう影響するのか (著) Mark pilgrim "Greasemonkey Hacks"の著者 2005/11/11 昔々、あるところにセキュリティホールがありました。（これは普通のおとぎ話ではないからそのまま読んでください。） Greasemonkeyのアーキテクチャは最初に書かれて以来大幅に変更されてきた。Version0.3は初めて広範囲に人気を得たバー
自由にアクセス制御可能なJavaScriptサンドボックスを作る:TKMR.blog.show
追記：早速破られた！ safeCall("var w=(function(){return this;}).call();w.alert(w.document.cookie);"); id:kazuhooku - http://b.hatena.ne.jp/kazuhooku/20071206#bookmark-6709542 サイ本よく見ると確かに「オブジェクトのメソッドとして呼び出された関数内でも、入れ子にされた関数内のthisはグローバルオブジェクトを参照します」て書いてあった。あとMDCにも http://developer.mozilla.org/ja/docs/Core_JavaScript_1.5_Reference:Operators:Special_Operators:this_Operator ========= 面白い記事があった、Greasemonkeyのunsaf
yohgaki's blog - 画像ファイルにJavaScriptを隠す
(Last Updated On: )前回のエントリでイメージファイルにスクリプトを埋め込んで攻撃する方法について記載しましたが、最近イメージファイルにスクリプトを埋め込む事例が話題になったためか ha.ckersにJavaScriptをイメージファイルに隠す方法が紹介されています。 http://ha.ckers.org/blog/20070623/hiding-js-in-valid-images/ <script src="http://cracked.example.com/cracked.gif"> などとXSS攻撃を拡張する手段に利用可能です。サンプルとしてFlickerにJavaScriptを埋め込んだイメージファイルがアップされています。 このイメージファイルは上手く細工しているので画像としても表示され、JavaScriptも実行できます。 Flickerは画像ファイルをそ
XSS対策:JavaScriptのエスケープ(その2) - ockeghem's blog
5/11の日記XSS対策:JavaScriptなどのエスケープ - ockeghem(徳丸浩)の日記に対する金床さんのコメントに触発されて、JavaScriptのエスケープについて検討してみよう。ただし、現実のアプリケーション開発においては、私はJavaScriptの動的生成を推奨していないが、これはエスケープ処理をどのように考えるかと言うレッスンのつもりで検討することにする。 金床さんのコメントで紹介されたリンクには、以下のようなガイドライン案が提案されている。 JavaScriptの文字列でのエスケープ手順としては、以下が今のところ正解っぽい感じです。 1. 「\」を「\\」に置換する 2. 「"」を「\"」に置換する 3. 「'」を「\'」に置換する 4. 「/」を「\/」に置換する 5. 「<」を「\x3c」に置換する 6. 「>」を「\x3e」に置換する 7. 「0x0D（CR)
Ajaxian ? Gmail CSRF Security Flaw
Enterprise Strategy Group: Go-to-market Expertise to Help You Win
JavaScriptのソースに重要なデータを埋め込むなんて….
(Last Updated On: )GmailでJavaScriptのソースとしてコンタクトリストデータを埋め込んでいたため、第三者がコンタクトリストを盗めてしまう、という問題が話題になっています。 まだ詳しく調べていませんがsrc属性に指定されたソースは誰でも（どのサイトからでも）取得できるブラウザの仕様を利用したものだと思います。 比較的早くからsrc属性で他のサイトのJavaScritpが指定できる仕様のリスクは指摘されていました。Gmailでさえ重要なデータをJavaScriptのソースに埋め込んでいるのですからAjaxアプリケーションの多くに同じ脆弱性があるような気がします… 手っ取り早く不完全な方法で修正するにはリファラチェック、きちんと修正するならJavaScriptのリクエストに鍵を付けてチェックする、といった方法で対策可能です。 http://example.com/j
hoshikuzu | star_dust の書斎 InternetExplorer6::base要素のstyle属性が全要素に効くのでJavaScriptも記述し放題
下のソースでローカルにHTMLファイルを作りIE6で開く。一行目はおまじないなので省略しない。img要素とかbr要素とかが泣ける。 <!-- saved from url=(0014)about:internet --> <html> <head> <title>nandakore</title> </head> <body> <base id="b00" style="width:expression(setTimeout(this.innerText,0))"> <pre> resizeTo (400, 400); </pre> <img> document.title='areare'; </img> <br> var hoge = 'foo'; </br> <blockquote> window.status = hoge; </blockquote> </body> </html
XSS (Cross Site Scripting) Cheat Sheet
XSS (Cross Site Scripting) Cheat Sheet Esp: for filter evasion By RSnake Note from the author: XSS is Cross Site Scripting. If you don't know how XSS (Cross Site Scripting) works, this page probably won't help you. This page is for people who already understand the basics of XSS attacks but want a deep understanding of the nuances regarding filter evasion. This page will also not show you how to
IE における "expression" の過剰検出による XSS の 誘因
IE における "expression" の過剰検出による XSS の 誘因 2006-08-31-1: [Security] http://archive.openmya.devnull.jp/2006.08/msg00369.html IE では expression(式) をスタイルシート内で記述することで JavaScript を記述することができるのは有名ですが， IE による expression の検出がやたら過剰で XSS を引き起こしやすいということらしい． 実態参照やコメントの挿入，Unicode 文字，全角文字で記述しても expression として検出される． 詳細は，上記サイトより引用． IE では、以下のようなスタイルを記述することで、JavaScript を動作させる ことが可能です。 1) <style>ブロック内での定義 <style>input { l
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
https://labs.cybozu.co.jp/blog/kazuho/archives/2007/01/e4x-xss.php
https://labs.cybozu.co.jp/blog/kazuho/archives/2007/01/crosssite_security.php