XSS game
Welcome, recruit! Cross-site scripting (XSS) bugs are one of the most common and dangerous types of vulnerabilities in Web applications. These nasty buggers can allow your enemies to steal or modify user data in your apps and you must learn to dispatch them, pronto! At Google, we know very well how important these bugs are. In fact, Google is so serious about finding and fixing XSS issues that we
mXSS - Mutation-based Cross-Site-Scripting のはなし - 葉っぱ日記
ここ数年、XSS業界の最先端で盛り上がっている話題として mXSS というものがあります。mXSS - Mutation-based XSS とは、例えば innerHTML などを経由してすでに構築されているDOMツリーを参照したときに、本来のDOM構造とは異なる結果を得てしまい、そのためにHTML構造の破壊を引き起こすという類のDOM based XSSの亜種とも言えます。 mXSSに関しては以下の資料などが参考になります。 The innerHTML Apocalypse mXSS Attacks: Attacking well-secured Web-Applications by using innerHTML Mutations どちらの資料にも掲載されていますが、mXSSのきっかけとなったのは 「教科書に載らないWebアプリケーションセキュリティ（1）：［これはひどい］IEの
セキュリティ・キャンプ2013 お疲れ様でした - 葉っぱ日記
今さらという感じもありますが、セキュリティ・キャンプ2013にWebセキュリティ・クラスの講師として今年も参加しました。 Webセキュリティ・クラス以外の実施内容については様々な記事をご参照いただくとして、ここではWebセキュリティ・クラスでの講義内容をご紹介したいと思います。 今年のWebセキュリティ・クラスでは、DOM based XSSを中心に、クライアントサイドで発生する脆弱性を中心に取り上げて講義および実習を行いました(参考:▶ セキュリティ・キャンプ2013：Webセキュリティクラスのご紹介)。ビデオ内でも話していますが、取り上げる内容をクライアントサイドに限定したのは、SQLインジェクションのような古くから存在するサーバ上の問題点については根本的な解決方法も見出されているものの、DOM based XSSのようなクライアントサイドで発生する問題についてはJavaScriptコ
X-Content-Type-Options: nosniff つかわないやつは死ねばいいのに! - 葉っぱ日記
2011-01-06: IE8ということを追記 & ちょっと間違いを修正。あけましておめでとうございます。 年明け早々ですが、Internet Explorerの話題です。IEはご存じの通り、Content-Type だけでなくコンテンツの内容なども sniff することでファイルタイプを決定しているため、画像ファイルやテキストファイルをHTMLと判定してしまい、クロスサイトスクリプティングが発生することが昔からたびたび報告されていました*1。現在は幾分マシになったとはいえ、IEのファイルタイプの判定アルゴリズムは非常に難解であり、現在でも状況によってはWebサイト運営者のまったく意図していないかたちでのXSSが発生する可能性があったりします。そういうわけで、IEがコンテンツを sniff してHTML以外のものをHTML扱いしてしまうことを防ぐために、動的にコンテンツを生成している場合に
第4回 危険性が理解されにくいネイティブアプリ内XSS（2） | gihyo.jp
アプリ内XSSの影響と問題点 筆者はSkypeの事例が報道される前にも、いくつかアプリ内XSSを見つけて報告したり、著名なアプリに同様の問題があったことを把握しています。しかし、単にサンドボックス内でJavaScriptコードが実行されるだけだろう、アプリケーションをクラッシュさせたりすることは当然可能だろうが、さほど悪いことはできないだろう、と考えていました。 中には、そのアプリケーションの設定ファイルを読み込むことが可能であり、設定ファイル内にサービスのログインに必要なメールアドレスやパスワードが含まれているケース、あるいはSQLiteデータベースのファイルの中に外部サービスのIDとパスワードが含まれているケースなども見てきました。いずれも影響範囲が大きいものですが、「そのアプリケーション」の保存しているデータであり、OSの持っているデータは読み取り不可能だろう、それ以外はOS側のサ
第4回 危険性が理解されにくいネイティブアプリ内XSS（1） | gihyo.jp
今回はネイティブアプリケーション[1] 内のXSS（Cross-Site Scripting、クロスサイトスクリプティング）脆弱性の傾向と対策について解説します。 ネイティブアプリの現状 内部にHTMLやJavaScriptを使って構築されるスマートフォン向け、デスクトップ向けのアプリケーションが増えています。その結果、今までWebサイト上で起きていたような問題が、ネイティブアプリケーション内でも起こるようになっています。アプリケーション内におけるJavaScriptコードのインジェクションは、クロス「サイト」ではないのでXSSと呼ぶのは適切ではありませんが、脆弱性の原因と対策方法はまさにWebサイトにおけるXSS脆弱性と同じです。 今回は、個人的に問題を発見・報告したことのある事例を挙げながら、「脆弱性をどのように発見するか」「どう修正すればよいのか」「どうすれば未然に防げるのか
PHPのイタい入門書を読んでAjaxのXSSについて検討した(1) - ockeghem's blog
このエントリでは、あるPHPの入門書を題材として、Ajaxアプリケーションの脆弱性について検討します。全3回となる予定です。 このエントリを書いたきっかけ twitterからタレコミをちょうだいして、作りながら基礎から学ぶPHPによるWebアプリケーション入門XAMPP/jQuery/HTML5で作るイマドキのWeという本を読みました。所感は以下の通りです。 タレコミ氏の主張のように、本書はセキュリティを一切考慮していない 主な脆弱性は、XSS、SQLインジェクション、任意のサーバーサイド・スクリプト実行（アップロード経由）、メールヘッダインジェクション等 脆弱性以前の問題としてサンプルスクリプトの品質が低い。デバッグしないと動かないスクリプトが多数あった 上記に関連して、流用元のソースやデバッグ用のalertなどがコメントとして残っていて痛々しい 今時この水準はないわーと思いました。以前
もいちどイチから！ HTTP基礎訓練中 第1回 XSSは知ってても、それだけじゃ困ります？ ― ＠IT
分かってるつもりではあるけれど…… クウはベンチャー企業で働くWebアプリケーションのエンジニア。でもそこは小さなベンチャー企業、セキュリティのことは分かっていながらも、動くものを納品するので精いっぱい……。今日は納品のため、客先でミーティングに参加していた。そしてお客様から受けた指摘は、こんな一言だった。 お客さん 「……で、このWebアプリケーション、セキュリティは大丈夫なんだよね？」 クウ 「は、はいっ！ もちろんです！」 お客さん 「じゃあ、これからもよろしく頼むよ」 クウ、ユウヤ 「よろしくお願いしますっ！」 無事、お客さんとのミーティングを終えたクウとユウヤの2人は、近くの喫茶店で一息いれることにした。 クウ 「最近はセキュリティのことを聞かれることがかなり増えてきましたねぇ」 ユウヤ 「ああ、そうだね。営業の段階から『セキュリティはどう担保されているんだ？』なーんてことをいわ
Twitterの脆弱性3連発 - ma<s>atokinugawa's blog
最近僕が発見し、修正されたTwitterの脆弱性を3つ紹介します。 1.旧Twitterの文字列処理に絡んだXSS 去年の夏くらいに、Twitter Web上で € 〜 ÿ の文字参照が含まれるツイートをXMLHttpRequestで読み込んだ際に表示が乱れるという問題に気付き*1、その時はこれは脆弱性には繋がらないだろうという判断をしたのだけど、今年の4月になって改めて調べたところ貫通しました。 表示が乱れるというのは、€ 〜 ÿ の文字参照が含まれるツイートがあると、一部の文字が\XXXXの形式に化けたり、ツイート周辺の「"」が「\"」になったりするものだったのですが、今回は「"」が「\"」になる点が脆弱性を発生させていました。 この条件でXSSさせようと思ったら、ツイートを細工してURLや@や#などオートリンクが作成される部分にうまいことイベン
第1回 UTF-7によるクロスサイトスクリプティング攻撃［前編］ | gihyo.jp
みなさん、はじめまして。はせがわようすけと申します。 最近、文字コードと関連したセキュリティの話題を目にすることが増えてきました。文字コードを利用した攻撃は技術的に未開拓ということもあり、参考となる情報がなかなか見当たりません。この連載では、文字コードを利用した攻撃やそれに対する対策について正しい知識を解説していきます。 文字コードとセキュリティが関連するもっとも大きな点は、やはり文字列の比較でしょう。「危険な文字列の検出」「安全な文字列であることの確認」といった文字列の比較は、セキュリティを考えるうえで避けて通れない処理だと思います。 文字列の比較においては、単純にバイト列を比較するだけでは不十分で、文字列がメモリ上でどのようなバイト列として格納されているのか（このルールを符号化方式あるいは文字エンコーディングと言います）に注意しなければならないこともあるでしょう。攻撃者は巧みに文字
JSONのエスケープをどこまでやるか問題 - 葉っぱ日記
Ajaxなアプリケーションにおいて、サーバからJSONを返す場合に、JSON自体はvalidであるにも関わらず、(IEの都合で)エスケープが不足していて脆弱性につながってる場合があるので、書いておきます。 発生するかもしれない脆弱性 JSONのエスケープが不足している場合に発生する可能性のある脆弱性は以下の通りです。 JSON内に含まれる機密情報の漏えい XSS それぞれの詳細については後述します。 開発側でやるべきこと 文字列中のUnicode文字は "\uXXXX" な形式にエスケープするとともに、ASCIIな範囲であっても「/」「<」「>」「+」も同様にエスケープすることにより、前述の脆弱性を防ぐことができます。 Perlであれば、以下のような感じになります。JSON->ascii(1) に続けて、JSON文字列を正規表現で置換しているあたりがキモになります。 use utf8; u
最終回 XSSの正体見たり 騙りタグ | gihyo.jp
＜前回のお話＞ XSSの正体は、タグに使用される特定の記号を本来とは異なる個所に用いることで、サーバの誤認識を誘発することと知ったわかばちゃん、“難しくない”というその対策とは!? そして気になる2人のカンケイは!? 読者100万人を巻き込んだ、衝撃と感動の一大スペクタクルがいまここに完結！
はまちちゃんのセキュリティ講座 ここがキミの脆弱なところ…！：第5回 こまっちゃうナ XSSにねらわれて｜gihyo.jp … 技術評論社
＜前回のお話＞ 一難去ってまた一難… CSRF対策もばっちり理解してこれで万全と思いきや、さらなる上手「XSS」の登場です。噂ではあんなこともこんなこともできちゃう凄いやつらしいけど、はたしてその実態は!? 敵を知れば百戦危うからずということで、まずは気になるその正体を探っていきましょう！
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
: _
はてなダイアリーのヘルプ - はてなダイアリーXSS対策
