昨年の11月にブログエントリ『「SQLインジェクション対策」でGoogle検索して上位15記事を検証した』という記事を書いたところ、非常に好評で、「次はXSSについて書いてください」という要望をいただいておりました。中々XSSについては手がついておりませんでしたが、ようやく書いてみました。以下のURLで検索した結果の上位15位の記事を検証しました。 http://www.google.co.jp/search?q=クロスサイトスクリプティング対策&pws=0 検索結果は変動するため、私が検索した際の結果をEvernoteの公開ノートとして記録しています。 1～10位 11～20位 記事の「正しさ」の検証基準としては、IPAの「安全なウェブサイトの作り方改訂第5版」を参考に、最低限として以下が記述されているかどうかを確認しました。 HTMLのエスケープ処理を行う 属性値はダブルクォートで囲む
Shibuya.XSS テクニカルトーク#1 : ATND に参加してきたので、その時のメモ。 Shibuya.XSS Shibuya.XSSまとめ – Togetter DOM Based XSSの傾向と対策 – mala Shibuya.XSSで発表してきました – 金利0無利息キャッシング – キャッシングできます – subtech 機械的なスキャンで見つけづらいXSS location.hash経由で発火が多い、 サーバ側にアクセスログが残りづらい ビーコンでlocation.hashを記録する事も可能だけど、実行順序で潰される事がある location.hashでの問題 XHR2 どんな時に見つけにくい パラメーターをパースして利用してる場合 ソースを読まないと見つけにくい。 難読化されてるとしんどい レガシーコード どうするのがいいのだろうか バリデーション? バリデーション
最近僕が発見し、修正されたTwitterの脆弱性を3つ紹介します。 1.旧Twitterの文字列処理に絡んだXSS 去年の夏くらいに、Twitter Web上で € 〜 ÿ の文字参照が含まれるツイートをXMLHttpRequestで読み込んだ際に表示が乱れるという問題に気付き*1、その時はこれは脆弱性には繋がらないだろうという判断をしたのだけど、今年の4月になって改めて調べたところ貫通しました。 表示が乱れるというのは、€ 〜 ÿ の文字参照が含まれるツイートがあると、一部の文字が\XXXXの形式に化けたり、ツイート周辺の「"」が「\"」になったりするものだったのですが、今回は「"」が「\"」になる点が脆弱性を発生させていました。 この条件でXSSさせようと思ったら、ツイートを細工してURLや@や#などオートリンクが作成される部分にうまいことイベン
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
Evernoteに任意のHTMLを注入できる脆弱性がありました。 http://togetter.com/li/125281 Evernoteのセキュリティポリシーとかには触れず、とりあえず何が可能だったのか、どういう状況だったのかを書きます。 4/18 16時ごろ Evernoteの登録ページのHTMLに以下のような記述があります。 <script type="text/javascript"> $(document).ready(function() { suggestedTags = []; suggestedNotebook = ""; sourceUrl = ""; providerName = ""; payload = { "user" : { ... }, ..後略.. </script> このsourceUrl = ""の部分、https://www.evernote.c
最近のモダンなWebブラウザがサポートしている、セキュリティに関連しそうな X- なHTTPレスポンスヘッダをまとめてみました。それ以外にもあったら教えてください。 X-XSS-Protection 0:XSSフィルタを無効にする。 1:XSSフィルタを有効にする。 XSSフィルタを有効にすることでエンドユーザがXSSの被害にあう可能性が低減するが、まれに誤検知することで画面の表示が乱れることもある。IE8+、Safari、Chrome(多分) で有効。IEでは「X-XSS-Protection: 1; mode=block」という指定も可能。 2008/7/2 - IE8 Security Part IV: The XSS FilterBug 27312 – [XSSAuditor] Add support for header X-XSS-Protection X-Content-Ty
先のエントリ「(Twitter の XSS 脆弱性に関連して) 構造化テキストの正しいエスケープ手法について」の続き。 弾さんが「404 Blog Not Found:DHTML - 構造化テキストは構造化するのがやっぱ正しい」で示されているような DOM ベースの操作を行えば、原理的に XSS 脆弱性を防ぐことができます。ただ、クライアントサイド JavaScript によるレンダリングはウェブの構造を破壊するという点で筋が悪い（テーブルと FONT タグを利用したページレイアウトが批判されていた頃を覚えていらっしゃいますでしょうか。JavaScript によるレンダリングはウェブのリンク構造も破壊するので一層たちが悪いというのが自分の考え）ですし、サーバサイドでの DOM 操作は重たいので、できれば避けたいところです。 構造化テキストの HTML への変換は、よほど複雑な記法でない限り
4. 徳丸浩の自己紹介 • 経歴 – 1985年 京セラ株式会社入社 – 1995年 京セラコミュニケーションシステム株式会社(KCCS)に出向・転籍 – 2008年 KCCS退職、HASHコンサルティング株式会社設立 • 経験したこと – 京セラ入社当時はCAD、計算幾何学、数値シミュレーションなどを担当 – その後、企業向けパッケージソフトの企画・開発・事業化を担当 – 1999年から、携帯電話向けインフラ、プラットフォームの企画・開発を担当 Webアプリケーションのセキュリティ問題に直面、研究、社内展開、寄稿などを開始 – 2004年にKCCS社内ベンチャーとしてWebアプリケーションセキュリティ事業を立ち上げ • その他 – 1990年にPascalコンパイラをCabezonを開発、オープンソースで公開 「大学時代のPascal演習がCabezonでした」という方にお目にかかること
世界的猛威を奮ったTwitterマウスオーバー・バグはどう広まった？2010.09.22 10:305,281 satomi これは今朝世界中を席巻したTwitterバグにやられたブラウン元英首相夫人のTwitter公式サイト。巨大な英文字｢h｣が出て、日本のポルノサイトに自動リンクしてます...なんとまあ...。 ツイッター公式Webでリンクをマウスオーバーすると、フォロワーにスパムやポルノがリツイート（RT）されちゃう、この｢マウスオーバーバグ｣。いやあ、ひどかったひどかった。世界中にみるみる野火のように広まって一時はどうなることかと思いましたよ。 サードパーティーのアプリ使ってる人は大丈夫です（バグったRTもそっちで削除できます）が、twitter.com開いてこんな状態なっててビックリこいた人も多いんじゃ？ これはTwitterのサイトにあるクロス・サイト・スクリプティング（XSS
昨日の Twitter の XSS 騒ぎは、まだ皆さんの記憶に新しいことと思います。いい機会なので、ツイートのような構造化テキストのエスケープ手法について触れておきたいと思います。 Twitter のメッセージは、単なる平文（プレインテキスト）ではなく、「@英数字」のような他のユーザーへの言及と「http://〜」のような URL を自動的にハイパーリンク化する構造化テキストです。 このような複数のルールをもつ構造化テキストを HTML 化する際には、どのようなコードを書けばいいのでしょう？ まず「@〜」をリンク化してから、URL をリンク化すればいいのでしょうか？ それだと、@〜 のをリンク化した A HREF タグの中の URL がさらにリンク化されていまいますね。 では、URL をリンク化してから @〜 をリンク化すればいいのでしょうか？ それだと、@ を含む URL があった場合に
2010年09月22日21:30 カテゴリLightweight Languages 構造化テキストの間違ったエスケープ手法について 昨晩のtwitter XSS祭りは、ふだんもtwitter.comは使わない私には遠くの祭り囃子だったのですが、せっかくの自戒の機会なので。 Kazuho@Cybozu Labs: (Twitter の XSS 脆弱性に関連して) 構造化テキストの正しいエスケープ手法について 正しいアプローチは、全てのルールを同時に適用することです。 これは残念ながら(おそらく)必要条件であっても十分条件ではありません。 こういう(かなりええかげんな)正規表現でtweetをparseしていたとします。 re_http = '(?:https?://[\\x21-\\x7e]+)'; re_user = '(?:[@][0-9A-Za-z_]{1,15})'; re_hash
セキュリティ会社Sophosは米国時間9月21日、Twitterのウェブインターフェースを悪用した、潜在的な危険性を持つ新たなハックに関するエントリを同社ブログに投稿した。影響を受けるのはTwitter.comのみで、サードパーティー製クライアントは影響を受けない。 このハックの仕組みは次のようになっている。ツイートのURL内にJavaScriptコード（onmouseover）を挿入することで、ユーザーがリンクの上にカーソルを移動させた場合にポップアップメッセージを表示させるようにする。 Sophosは、この攻撃を最初に起こした人々は今のところ「遊びでやっている」が、スパマーや悪意あるコードの提供者らに悪用される可能性もあるとしている。この問題は、先週公開された新しいTwitterのウェブインターフェースとともに、従来のインターフェースにも影響があると思われる。 「Mouseover」ハ
NTTドコモとソフトバンクモバイルは、フィーチャーフォン（いわゆるガラケー）にてJavaScriptの対応を始めています。JavaScriptに対応すると、クロスサイト・スクリプティング(XSS)脆弱性の懸念が高まりますが、両社は独自の手法によりXSS対策をしている（しようとしている）挙動が観測されましたので報告します。この内容は、オレ標準JavaScript勉強会でネタとして使ったものです。 NTTドコモに学ぶ「XSS対策」まず、サンプルとして以下のようなXSS脆弱なスクリプトを用意します。 <?php session_start(); ?> <body> こんにちは<?php echo $_GET['p']; ?>さん </body>これを以下のURLで起動すると、IE7では下図のような表示になります。 []http://example.com/xss01.php?p=山田<scrip
html5securityのサイトに、XSSの各種攻撃手法がまとめられているのを発見せり!ということで、個人的に「お!」と思った攻撃をサンプルつきでご紹介します。 1. CSS Expression IE7以前には「CSS Expressions」という拡張機能があり、CSS内でJavaScriptを実行できたりします。 <div style="color:expression(alert('XSS'));">a</div> 確認 @IT -［柔軟すぎる］IEのCSS解釈で起こるXSS で詳しく解説されていますが、CSSの解釈が柔軟なことともあいまって自前で無害化するのはなかなか困難。以下のようなコードでもスクリプトが実行されてしまいます。 <div style="color:expr/* コメントの挿入 */ession(alert('XSS'));">a</div> 確認 <div s
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
適当 XSSがある=なんでもやり放題ではない ブログサービスなど自由にHTMLをかけるようなサービスでは、害が及ばないように表示を丸ごと別のドメインに分けていたり、あるいは別ドメインのIFRAME内で実行したりしているのが普通です。個人情報を預かってるサイトは、重要個人情報についてはHTTPSじゃないと参照できなかったり、そもそも表示しなかったり(パスワードやカード番号等)、決済用のパスワードや暗証番号を入れないと操作できなかったりする。 参考までに http://blog.bulknews.net/mt/archives/001274.html (2004年のアメブロ脆弱性の話) http://d.hatena.ne.jp/yamaz/20090114 (信頼できないデータを取り扱うドメインを分ける話) 管理用と別ドメインに分けたにも関わらず、script実行できることに対してDISられ
こんにちはこんにちは！！ 今日、はてなの人気記事を見ていてこんな記事がありました…！ ちゃんとセキュリティのこと考えてますか･･･！？ 『セキュリティ対策とか難しいし面倒くせーし、俺の適当に作ったサービスとかどうなってもイイしｗｗ』 いいんですいいんです！ 別にそう思ってるならどうでもいいんです！ でもそんなプログラムをWeb上で公開すんじゃねーよボケと。 PHPで誰でも簡単Webサービス製作！でなんか作って公開した奴ちょっと来い - 甘味志向＠はてな ふむふむ、PHPで簡単につくっちゃうのは良いけど、 公開するのなら、ちゃんとセキュリティホールなくしてからにしましょうね って記事ですね！ でもぼくは、この記事を読んでも… なぜXSSがいけないのか 結局よくわかりませんでした…。 いちおうXSS脆弱性があるとダメな理由として、下のようなことが書かれてあったんだけど… フォームに入力したHT
コミュニティーサイト構築に詳しい専門家は、「CSRF対策は基本的なところ。Amebaなうが対策していなかったのは意外だ」と話している。 「CSRF対策は基本的なところ」と言われると、発見も対処も容易であるような印象を受けますが、これは少し違和感がありますね。 半年ほど前の話ですが、弊社 (www.b-architects.com)のクライアントが新規のECサイトを立ち上げるにあたって脆弱性診断をしようという話になり、外部の会社に見積もり依頼をしたことがあります。その際、業界では知らない人がいないような大手会社の診断メニューも見せていただきました。 そこで印象的だったのは、標準とされるプランにCSRFの診断が含まれていなかったことです。標準のコースにはXSSやSQLインジェクションの診断が含まれますが、CSRFは「アドバンスド」プランの方にしか含まれていませんでした。普通のサイトではXSSや
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
