<script class="xss">$('.xss').parents().eq(1).find('a').eq(1).click();$('[data-action=retweet]').click();alert('XSS in Tweetdeck')</script>♥
ECMAScriptの仕様では、0x0A/0x0D以外にU+2028/2029の文字も改行とすることが明記されています。 これはあまり知られていないように思います。 以下はアラートを出します。 <script> //[U+2028]alert(1) </script> 知られていないだけでなく、知っていたとしても、スクリプトで文字列を処理するときに、U+2028/2029まで考慮する開発者がどれだけいるのかという話です。 実際、U+2028/2029を放り込むと文字列リテラル内にその文字が生のまま配置され、エラーが出るページは本当にたくさんあります。まあ、エラーがでるだけなら、大抵の場合大きな問題にはなりません。 ところが、U+2028/2029によってXSSが引き起こされてしまう場合というのを最近実際に見ました。 Googleのサービスで見つけた2つのケースを取り上げたいと思います。 ケ
平素よりYahoo!知恵袋をご利用いただきありがとうございます。 2017年11月30日をもちまして、「知恵ノート」機能の提供を終了いたしました。 これまでご利用いただきました皆様にはご迷惑をおかけすることとなり、誠に申し訳ございません。 長年のご愛顧、心よりお礼申しあげます。 引き続き、Yahoo!知恵袋の「Q&A」機能をご利用ください。 Yahoo!知恵袋トップ 知恵ノートサービス終了のお知らせ プライバシー - 利用規約 - メディアステートメント - ガイドライン - ご意見・ご要望 - ヘルプ・お問い合わせ JASRAC許諾番号:9008249113Y38200 Copyright (C) 2018 Yahoo Japan Corporation. All Rights Reserved.
2013-07-22 Yahoo!知恵袋にXSS?(その2) ブコメから、 netcraft XSS localStorageの保存件数が5件までなので、5件安全な質問を見ればスクリプトは実行されなくなるけど、他に危険なJS仕込まれる可能性があるし、Yahooが対応するまでは回答にあるユーザースクリプトを入れておいた方が良いな あぁ、localStorageなんですね。早速、質問者が必ずオバマになるという、凝ったいたずらも登場してますがw #アイコンがいいですね(笑)とりあえず、回答にあるJavaScriptを使うか、WebブラウザのディベロッパーツールからlocalStorageを削除しましょう。 Chromeだったら、開発/管理 -> ディベロッパーツール -> Resouce -> Local Storage -> http://detail.chiebukuro.yahoo.
Googleの脆弱性報酬制度の報酬がアップされましたね! Google、脆弱性情報に支払う報奨金を大幅アップ - ITmedia エンタープライズ http://www.itmedia.co.jp/enterprise/articles/1306/10/news027.html Googleアカウントページに存在するクロスサイトスクリプティング(XSS)の脆弱性情報については3133.7ドルから7500ドル accounts.google.comのXSSは$7,500 だそうです。みつけたいですね! みつけるのはかなり厳しいと思いますが、かつて2つみつけたことがあります。 今日はそのうち1つを紹介したいと思います。 oeパラメータを使ったXSS 2012年12月27日に報告し修正された問題です。 Googleは、一部のサービスで「oe」というクエリパラメータを付加することで、ページの表示に
なんか robots.txt がホットなキーワードになっていたので今さら知ったのですが、通信機器レンタルサービスの会社さんがクレジットカード情報をど派手に流出させたた件で、サイトに設置されていた robots.txt が色々と残念な件について話題になっていました。 robots.txt : はてなブックマーク 不正アクセスによるお客様情報流出に関するお知らせとお詫び : エクスコムグローバル株式会社 情報が流出した直接の原因は SQL インジェクションによる攻撃を受けたとのことで、同サイトの robots.txt が何の経緯で話題になったのかはわかりませんが、robots.txt の内容から、CMS に Drupal を使ってるらしいことや、Drupal のパッケージに同梱されてくる robots.txt ほぼそのまま設置されている件、さらにその、Drupal の古いバージョンには XSS
文字集合自体は抽象的な「文字の集まり」に過ぎないので単独で問題になることはないが,異なる文字集合に変換する際には問題が発生する場合がある。文字集合が異なるということは,対応する文字が1対1対応していないので,変換先の文字集合で対応する文字がないケースや,多対1の対応が発生する可能性がある。 図1に,Unicodeからマイクロソフト標準キャラクタセットに変換する場合を例示した。マイクロソフト標準キャラクタセットには「骶」(尾てい骨の“てい”)や,ハングルなどはない。また,バックスラッシュ「\」(U+005C)と円記号「\」(U+00A5)がともにJIS X 0201の「\」(0x5C)に変換される場合について示している。 「漢」のように1対1対応している文字は問題ない。ハングルや「骶」のように対応するコードポイントがない場合はエラーになるか文字化けする。インターネットで「尾 骨 びていこつ」
先に、「CVE-2008-5814を巡る冒険」にて、CVE-2008-5814脆弱性があるとdisplay_errorsがOnの環境下でXSS脆弱性となる場合があることを説明しました。しかし、display_errorsがOnの環境下ではCVE-2008-5814脆弱性がなくても、XSS脆弱性となる場合がしばしばあります。 これは、display_errorsによるエラーメッセージ表示がHTMLエスケープされていないことが原因です。簡単なサンプルを以下に示します。 <?php ini_set('display_errors', 1); // display_errorsを有効にする $a = array(); // 配列の生成 $index = $_GET['x']; // 配列のインデックスを得る $b = $a[$index]; // 配列の要素にアクセス このスクリプトに、x=<sc
先日もtwitter上の犯行予告により20歳の青年が逮捕されたようですが、なりすましによる誤認逮捕ではなかったのか気になるところです。そこで、twitterが、なりすまし投稿をどの程度対策しているかを調べてみることにしました。twitterの安全性を確認することが目的というよりも、twitterが実施している対策を知ることにより、皆様のWebサイトを安全にする参考にしていただければと思います。 今回調べた「なりすまし投稿」の手法は下記の通りです。 クロスサイト・リクエスト・フォージェリ(CSRF) クロスサイトスクリプティング(XSS) HTTPヘッダーインジェクション クリックジャッキング DNSリバインディング クッキーモンスターバグ このうち、上の5つの解説は拙稿「“誤認逮捕”を防ぐWebセキュリティ強化術」、最後のクッキーモンスターバグについては、過去のエントリ「クッキーモンスター
Twitterは2010年から、年ごとにTwitterのサービスのセキュリティ問題の報告者のリストを掲載しています。以下がそのページです。 https://twitter.com/about/security 幸運にも、僕は毎年載ることができているので、2013年も早速載ってやろうじゃないかということで頑張って脆弱性を探しました。結果はページを見てもらえばわかると思いますが、なんとかみつけることができました。今回みつけた問題がどんな問題だったかを書きたいと思います。2つあります。 1. analytics.twitter.com のXSS analytics.twitter.comは、Twitterが提供するサイトオーナーのための解析ツール、だそうです。こんな具合に、ログインページのパラメータでエンコーディング処理に起因するXSSがありました。 XSSベクタに関して特に面白いことはないので
指摘事項A中の(a)は、他を見なくても「セキュア」属性だと分かりますね。徳丸本(体系的に学ぶ 安全なWebアプリケーションの作り方)では、4.8.2クッキーのセキュア属性不備(P209)に説明があります。 指摘事項Bは、ここだけ読むと、XSSのようでもあり、サーバーサイドのスクリプトインジェクションのようでもありますが、検査ログからXSSであることがわかります(下図はIPAからの引用)。XSSは、徳丸本4.3.1クロスサイトスクリプティング(基本編)と4.3.2クロスサイトスクリプティング(発展編)にて説明しています。 ここまでは、ごく基本的な問題ですが、問題文P6に出てくる以下の部分は、少しだけひねってますね。 このプログラムは、利用者が入力した文字列をダイアログに表示するために、受け取ったパラメタの値をスクリプトに埋め込み、動的にスクリプトを生成する。図4の( c )行目では
先日のエントリ「処理開始後の例外処理では「サニタイズ」が有効な場合もある」は、素材の消化不足、私の表現の未熟等から、一部で誤解を招いてしまったようで申し訳ありません。アプローチを変えて、サニタイズについてもう一度考えてみたいと思います。結論から言えば、悪いサニタイズはあっても、「良いサニタイズ」はないと考えます。しかしながら、状況によっては妥協の産物としてサニタイズを使うことは、あり得ると考えます。 本稿で用いる「サニタイズ」の定義 サニタイズという用語は、歴史的に都合の良いように使われてきた歴史があり、あらためてネット検索して見ると、本当に多様な使われ方をしていると感じました。その様子は、高木浩光氏のブログ記事『「サニタイズ」という言葉はもう死んでいる』からも伺えます。 ここでは、議論の都合上、以下をサニタイズの定義として用いることにします。 サニタイズとは、 主にセキュリティ上の目的で
Masato Kinugawaさんのブログ「Masato Kinugawa Security Blog: Googleのmetaリダイレクトに存在した問題」を読んで、 <meta http-equiv="refresh" content="0;url=http://good/;url=http://evil/"> みたいな書き方をするとIE6、IE7ではevilなほうにリダイレクトされるということを初めて知ったわけですけど、それをTwitter上で言ったら みたいに言われてしまって軽くショック受けたんで追試してみたけど、「;」をエスケープしようと <meta http-equiv="refresh" content="0;url=http://good/;url=http://evil/"> みたいに書いても、「;url=」みたいな文字列が出現してしまって、やっぱりevilにリダ
マイクロソフト セキュリティ情報 MS11-099 - 重要 : Internet Explorer 用の累積的なセキュリティ更新プログラム (2618444) で修正された「Content-Disposition の情報漏えいの脆弱性 - CVE-2011-3404」について書いておきます。 Content-Disposition: attachment をHTTPレスポンスヘッダに指定すると、一般的なブラウザではコンテンツをブラウザ内でいきなり開くのではなく、ローカルディスクへダウンロードすることになります。ところが、MS11-099にて修正された脆弱性を使用すると、罠ページを経由することで Content-Disposition: attachment のついたhtmlを強制的にInternet Explorer内で開くことができたため、例えば Wiki や Web メールの添付ファ
Flash Playerの更新版で対処したクロスサイトスクリプティング(XSS)の脆弱性は、Webメールなどを狙った攻撃に悪用されているという。 米Adobe Systemsは、Flash Playerのセキュリティアップデートを6月5日付で公開し、クロスサイトスクリプティング(XSS)の脆弱性に対処した。これに合わせてGoogleも同日、WebブラウザChromeの安定版のアップデートを公開している。 Adobeのセキュリティ情報によると、脆弱性はFlash Player 10.3.181.16までのバージョン(Windows、Mac、Linux、Solaris向け)と10.3.185.22までのバージョン(Android向け)に存在する。この脆弱性を悪用し、悪質なリンクを仕込んだ電子メールを送り付けてクリックさせようとする手口が横行しているとの報告があるという。 ユーザーがこの手口にだ
こんにちは、セキュリティ勉強会などで講師を担当しているockeghem夫です。私は学歴も知識もありませんが、セキュリティに関してはプロフェッショナル。今回は、モテるセキュ女子力を磨くための4つの心得を皆さんにお教えしたいと思います。 1. あえて2〜3世代前の書籍の知識で対策する あえて2〜3世代前の書籍の知識で脆弱性対策するようにしましょう。そして勉強会の打ち上げで好みの男がいたら話しかけみましょう。「あ〜ん! addslashes本当にマジでチョームカつくんですけどぉぉお〜!」と言って、男に「どうしたの?」と言わせましょう。言わせたらもう大成功。「SQLインジェクションとか詳しくなくてぇ〜! サテ技本に載ってたからずっとaddslashes使ってるんですけどぉ〜! 日本語が化けるんですぅ〜! ぷんぷくり〜ん(怒)」と言いましょう。だいたいの男は新しい書籍を持ちたがる習性があるので、古か
要するに、解決されるまではログアウトしとけということだそうデス。 【2011/04/20 12:20 追記】ひゃっはー的なおまけを追加しました。 【2011/04/20 00:30 追記】多分これで最後。以降は Evernote の正式発表を待った上で、それを信用して利用するかどうかは各個人の判断にお任せします。 【2011/04/19 17:05 追記】午後の部追記。なお、エントリを起こされている方がおりましたのでご紹介。>『bulkneets氏によって報告されたEvernoteのXSS脆弱性とは 危険と対策』( http://d.hatena.ne.jp/pichikupachiku/20110419/1303158373 ) 続きを読む
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く