Masato Kinugawa Security Blog: Referrer文字列によるXSS
リファラを使ったXSSの小ネタです。 今回取り上げるのは、ターゲット自身が、細工したページを経由することでつけられたリファラによって攻撃を受けるケースです。このような攻撃の場合は、現実に経由可能なページからでしか攻撃文字列を送りこむことができません。 例えば、以下のように、document.referrerをそのままdocument.write()しているページがあるとします。 http://vulnerabledoma.in/location/ リファラを書き出している部分でXSSできるでしょうか。 IEでは単純です。 IEはURLのクエリに、エンコードせずに「"<>」などを含めることができるので、これらを含むURLから、リファラを書き出しているページへ遷移させれば、XSSが起きます。 http://l0.cm/xss_referrer.html?<script>alert(1)</sc
Kazuho@Cybozu Labs: XSSに強いウェブサイトを作る – テンプレートエンジンの選定基準とスニペットの生成手法 (第１回神泉セキュリティ勉強会発表資料)
発表資料は以下のとおり。春山様はじめECナビの皆様、ありがとうございました。 XSSに強いウェブサイトを作る – テンプレートエンジンの選定基準とスニペットの生成手法View more presentations from kazuho.
Apache狙いの攻撃発生、パスワード流出の恐れも
バグトラッキングソフトをホスティングしているサーバが攻撃を受け、JIRA、Bugzilla、Confluenceのユーザーのパスワードが流出した恐れがあるという。 Apache Software Foundationは4月13日、バグトラッキングソフト「JIRA」をホスティングしているサーバが攻撃を受けたとブログで発表した。この攻撃により、ApacheでホスティングしているJIRA、Bugzilla、Confluenceのユーザーのハッシュ化されたパスワードが流出した恐れがあると警告した。 Apacheによれば、攻撃には短縮URLサービスのTinyURLを使ってクロスサイトスクリプティング（XSS）攻撃コードを仕込んだURLへリダイレクトする手口が使われたという。Apacheの管理者数人がこのリンクをクリックしてしまい、JIRA管理権限を含むセッションに侵入された。 さらにXSS攻撃と並行
htmlspecialcharsのShift_JISチェック漏れによるXSS回避策
補足 この記事は旧徳丸浩の日記からの転載です（元URL、アーカイブ、はてなブックマーク1、はてなブックマーク2）。 備忘のため転載いたしますが、この記事は2009年10月9日に公開されたもので、当時の徳丸の考えを示すものを、基本的に内容を変更せずにそのまま転載するものです。 補足終わり このエントリでは、PHPのhtmlspecialchars関数の文字エンコーディングチェック不備をついたクロスサイト・スクリプティング(XSS)脆弱性について、PHP側のパッチが提供されない状況での回避策について説明します。 何が問題か PHPにおいて、XSS対策にはhtmlspecialcharsによって記号をエスケープすることが行われますしかし、htmlspecialcharsを利用していても、Shift_JISの先行バイトを利用して、XSSが発生する場合があります。 例えば、以下のようなINPUTがあ
Rails 2系のXSS脆弱性がRuby 1.9では影響なしとされる理由 - 岩本隆史の日記帳（アーカイブ）
Rails 2系のXSS脆弱性を修正するパッチが先日公開されました。 4日(米国時間)、Ruby on Railsの2系すべてのバージョンにXSSの脆弱性があることがRiding Rails: XSS Vulnerability in Ruby on Railsにおいて発表された。特定のUnicode文字列を使ってチェックをくぐり抜け、任意のHTMLを送り込まれる危険性がある。なおRuby 1.9系で動作しているアプリケーションはこの影響を受けない。 http://journal.mycom.co.jp/news/2009/09/07/048/index.html この件に関して、大垣さんは次のように説明しています。 RoRの脆弱性に関連してRuby1.9では安全、と解説されていますが、それはRuby1.9は不正な文字エンコーディングを受け付けないからです。 何故かあたり前にならない文字エ
［気になる］JSONPの守り方
XSSにCSRFにSQLインジェクションにディレクトリトラバーサル……Webアプリケーションのプログラマが知っておくべき脆弱性はいっぱいあります。そこで本連載では、そのようなメジャーなもの“以外”も掘り下げていきます （編集部） JSONPだって、セキュリティを気にしてほしい 皆さんこんにちは、はせがわようすけです。今回は、JSONPを使用する場合のセキュリティについて解説しましょう。 JSONPとは、JSON with Paddingの名称が示しているとおり、JSON形式のデータにコールバック関数の呼び出しのためのコードを付加することで、クロスドメインでデータの受け渡しを実現するためのデータ形式です。JavaScriptからクロスドメインでのデータが簡単に扱えることなどを理由に、多数のWebアプリケーションでAPIの一部としてJSONP形式でデータの提供が行われています。 具体的な例を見
ツッコミ hideden (2009-08-06 12:45) - 徳丸浩の日記 - i-mode2.0セキュリティの検討 - 携帯JavaScriptとXSSの組み合わせによる「かんたんログイン」なりすましの可能性
SQLインジェクション対策はおすみですか? 開発開始時点からのコンサルティングから、公開済みWebサイトの脆弱性検査、 脆弱性発見後の適切な対策まで ●携帯JavaScriptとXSSの組み合わせによる「かんたんログイン」なりすましの可能性 このエントリでは、携帯電話のブラウザに搭載されたJavaScriptと、WebサイトのXSSの組み合わせにより、いわゆる「かんたんログイン」に対する不正ログインの可能性について検討する。 5月28にはてなダイアリーに書いた日記「i-mode2.0は前途多難」にて、今年のNTTドコモの夏モデルP-07AにてJavaScript機能が利用停止されたことを指摘した。同日付のNTTドコモ社のリリースによると、「ソフトウェア更新に伴い、高度化した機能の一部をご利用いただけなくなっていますが、再びご利用いただけるよう速やかに対処いたします」とあったが、それ以
画像ファイルによるクロスサイト・スクリプティング(XSS)傾向と対策
補足 この記事は旧徳丸浩の日記からの転載です（元URL、アーカイブ、はてなブックマーク1、はてなブックマーク2）。 備忘のため転載いたしますが、この記事は2007年12月6日に公開されたもので、当時の徳丸の考えを示すものを、基本的に内容を変更せずにそのまま転載するものです。 補足終わり 最近、画像ファイルを用いたクロスサイト・スクリプティングが注目されている。本稿では、画像を悪用したXSSについて説明した後、対策方法について解説する。 画像によるXSSとはどのようなものか Internet Explorer(IE)の特性として、コンテンツの種類を判別する際に、レスポンスヘッダ内のContent-Typeだけでなく、コンテンツの内容も判断基準にしている。このため、Content-Typeが例えばimage/gif(GIF画像)となっていても、中身がHTMLであればHTMLと解釈して表示する。
ケータイの流儀を常識と思いこむのは危険 | 水無月ばけらのえび日記
公開: 2009年8月6日14時10分頃 「やはり退化していた日本のWeb開発者「ニコニコ動画×iPhone OS」の場合 (takagi-hiromitsu.jp)」。 iPhone・iPod Touch用の「ニコニコ動画」アプリのサーバ側実装が脆弱だったというお話。iPhoneやiPod Touchの端末製造番号 (UDID) は秘密情報ではない上に詐称可能なのですが、そのUDIDに依存した認証を行っていたため、他人のUDIDが分かると、その人の非公開マイリストなどが見られてしまう……ということのようで。現在は修正されているようです。 脆弱性の話としては、認証方法の不備という単純な話なのですが、むしろ周辺の反応が興味深いですね。いちばん面白いと思ったのがこのブックマークコメント。 ツッコミがたくさん入っていますが、「流儀が違う」というのは、実は全くその通りなのですね。端末固有IDによる
i-mode2.0セキュリティの検討: 携帯JavaScriptとXSSの組み合わせによる「かんたんログイン」なりすましの可能性 - 徳丸浩の日記(2009-08-05)
_携帯JavaScriptとXSSの組み合わせによる「かんたんログイン」なりすましの可能性 このエントリでは、携帯電話のブラウザに搭載されたJavaScriptと、WebサイトのXSSの組み合わせにより、いわゆる「かんたんログイン」に対する不正ログインの可能性について検討する。 5月28にはてなダイアリーに書いた日記「i-mode2.0は前途多難」にて、今年のNTTドコモの夏モデルP-07AにてJavaScript機能が利用停止されたことを指摘した。同日付のNTTドコモ社のリリースによると、「ソフトウェア更新に伴い、高度化した機能の一部をご利用いただけなくなっていますが、再びご利用いただけるよう速やかに対処いたします」とあったが、それ以来2ヶ月以上が経つものの、未だにJavaScript機能は利用できない状態のままだ。 実は、NTTドコモ社が慌てふためいてJavaScript機能を急遽停止
Cross Site Scripting Prevention - OWASP Cheat Sheet Series
Introduction Index Alphabetical Index ASVS Index MASVS Index Proactive Controls Index Top 10 Cheatsheets Cross Site Scripting Prevention Cheat Sheet¶ Introduction¶ This cheat sheet helps developers prevent XSS vulnerabilities. Cross-Site Scripting (XSS) is a misnomer. Originally this term was derived from early versions of the attack that were primarily focused on stealing data cross-site. Since t
世間の認識と脅威レベルのギャップ――XSSは本当に危ないか？
皆さんこんにちは、川口です。コラムの第6回「IPSは“魔法の箱”か」でまっちゃ１３９で講演をしたお話を書きましたが、今度は関東でやっている「まっちゃ４４５」にお招きいただき、お話ししてきました。 まっちゃ４４５は募集開始から定員が埋まるまでがとても速く、今まで参加したことがなかったのですが、今回は運良く（？）講師側ということでキャンセル待ちにならずに参加することができました。ロックオンの福田さんがオープンソースのECサイト構築システム「EC-CUBE」に脆弱（ぜいじゃく）性が発見された際のインシデントハンドリングのお話をされていました。EC-CUBEにSQLインジェクションとクロスサイトスクリプティング（以下、XSS）が発見されたあとの対応のお話です。JSOCで日々インシデントにかかわっているいる自分としてはとても興味深い内容でした。 日本のエンジニアのセキュリティ意識は過剰？ 今回のよう
Kazuho@Cybozu Labs: クロスサイトのセキュリティモデル
« Japanize - IE 系の User JavaScript エンジンに対応しました | メイン | 安全な JSON, 危険な JSON (Cross-site Including?) » 2007年01月04日 クロスサイトのセキュリティモデル あけましておめでとうございます。 昨年、社内で「XMLHttpRequest は何故クロスサイトで使えないのか。画像や SCRIPT タグは使えるのに」という疑問 (というより試問) を耳にしました。おもしろい話なのでブログネタにしようと思っていたのですが、新年早々 GMAIL の事例がスラッシュドットされていたので、自分の現時点での理解をまとめてみることにしました。文書を確認して書いているわけではないので、間違いがあれば指摘してください。また、よい参考文献をご存知の方がいらっしゃいましたら、教えていただければ幸いです。 ウェブブラウザ
Kazuho@Cybozu Labs: 安全な JSON, 危険な JSON (Cross-site Including?)
« クロスサイトのセキュリティモデル | メイン | E4X-XSS 脆弱性について » 2007年01月06日 安全な JSON, 危険な JSON (Cross-site Including?) 先のエントリで、 JSON については、JavaScript として副作用をもたない (もたせようがない) ゆえに文法違反であるがゆえに、秘密情報を含むデータフォーマットとして使用することができるのです。 (Kazuho@Cybozu Labs: クロスサイトのセキュリティモデル) と書いたのですが、認識が甘かったようです。Jeremiah Grossman: Advanced Web Attack Techniques using GMail によると、配列の初期化演算子 [] の動作を外部から変更することができる注1とのこと。 実際に手元の Firefox 1.5 で試してみたところ、JS
対策としての入力値チェックは…… | 水無月ばけらのえび日記
まっちゃ445の懇親会で、大垣さんと徳丸さんとのやりとりが話題になっていました。 ホワイトリストはどう作る? (blog.ohgaki.net)ホワイトリスト方式の優位は神話 (www.tokumaru.org)プログラミングではホワイトリスティングが基本 (blog.ohgaki.net)プログラミングではホワイトリスティングが基本ではない (www.tokumaru.org)今こそXSS対策についてまとめよう (www.tokumaru.org)……なんというか、何について議論されているのかがよく分からない感じがしますね。 徳丸さんは以下のように述べられていますが、 これは「ホワイトリストかブラックリストか」という以前の話で、そもそも入力値チェックをXSSの「対策」とすること自体が不適切なのだ、と言われているのだと思います。これはその通りだと思います。 たとえば、このサイトには掲示板が
printenv at xss-quiz.int21h.jp
printenv at xss-quiz.int21h.jp Your IP address: 133.242.243.6 () NameValue HTTP_ACCEPT*/* HTTP_CACHE_CONTROLno-cache HTTP_CONNECTIONclose HTTP_HOSTxss-quiz.int21h.jp HTTP_USER_AGENTHatenaBookmark/4.0 (Hatena::Bookmark; Analyzer) QUERY_STRING REMOTE_ADDR133.242.243.6 REQUEST_METHODGET REQUEST_SCHEMEhttp REQUEST_URI/
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
「UnicodeによるXSSとSQLインジェクションの可能性」プレゼン資料 - ockeghem's blog