セキュリティ企業「Deusen」のセキュリティ専門家 David Leo氏は、Microsoft の Internet Explorer（IE）に存在する新たな脆弱性を報告しました。この脆弱性を利用することにより、攻撃者はブラウザの同一生成元ポリシーを侵害することが可能になります。同一生成元ポリシーは、ある生成元や Webサイトから読み込まれた文書やスクリプトが、異なる生成元からプロパティを取得したり設定したりするのを制限します。 同一生成元ポリシーを侵害することによって、攻撃者はセッションの乗っ取り、認証情報（クッキー）の窃取、フィッシング攻撃の開始が可能になります。今回の脆弱性は「ユニバーサルクロスサイトスクリプティング（Universal XSS、UXSS）」の攻撃を可能にし、すべての Webサイトが「クロスサイトスクリプティング（XSS）」と呼ばれる攻撃に脆弱になります。 UXSS
XSSとsecurityに関するn2sのブックマーク (29)
-
n2s 2015/02/17
-
安全なPHPアプリケーションの作り方2014
2. 徳丸浩の自己紹介 • 経歴 – 1985年京セラ株式会社入社 – 1995年京セラコミュニケーションシステム株式会社(KCCS)に出向・転籍 – 2008年KCCS退職、HASHコンサルティング株式会社設立 • 経験したこと – 京セラ入社当時はCAD、計算幾何学、数値シミュレーションなどを担当 – その後、企業向けパッケージソフトの企画・開発・事業化を担当 – 1999年から、携帯電話向けインフラ、プラットフォームの企画・開発を担当 Webアプリケーションのセキュリティ問題に直面、研究、社内展開、寄稿などを開始 – 2004年にKCCS社内ベンチャーとしてWebアプリケーションセキュリティ事業を立ち上げ • 現在 – HASHコンサルティング株式会社代表http://www.hash-c.co.jp/ – 独立行政法人情報処理推進機構非常勤研究員http://www.ipa.go.
-
-
XSSとSQLインジェクションの両方が可能なRFC5322適合のメールアドレス
メールアドレスの「ルール」に関する話題が盛り上がっていますね。 「メールアドレスのルール」系まとめがそろって間違ってるのでご注意を 「メールアドレスのルール」なんて使ってはいけない3つの理由 これらのエントリに異論があるわけでありません。メールアドレスに関するルールというとRFC5322などがあるものの、現実の運用では簡易的な仕様を用いている場合が大半である…という事情は、私も以前ブログに書きました。、 本稿では、「空前のメールアドレスのルールブーム(?)」に便乗する形で、RFC5322に準拠したメールアドレスで、XSSやSQLインジェクションの攻撃ができることを紹介します。と言っても、SQLインジェクションについては、過去に書きましたので、本稿では、RFC5322バリッドなメールアドレスでSQLインジェクションとXSSの両方ができるメールアドレスを紹介します。 まず、攻撃対象として、以下
-
XSS再入門
4. 典型的なXSSサンプルに対する「素朴な疑問」 • クッキーの値がアラートで表示されても、特に危険性はないよ うな気がする • クッキーの値はブラウザのアドオンなどでも表示できるよね • 任意のJavaScriptが実行されると言っても、ホームページ作 れば任意のJavaScriptが書けるし、見た人のブラウザで実行 されるよね… Copyright © 2013 HASH Consulting Corp. 4 5. そもそもの疑問：JavaScriptは危険か? • 実は、JavaScriptの実行自体は危険ではない • Webは、未知の（ひょっとすると悪意のある?）サイトを訪問し ても「悪いこと」が起きないように設計されている • JavaScriptの「サンドボックス」による保護 – JavaScriptからローカルファイルにアクセスできない – JavaScriptからクリップ
-
Yahoo！知恵袋にXSS脆弱性 ユーザーの指摘受けヤフーが修正
脆弱性を利用し、バラク・オバマ米大統領が質問しているかのように見せかけるJavaScriptが埋め込まれるなど、いたずらも行われていた。画像は、埋め込まれたJavaScriptの挙動を再現したもの 脆弱性があったのは、「あなたが最近見たQ＆A」機能。複数のユーザーが知恵袋の投稿などを通じて指摘しており、脆弱性について解説するブログも話題になっていた。 ヤフーは、ブログの指摘を見た社員からの報告を受け、22日朝に脆弱性を認知し、22日昼までに対処したという。 関連記事 WordPressの更新版公開、XSSなどの脆弱性を修正 従来バージョンのユーザーに対し、ただちにWebサイトをアップデートするよう強く勧告している。 Google、脆弱性情報に支払う報奨金を大幅アップ Googleは、同社の主要アプリケーションの脆弱性を見つけることの難しさを勘案して、報償額を大幅に引き上げた Apple、O
-
大垣さんと徳丸のパリデーション論争のリンク集
第一次論争 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を使
公式Twitter
- @HatenaBookmark
リリース、障害情報などのサービスのお知らせ
- @hatebu
最新の人気エントリーの配信
キーボードショートカット一覧
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Copyright © 2005-2025 Hatena. All Rights Reserved.
設定を変更しました