Universal XSS攻撃に利用されるIEのゼロデイ脆弱性の解析 | トレンドマイクロ セキュリティブログ
セキュリティ企業「Deusen」のセキュリティ専門家 David Leo氏は、Microsoft の Internet Explorer（IE）に存在する新たな脆弱性を報告しました。この脆弱性を利用することにより、攻撃者はブラウザの同一生成元ポリシーを侵害することが可能になります。同一生成元ポリシーは、ある生成元や Webサイトから読み込まれた文書やスクリプトが、異なる生成元からプロパティを取得したり設定したりするのを制限します。 同一生成元ポリシーを侵害することによって、攻撃者はセッションの乗っ取り、認証情報（クッキー）の窃取、フィッシング攻撃の開始が可能になります。今回の脆弱性は「ユニバーサルクロスサイトスクリプティング（Universal XSS、UXSS）」の攻撃を可能にし、すべての Webサイトが「クロスサイトスクリプティング（XSS）」と呼ばれる攻撃に脆弱になります。 UXSS
スクリプトインジェクション入門 - Qiita
はじめに 今回の記事は PHP を想定しています。 PHP は WEB サイトで最も使われていて、初心者がとっつきやすく、セキュリティーホールのあるシステムを最も多く生み出し続けている言語ですよね(￣▽￣；) そこで WEB プログラミングの初心者の方をターゲットに、出来るかぎり分かりやすく書いてみます。 というのは建前で、今週末にある PHP セキュリティのお勉強会の予習です。 記事の内容を他人の公開サーバーで試すと犯罪になる場合もあるので注意してね。 セキュリティを確保するにはシステムのアップデートが欠かせませんが、PHP は後方互換性に乏しく、バージョンアップが高コストなため、問題のあるバージョンのまま放置されたシステムになりやすく危険な言語だと思っています。 これは Ruby も同じで、私が言語を選べるなら、どちらも使いません。 堅い言語なら Java か C#(ASP.NET)、
Yahoo！知恵袋にXSS脆弱性 ユーザーの指摘受けヤフーが修正
関連記事 WordPressの更新版公開、XSSなどの脆弱性を修正 従来バージョンのユーザーに対し、ただちにWebサイトをアップデートするよう強く勧告している。 Google、脆弱性情報に支払う報奨金を大幅アップ Googleは、同社の主要アプリケーションの脆弱性を見つけることの難しさを勘案して、報償額を大幅に引き上げた Apple、OS XとSafariの更新版公開 深刻な脆弱性を修正 Appleが「OS X Mountain Lion v10.8.4」およびSnow LeopardとLion向けのアップデートをリリース。「Safari 6.0.5」も公開された。 関連リンク Yahoo!知恵袋にXSS？：yhgnの「自分に向けて書く」ブログ
大垣さんと徳丸のパリデーション論争のリンク集
第一次論争 XSSのホワイトリスト防御について 2008年2月 ホワイトリストはどう作る?（大垣さん） 徳丸コメント：XSSの攻撃方法を出発点として「ホワイトリスト」を検討するのはおかしいと思います。 2008年7月 ホワイトリスト方式の優位は神話（徳丸） 2008年8月 プログラミングではホワイトリスティングが基本（大垣さん） 徳丸コメント：バリデーションの基準は、「ホワイトリスト」（って何?）ではなくアプリケーションの仕様が基準 プログラミングではホワイトリスティングが基本ではない（徳丸） ホワイトリストとブラックリスト(SAWA, Izumiさん) 今こそXSS対策についてまとめよう（徳丸） 続・ホワイトリストとブラックリスト(SAWA, Izumiさん) 第二次論争 バリデーションは「セキュリティ対策なのか」 2011年12月 妥当性とは仕様の所作 - SQLインジェクション対策と
はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
Masato Kinugawa Security Blog: accounts.google.comに存在したXSS
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」というクエリパラメータを付加することで、ページの表示に
IPAテクニカルウォッチ 『DOM Based XSS』に関するレポート：IPA 独立行政法人 情報処理推進機構
IPA（独立行政法人情報処理推進機構、理事長：藤江 一正）は、IPAに届け出られる「DOM Based XSS」の脆弱性に関する届出が2012年後半から増加していることを踏まえ、それらの情報を分析して当該脆弱性の概要や対策のポイントをまとめた技術レポート（IPAテクニカルウォッチ 第13回）を公開しました。 IPAに多くの届出があるクロスサイト・スクリプティング（XSS）の脆弱性ですが、2012年第1四半期から第3四半期の期間では合計38件だった「DOM Based XSS」と呼ばれるタイプのクロスサイト・スクリプティングの脆弱性の届出が、第4四半期だけで92件（第3四半期までの件数比約2.4倍増）と急増しました。 一般にクロスサイト・スクリプティングは、サーバ側のプログラムに作り込まれてしまう脆弱性ですが、「DOM Based XSS」と呼ばれるクロスサイト・スクリプティングの脆弱性は、
IPAから『DOM Based XSS』に関するレポート出ました
DOM Based XSSに関しては、IPA「安全なウェブサイトの作り方」でも、拙著でもごく簡単にしか触れておらず、まとまった解説が要望されていましたが、本日（2013年1月29日）にIPAから「IPA テクニカルウォッチ『DOM Based XSS』に関するレポート」が公開されました。 同冊子の目次は下記の通りです。 はじめに 1. DOM Based XSSの概要 2. IPAに報告されたDOM Based XSSの脆弱性 3. DOM Based XSSの事例 4. DOM Based XSSの対策方法 コラム おわりに IPAのレポートと言うことで、DOM based XSSの届出の状況も説明されています。以下にグラフを引用します。 一見して「急増」していることと、昨年の10月から12月の3ヶ月で92件も届出があったということで、対策が急務となっている状況が見て取れます。これは、こ
http://blog.monoweb.info/blog/2012/02/18/ruby-secure-web-app/
See related links to what you are looking for.
情報処理試験問題に学ぶJavaScriptのXSS対策
指摘事項A中の(a)は、他を見なくても「セキュア」属性だと分かりますね。徳丸本（体系的に学ぶ 安全なWebアプリケーションの作り方）では、4.8.2クッキーのセキュア属性不備(P209)に説明があります。 指摘事項Bは、ここだけ読むと、XSSのようでもあり、サーバーサイドのスクリプトインジェクションのようでもありますが、検査ログからXSSであることがわかります（下図はIPAからの引用）。XSSは、徳丸本4.3.1クロスサイトスクリプティング（基本編）と4.3.2クロスサイトスクリプティング（発展編）にて説明しています。 ここまでは、ごく基本的な問題ですが、問題文P6に出てくる以下の部分は、少しだけひねってますね。 このプログラムは、利用者が入力した文字列をダイアログに表示するために、受け取ったパラメタの値をスクリプトに埋め込み、動的にスクリプトを生成する。図4の( c )行目では
はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
各ブラウザのUTF-7の対応状況 - 葉っぱ日記
今時のブラウザがどれくらいUTF-7をまだサポートしているか調べてみたのでメモ。全てWin32上。 IE8 レスポンスヘッダでcharset=utf-7と指定したとき、およびコンテンツの先頭(<html>より前)にUTF-7のBOMである +/v8- を挿入しておいた場合にUTF-7となる。<meta>でcharset=utf-7と指定した場合はページを表示したときにはUTF-7とはならないが、リロードするとUTF-7となる。 IE9beta レスポンスヘッダでcharset=utf-7と指定したとき、およびコンテンツの先頭(<html>より前)にUTF-7のBOMである +/v8- を挿入しておいたとき、<meta>でcharset=utf-7と指定したときにそれぞれUTF-7となる。 Firefox 3.6.13 <meta> で charset=utf-7 と指定しておくと、ページを
perl - EncodeでXSSを防ぐ : 404 Blog Not Found
2009年03月03日19:00 カテゴリLightweight Languages perl - EncodeでXSSを防ぐ 良記事。 第7回■文字エンコーディングが生み出すぜい弱性を知る：ITpro だけど、問題点のみ具体例があって、対策にないのが片手落ちに感じられたので、その点を補足。 結論だけ言ってしまえば、Perlなら以下の原則を守るだけです。 404 Blog Not Found:perl - Encode 入門 すでにOSCONでもYAPCでも、あちこちそちこちでこの基本方針に関しては話したのですが、ここ 404 Blog Not Found でも改めて。 Perl で utf8 化けしたときにどうしたらいいか - TokuLog 改め だまってコードを書けよハゲ入り口で decode して、内部ではすべて flagged utf8 で扱い、出口で encode する。これが
携帯電話事業者に学ぶ「XSS対策」 - ockeghem's blog
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
漢は黙ってXSSフィルタ | 水無月ばけらのえび日記
公開: 2010年2月28日1時10分頃 とあるサイトでXSS脆弱性らしきものを発見。いつもはこんな感じの3段階で脆弱性を確認しています。 「"><s>test」を入れて打ち消し線が出ることを確認する「"><script>alert(document.cookie)</script>」を入れてみる。IE8ではXSSフィルタで蹴られるが、ソース上に<script>が出ていることを確認する (「<script>」という文字列だけ消す、というような処理があるかどうか確認するため)実際にスクリプトが動作することを確認最後に実際にスクリプトの動作を確認するわけですが、IE8ではXSSフィルタを無効にしなければならず、それが非常に面倒くさいです。Firefoxの場合、NoScriptを入れているとやっぱりXSSフィルタが効いてしまいます。というわけで、XSSフィルタのないGoogle Chromeを使
XSSとセキュリティリスクと正しい脆弱性報告のあり方 - 最速転職研究会
適当 XSSがある=なんでもやり放題ではない ブログサービスなど自由にHTMLをかけるようなサービスでは、害が及ばないように表示を丸ごと別のドメインに分けていたり、あるいは別ドメインのIFRAME内で実行したりしているのが普通です。個人情報を預かってるサイトは、重要個人情報についてはHTTPSじゃないと参照できなかったり、そもそも表示しなかったり(パスワードやカード番号等)、決済用のパスワードや暗証番号を入れないと操作できなかったりする。 参考までに http://blog.bulknews.net/mt/archives/001274.html (2004年のアメブロ脆弱性の話) http://d.hatena.ne.jp/yamaz/20090114 (信頼できないデータを取り扱うドメインを分ける話) 管理用と別ドメインに分けたにも関わらず、script実行できることに対してDISられ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
安全なPHPアプリケーションの作り方2014
XSS再入門
ダイアリーとブログとXSS // Speaker Deck
http://blog.monoweb.info/article/2012021823.html