Content Security Policy の導入
原文: Implementing Content Security Policy on February 16, 2016 by April King, Stuart Colville Mozilla のアドオンチームは、addons.mozilla.org (AMO) で Content Security Policy (CSP) を有効にする作業を終えました。この記事では CSP 導入時の基礎とともに、CSP を AMO へ導入した際に遭遇した問題点も紹介します。 Content Security Policy について Content Security Policy (CSP) とは、クロスサイトスクリプティング (XSS) といったコンテンツを差し込む攻撃に関して、これらの攻撃に対する耐性を高めるためのセキュリティスタンダードです。CSP では、ユーザエージェントがコンテンツを取
バグハンターの哀しみ
12. 調査方法 ❶ URLの#以降にU+2028とDOM based XSSが起き得る文字列をつけて まわる ❷ 変なエラーがでないかみる http://host/#[U+2028]'"><svg/onload=alert(1)> 13. すると Benesseのサイトにメチャ普通のDOM based XSSがあった https://web.archive.org/web/20130723155109/http://manabi.benes se.ne.jp/#"><svg/onload=alert(1)> function writeAccesskeyForm(){ var htm = ''; var ownURI = location.href; //略 htm+= '<input type="hidden" name="backurl" value="' + ownURI + '"
脆弱性発見のプロ「キヌガワ マサト」さんは日本人だった
脆弱性を見つけてセキュリティ対策に貢献しているのが、「バグハンター」と呼ばれる存在だ。Googleなどベンダーの報奨金で生計を立てているという「キヌガワ マサト」さんが、プロのバグハンターとしての“愉しみ”を紹介してくれた。 ソフトウェアのバグや脆弱性は、軽微な不具合からセキュリティ上の深刻な問題を引き起こすものまで、様々なものがある。開発者が幾ら注意しても脆弱性をなくすことは非常に難しいが、外部の立場から脆弱性を見つけてセキュリティ対策に貢献する「バグハンター」という存在をご存じだろうか。 GoogleやMicrosoft、サイボウズなど一部のベンダーは、脆弱性を報告したバグハンターに報奨金などを支払う制度を運営。その報奨金で生計を立てるプロの一人が「キヌガワ マサト」さんだ。12月18、19日に行われたセキュリティカンファレンス「CODE BLUE」では、キヌガワさんがプロのバグハンタ
ファイアウォール内のサーバに対するShellshockを利用した攻撃 - 葉っぱ日記
2014-09-27: 該当サイト上にXSSがなくても攻撃可能であることが id:mayuki さんのコメントで判明しましたので全面的に書き直しました。ファイアウォール内であっても攻撃者はファイアウォール内のShellshock攻撃が通用するCGIのURLがわかっているだけで攻撃可能ですので早急に対応が必要です！会社のブログにも書いてますが、ファイアウォール内に置いてあるサーバで攻撃者が直接アクセスできないからといってbashの更新を怠っていると、条件によっては攻撃が可能となります。 条件としては、 そのサーバにはシェルを経由して外部コマンドを起動するCGI等が動いている(通常のShellshockの攻撃と同条件) 攻撃者がそのURLを事前に知っている(あるいは推測可能) となります。 攻撃者は、ユーザーを罠URLへ誘導し、以下のようなJavaScriptを罠ページ上で動かし、攻撃対象のW
Content-Security-Policy と nonce の話 - tokuhirom's blog
Content-Security-Policy の nonce を利用すると、XSS の脅威をかなり軽減できます。 そこで、Web Application Framework ではデフォルトで対応したほうがよいのではないか、という旨を @hasegawayosuke さんから教えて頂いたので、実装について考えてみました。 とりあえず CSP の nonce はどういうものなのかを考慮するために、コード例を探していたのですが、実際に動くサンプルというものが nonce 関連のもので見当たりませんでした。 そこで、実際に動くサンプルを用意しました。 https://github.com/tokuhirom/csp-nonce-sample 以下は Sinatra で書かれたサンプルコードです。 require 'sinatra' require 'securerandom' get '/' d
Shibuya.XSS テクニカルトーク #5 アウトラインメモ
Shibuya.XSS テクニカルトーク #5 : ATND Shibuya.XSSに参加してきたのでメモです。 体調がイマイチだったので朦朧としたメモです。 後、オフレコなものがあったので、その部分はオフレコとしてあります。 公開していけない箇所があったらIssuesなど立ててください。 私の見つけたXSS - yousukezan JVNのXSS FlashのXSS PaypalのXSS($100ぐらい) paypalの中国のサイト paypal-wujinggou.com All in ONE SEOプラグインのXSS (Wordpress) s=\\x22\x3e みたいな感じでXSS Wordpressのプラグイン XSSが日々大量に見つかるので要チェック Yahoo!のXSS 去年バウンティプログラムが始まって大量の脆弱性が報告されている Yahoo!mail の Self-X
mXSS
mXSS Tuesday, 6 May 2014 Mutation XSS was coined by me and Mario Heiderich to describe an XSS vector that is mutated from a safe state into an unsafe unfiltered state. The most common form of mXSS is from incorrect reads of innerHTML. A good example of mXSS was discovered by Mario where the listing element mutated its contents to execute XSS. <listing><img src=1 onerror=alert(1)></listing> W
mixiに報告した脆弱性2 - kusano-k’s blog
mixiの脆弱性報告制度（すでに終了している）で報告して、修正された脆弱性。 youbrideの有料機能を無料で使える問題 2014/03/12 報告 2014/03/18 修正完了 2014/03/24 75,000円のAmazonギフトが届いた youbrideはmixiの子会社の株式会社Diverseが運営する婚活サイト。一時、制度の対象だった。 youbrideでは無料ユーザーはプロフィールの公開条件は「全体に公開」しか選べない。 ChromeのDeveloper Toolで他の選択肢を有効にしたら、「全体に公開」以外の公開条件も選べてしまった。 mixiワードのXSS 2014/03/31 報告 2014/03/31 修正完了 2014/04/09 125,000円のAmazonギフトが届いた mixiワードにXSS可能な脆弱性があった。 「猫」には、キャットタワー、キャットフー
はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
XSS再入門
4. 典型的なXSSサンプルに対する「素朴な疑問」 • クッキーの値がアラートで表示されても、特に危険性はないよ うな気がする • クッキーの値はブラウザのアドオンなどでも表示できるよね • 任意のJavaScriptが実行されると言っても、ホームページ作 れば任意のJavaScriptが書けるし、見た人のブラウザで実行 されるよね… Copyright © 2013 HASH Consulting Corp. 4 5. そもそもの疑問：JavaScriptは危険か? • 実は、JavaScriptの実行自体は危険ではない • Webは、未知の（ひょっとすると悪意のある?）サイトを訪問し ても「悪いこと」が起きないように設計されている • JavaScriptの「サンドボックス」による保護 – JavaScriptからローカルファイルにアクセスできない – JavaScriptからクリップ
<script>alert("xss");</script>これであなたもおしまいです。 - http://detail.chiebuku... - Yahoo!知恵袋
古いブラウザ、Javaのバージョンとはまったく関係ありません。 とりあえず、今日あったことを書いておきます。 今日の午前の段階では、右サイドバーに「あなたが最近見たQ＆A」が表示されていました。 現在は表示するためのコードが削除されており、表示されておりません。 この「最近見た〜」に表示される内容は、サーバー側で書いているのではなく、クライアント側、つまり、InternetExplorerやChrome、Firefox、Safariのローカルストレージという所に閲覧履歴が貯められており、それを表示するようになってました。 これをサーバー側でやりたくない理由があるのか、面倒くさかったのか、この方法でもちゃんとやれば問題ないと言えば問題ないので、その判断は各自に委ねますが、致命的に駄目だったのは、質問のタイトルの中にHTMLのタグが混じっていても対処していなかったため、質問のタイトルに悪意ある
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」というクエリパラメータを付加することで、ページの表示に
ssig33.com - セキュリティの話
実際に危険な例 データの変更が出来るドメインに XSS がある 秘匿されたデータが閲覧できるドメインに XSS がある 声優の住所を公開するサイトがある 実際には危険ではない例 ameblo.jp に XSS がある Twitter クライアントの Consumer Key と Consumer Secret を第三者が取得できる 声優の携帯電話の情報をブログからまとめて公開するサイトがある 後者は大して危険ではないですし、こういうものを危険だ危険だといっていると真に危険なものについて話している人の声が届くべきところに届かないことになります。 ところで実際のところ、インテリジェンスなるもの大半は公開情報を検索可能な形に編集し意味のあるデータを作成する行為であり、声優の携帯電話に対してインテリジェンスの暴力を声優に翳すなと言う批判は成立するのだと思います。 例えば鹿野優以の使っていた携帯電話
twitterに学ぶなりすまし投稿対策
先日もtwitter上の犯行予告により20歳の青年が逮捕されたようですが、なりすましによる誤認逮捕ではなかったのか気になるところです。そこで、twitterが、なりすまし投稿をどの程度対策しているかを調べてみることにしました。twitterの安全性を確認することが目的というよりも、twitterが実施している対策を知ることにより、皆様のWebサイトを安全にする参考にしていただければと思います。 今回調べた「なりすまし投稿」の手法は下記の通りです。 クロスサイト・リクエスト・フォージェリ(CSRF) クロスサイトスクリプティング（XSS） HTTPヘッダーインジェクション クリックジャッキング DNSリバインディング クッキーモンスターバグ このうち、上の5つの解説は拙稿「“誤認逮捕”を防ぐWebセキュリティ強化術」、最後のクッキーモンスターバグについては、過去のエントリ「クッキーモンスター
CodeIgniter の XSS 対策はどうあるべきか？ その2 - A Day in Serenity @ kenjis
CodeIgniter の XSS 対策はどうあるべきか？ では、ビューでの変数をデフォルトで HTML エスケープするという実装案を示しましたが、それだけで XSS 対策が完了するわけではありません。 今回は、現状の CodeIgniter でどのような XSS 対策をすればいいかについて考えてみます。なお、実際のサイトでは、入力値のバリデーションも必須ですが、ここでは割愛してます。 なお、CodeIgniter 標準の XSS フィルタに対する私の考えは、CodeIgniter ユーザが CodeIgniter の XSS フィルタについて知るべき 5つのこと に記載しています。 XSS 対策として以下のすべてを実施します。 CodeIgniter の文字エンコーディングは UTF-8 にする HTTP レスポンスヘッダの文字エンコーディングを正しく指定する HTML の属性値はすべて
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
XSStrike
GitHub - teppeis/htmlspecialchars: Escape special characters to HTML entities in JavaScript
innerText(textContent)/innerHTMLを使ったHTMLエスケープは充分でないので今すぐやめろ、お前たちはもう終わりだ - TODESKING
スウェーデンの総選挙で、「JavaScript」に1票
CSRF対策用トークンの値にセッションIDそのものを使ってもいい時代なんて、そもそも無かった
