クライアントサイドの巨大なクッキーとサーバーサイドのヘッダーサイズ制限の組み合わせによるDoSについて - デー
もう10年以上前のネタなのですが、いまだに有効だし、最近、セッションを扱っていないならXSSがあってもあまり問題ないという意見を見ることがあるので、サービス提供側として案外面倒なことになる場合がある、という話を書きました。 POCです。 http://www.udp.jp/misc/largecookiedos.html 内容としては、 JavaScriptから巨大なCookieをブラウザに設定できる HTTPサーバーは受け取れるHTTPヘッダーサイズの上限を持っていて、それを超えていた場合にBad Requestを返す 1によって2を超えるサイズのCookieが設定可能な場合がある（たぶんほとんどの場合可能） よってXSSなどによって巨大なCookieを設定されると以降サービスが利用できなくなる というものです。 Cookieの有効期限を何十年も設定されるとユーザー側で勝手に回復すること
XHR XSS の話． - ほむらちゃほむほむ
概要 CORS が「幾つかのブラウザの先行実装」の状況から「古いブラウザではサポートされない機能」に変わりつつある頃合いなので，XHR2 が XSS の起点になりますよってお話． そもそも XHR XSS って何よ 簡単に言うとXHR2 による XSS のことのつもり．身近なところだと，jQuery Mobile がやらかしたり，大阪府警がやらかしたりした． 具体例1 jQuery Mobile jQuery Mobile については，jQuery MobileのXSSについての解説 で解説されるとおり． かいつまんで言うと，jQuery Mobile に location.hash の変更( hashchange イベント発火）時に，location.hash を URL とみなして読込んで，ページ内容を変更という機能があって，その読込先 URL にクロスドメインの制約がなかったので X
JSONのエスケープをどこまでやるか問題 - 葉っぱ日記
Ajaxなアプリケーションにおいて、サーバからJSONを返す場合に、JSON自体はvalidであるにも関わらず、(IEの都合で)エスケープが不足していて脆弱性につながってる場合があるので、書いておきます。 発生するかもしれない脆弱性 JSONのエスケープが不足している場合に発生する可能性のある脆弱性は以下の通りです。 JSON内に含まれる機密情報の漏えい XSS それぞれの詳細については後述します。 開発側でやるべきこと 文字列中のUnicode文字は "\uXXXX" な形式にエスケープするとともに、ASCIIな範囲であっても「/」「<」「>」「+」も同様にエスケープすることにより、前述の脆弱性を防ぐことができます。 Perlであれば、以下のような感じになります。JSON->ascii(1) に続けて、JSON文字列を正規表現で置換しているあたりがキモになります。 use utf8; u
それ Unicode で
UTF-7 を使ってスクリプトを記述 +ADw-SCRIPT+AD4-alert(\'XSS\');+ADw-+AC8-SCRIPT+AD4- IE は、文字エンコーディングが不明で UTF-7 っぽい文字列があれば、自動判別で UTF-7 となる。
エフセキュアブログ : ソーシャルメディア時代の脆弱性報告
ソーシャルメディア時代の脆弱性報告 2011年05月27日22:28 ツイート mikko_hypponen ヘルシンキ発 by：ミッコ・ヒッポネン 昨晩、古い電子メールを探していて、以下の奇妙なヘッダを見つけた： ユーモアのセンスを持つ誰かが、メールのヘッダにXSSジョークを挿入したのだ。 面白いと思ったので、このことについてTwitterに投稿した： 数分後、私はRobin Jacksonが以下のようにリプライしているのに気づいた： あり得ない。ツイートが「スクリプト」タグを含んでいるからといって、Javascriptを実行するTwitterクライアントは無い。 本当であることを示すため、Robinはスクリーンショットを投稿してくれた。 彼が使用しているクライアントは、Chrome用のTweetdeckだった。開発者に報せなくては。そしてもちろん、彼らもTwitter上にいる。 Tw
@ bulkneets氏によって報告されたEvernoteのXSS脆弱性とは 危険と対策 - 法学部生がライフハックするブログ
まずはじめに, 私がこの種の問題について, 専門知識を有するものではないことをお断りしておきます.また, 「問題だ」とは言うものの, 私自身で実際にどういう危険があるのか試すことはしていませんので, ひょっとしたら勘違いということもあるかもしれませんが, そこは技術のある方に検証いただければと思います.今回明らかになった問題@bulkneets氏の報告によると, 問題はEvernoteのWebクリッパーにあります.Evernoteに閲覧中のページをクリップするのに, ページに埋め込まれたWebクリッパーを使うことがあると思いますが, ここで, 「悪意のあるEvernoteクリッパー」を作成できるということです.仕組みEvernoteのWebクリッパーは次のようなURLで実行されます.https://www.evernote.com/noteit.action?url=ここでは空にしています
Evernote の XSS 脆弱性に関して mala 氏のつぶやき
要するに、解決されるまではログアウトしとけということだそうデス。 【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 ) 続きを読む
はてなブログ | 無料ブログを作成しよう
来年も作りたい！ふきのとう料理を満喫した 2024年春の記録 春は自炊が楽しい季節 1年の中で最も自炊が楽しい季節は春だと思う。スーパーの棚にやわらかな色合いの野菜が並ぶと自然とこころが弾む。 中でもときめくのは山菜だ。早いと2月下旬ごろから並び始めるそれは、タラの芽、ふきのとうと続き、桜の頃にはうるい、ウド、こ…
第6回 先行バイトの埋め込み | gihyo.jp
今回は、「先行バイトの埋め込み」という攻撃方法について紹介します。 ご存じのとおり、ほとんどの符号化方式（文字エンコーディング）においては、ひらがなや漢字などASCII以外のほとんどの文字は、1文字が複数バイトにて構成されています。たとえば、ひらがなの「あ」は、Shift_JISにおいては0x82 0xA0という2バイト、UTF-8においては0xE3 0x81 0x82という3バイトで表現されます。 攻撃者がマルチバイト文字の先行バイト部分だけを与えることにより、本来存在している後続の文字を無効にしてしまうのが、今回紹介する「先行バイトの埋め込み」という攻撃方法です。 先行バイト埋め込みの具体例 では、具体的な例を見ていきましょう。 たとえば、Shift_JISで書かれたHTMLとして、次のようなものがあったとします。 name: <input type=text value="" />
第5回 不正なバイト列の埋め込み | gihyo.jp
今回は、「不正なバイト列の埋め込み」という攻撃方法について紹介します。 文字列を入力とするソフトウェアにはさまざまなものがありますが、それらの処理系によっては、入力として与えた文字列中に、その文字コード上は不正となるようなバイト列を埋め込んでいたときに、それらのバイト列が無視されたり、想定外の文字に変換されてしまうことがあります。 たとえば、とあるソフトウェアにて （1) 処理A ＝ 文字列中に特定の文字（あるいは文字列）が含まれていないか検査 （2) 処理B ＝ 処理Aから受け取ったデータを処理。その際に不正なバイト列が無視あるいは別の文字に変換される という流れになっていた場合、後続の処理にて本来はフィルタリングされるべき文字列が含まれてしまうことになります。 このような流れを引き起こす具体的な例をいくつか紹介します。 Mozilla Firefoxにおける0x80の無視 Mozil
第3回 US-ASCIIによるクロスサイトスクリプティング | gihyo.jp
今回は、US-ASCIIによるクロスサイトスクリプティング(XSS)という話題について紹介します。 前回までで説明したUTF-7によるXSSと同様に、攻撃者はUS-ASCIIという文字コードを巧みに利用することで、IEを対象にXSSを発生させることができます。US-ASCIIによるXSSは、UTF-7によるXSSと類似点も多いため、前回までの説明も併せて読んでおくとよいでしょう。 US-ASCIIによるXSSについても先に対策を書いてしまうと、UTF-7のときと同様にHTTPレスポンスヘッダにて Content-Type: text/html; charset=UTF-8 Content-Type: text/html; charset=Shift_JIS Content-Type: text/html; charset=EUC-JP のいずれかを出力するという原則を守ることで、完全に攻撃
世間の認識と脅威レベルのギャップ――XSSは本当に危ないか？
皆さんこんにちは、川口です。コラムの第6回「IPSは“魔法の箱”か」でまっちゃ１３９で講演をしたお話を書きましたが、今度は関東でやっている「まっちゃ４４５」にお招きいただき、お話ししてきました。 まっちゃ４４５は募集開始から定員が埋まるまでがとても速く、今まで参加したことがなかったのですが、今回は運良く（？）講師側ということでキャンセル待ちにならずに参加することができました。ロックオンの福田さんがオープンソースのECサイト構築システム「EC-CUBE」に脆弱（ぜいじゃく）性が発見された際のインシデントハンドリングのお話をされていました。EC-CUBEにSQLインジェクションとクロスサイトスクリプティング（以下、XSS）が発見されたあとの対応のお話です。JSOCで日々インシデントにかかわっているいる自分としてはとても興味深い内容でした。 日本のエンジニアのセキュリティ意識は過剰？ 今回のよう
葉っぱ日記 - レジストリの HKCR￥MIME￥Database￥charset 以下に定義されています。
UTF-7を利用したXSSは、charset が指定されていない場合に発生すると考えられていますが、少なくとも Internet Explorer においては、これは大きな間違いです。正しくは、Internet Explorer が認識できる charset が指定されていない場合であり、charsetが付加されていても、IEが認識できない文字エンコーディング名である場合にはXSSが発生します。 例えば、次のような HTML は(HTTPレスポンスヘッダで charset が明示されていない場合)IEが文字エンコーディング名を正しく認識できないため、その内容からUTF-7と解釈されるためにスクリプトが動作します。"utf8"という表記はUTF-8の慣用的な表現ではありますが、ハイフンが抜けており正しい表記ではありません。 <html> <head> <meta http-equiv="Co
Atom や RDF を利用したXSS - 葉っぱ日記
Internet Explorer の悪名高い Content-Type: 無視という仕様を利用すると、Atom や RDF/RSS を利用してXSSを発生できることがあります。条件的に対象となるWebアプリケーションは多くはないと思いますが、それでもいくつか該当するWebアプリケーションが実在することを確認しました。以下の例では Atom の場合について書いていますが RDF/RSS でも同様です。 例えば、http://example.com/search.cgi?output=atom&q=abcd という URL にアクセスすると、「abcd」という文字列の検索結果を Atom として返すCGIがあったとします。 GET /search.cgi?output=atom&q=abcd Host: example.com HTTP/1.1 200 OK Content-Type: ap
安全なウェブサイトの作り方 改定第3版 - 葉っぱ日記
IPAによる「安全なウェブサイトの作り方」の改定第3版が出ていました。あちこちにUTF-7によるXSSネタが出てきているんですが、いくつか気になる点がありました。 まずはP.25から。 HTTP のレスポンスヘッダのContent-Type フィールドには、「Content-Type:text/html; charset=us-ascii」のように、文字コード(charset)を指定することができますが、この指定を省略した場合… 安全なウェブサイトの作り方 改定第3版 (P.25)より。charset をきちんとつけようという例で US-ASCII を示すのはあまり頂けないなと思います。Internet Explorer においては、US-ASCIIの場合は最上位ビットを無視するという問題が2006年から放置されてますので、US-ASCIIを指定してもそれはそれでWebアプリケーション開発
UTF-7 XSS Cheat Sheet
Countermeasures against XSS with UTF-7 are: Specify charset clearly (HTTP header is recommended) Don't place the text attacker can control before <meta> Specify recognizable charset name by browser. For more information about UTF-7 trick, see "Cross-site scripthing with UTF-7". These XSS patterns are tested on IE6 and IE7. Yosuke HASEGAWA <hasegawa@openmya.hacker.jp> Last modified: 2008-01
TAKESAKO @ Yet another Cybozu Labs: LL魂お疲れ様でした[LLSpirit]
LL魂、参加されたみなさんお疲れ様でした。みなさんのお陰で無事イベントを終了することができました。ありがとうございました。 前半の20枚だけですが、Flickrに写真をアップロードしました。 詳しい感想はのちほど。いろいろ新しい刺激を受けました。 とりいそぎ、Lightning Talksの発表資料（※画像はイメージでしたバージョン）を公開します。 イメージファイト！ - 画像に埋め込まれたPHP・XSS攻撃コードと戦う5つの方法 - 11 竹迫良範（Shibuya Perl Mongers） http://wafful.org/mod_imagefight/ImageFight-LL2007.ppt 先日、PHPの攻撃コードが隠された画像ファイルが、大手ホスティングサイトで発見されたとの報道がなされました。GIF,PNG,JPEG,BMP形式の画像ファイルには、PHPのRFI攻撃で使用さ
徳丸浩の日記 - mod_imagefight考 - 画像版サニタイズ言うな
SQLインジェクション対策はおすみですか? 開発開始時点からのコンサルティングから、公開済みWebサイトの脆弱性検査、 脆弱性発見後の適切な対策まで ● 画像版サニタイズ言うな しばらく前から、竹迫さんのイメージファイト(mod_imagefight)が、第10回セキュリティもみじセミナーなとで発表され話題になっていましたが、LL魂で発表されたプレゼン資料が公開されましたので、私もようやく内容を見させていただきました。 先日、PHPの攻撃コードが隠された画像ファイルが、大手ホスティングサイトで発見されたとの報道がなされました。GIF,PNG,JPEG,BMP形式の画像ファイルには、PHPのRFI攻撃で使用されるコードやJavaScriptのソースなどを埋め込むことができます。画像に埋め込まれた攻撃コードと戦う5つの方法について解説し、安全な画像アップローダの実装について考察します。
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Add a conformance test for the Ruby XSS-after-@ issues · mzsanford/twitter-text-conformance@c7d8497
JVN#50327700: PHP におけるクロスサイトスクリプティングの脆弱性