Electronでアプリを書く場合は、気合いと根性でXSSを発生させないようにしなければならない。 - 葉っぱ日記
そのうちもう少しきちんと書きますが、とりあえず時間がないので結論だけ書くと、タイトルが全てでElectronでアプリを書く場合は気合いと根性でXSSを発生させないようにしなければならない。 これまでWebアプリケーション上でXSSが存在したとしても、影響範囲はそのWebアプリケーションの中に留まるので、Webアプリケーションの提供側がそれを許容するのであればXSSの存在に目をつむることもできた。しかし、ElectronアプリでDOM-based XSSが一か所でも発生すると、(おそらく)確実に任意コード実行へとつながり、利用者のPCの(そのユーザー権限での)全機能が攻撃者によって利用できる。 そのため、Electronでアプリケーションを作成する開発者は気合いと根性でXSSを完全につぶさなければならない。 nodeIntegration:falseやContent-Security-Pol
<script>alert(1)</script>のお求めはAmazon CDストア - Qiita
本記事は脆弱性"&'<<>\ Advent Calendar 2015の15日目の記事です。 11/18にAmazonがリリースしたAmazon Musicというサービスに関連するXSSを2つ発見・報告したのでそのお話です。 1. Amazon MusicにあったXSS このページから "><_><script>alert(document.domain)</script>と検索すると alertが出ました。 画面右側のペイン内にて、aタグのhref attribute内に検索クエリを出力している箇所にあるバグに起因しています。この文字列は本来何らかの処理を通じてエスケープされていたのですが、適当に<hoge>のような文字列を一つ挟むとaタグのhref attributeから漏れて出力されていました。 11/19に発見・報告し、11/26に修正されました。 何故かAmazonのセキュリティ
エラーメッセージによるXSSにご用心
以前の記事「PHPのdisplay_errorsが有効だとカジュアルにXSS脆弱性が入り込む」では、php.ini等でdisplay_errorsを有効にしていると、スクリプトに脆弱性がなくてもXSS（クロスサイトスクリプティング）脆弱性が入り込む可能性が高いことを指摘しました。 しかし、display_errorを無効にしていても、エラー処理がまずいと、エラー表示が原因でXSS脆弱性が入り込む場合があります。ネット上のサンプルスクリプトを見ても、潜在的にXSS脆弱性があるものが多くあります。 サンプルスクリプト まずは、典型的な脆弱性の例をスクリプトで紹介します。PHP+PDO+PostgreSQLの組み合わせです。 <?php try { $db = new PDO("pgsql:host=localhost options='--client_encoding=UTF8';dbnam
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可能な脆弱性があった。 「猫」には、キャットタワー、キャットフー
知っていれば恐くない、XMLHttpRequestによるXSSへの対応方法
知っていれば恐くない、XMLHttpRequestによるXSSへの対応方法：HTML5時代の「新しいセキュリティ・エチケット」（3）（1/2 ページ） 連載目次 皆さんこんにちは。ネットエージェントのはせがわようすけです。前回は、同一オリジンポリシーを突破する攻撃の代表的事例であるXSSについて、特にDOM based XSSと呼ばれるものについて解説しました。今回はその続きとして、XMLHttpRequestによるXSSを解説します。 XHR Level 2によるリモートからのコード挿入によるXSS 従来、XMLHttpRequest（以下、XHR）は、表示しているドキュメントと同じオリジン（オリジンについては第1回を参照）としか通信できませんでしたが、現在の主要なブラウザーではXHR Level 2と呼ばれる実装により、オリジンを超えて通信することが可能になっています。 これは、Jav
SECCON2013 北陸大会の前日勉強会の資料 スライド形式のはこちら https://speakerdeck.com/mala/seccon2013-slide
スマートフォンのセキュリティについて ma.la 自己紹介 http://ma.la https://twitter.com/bulkneets LINE株式会社 livedoor方面の人です 仕事 JavaScript, Perl 元々の専門領域はUI, フロントエンド Webアプリ全般 認証認可周り セキュリティに関する業務 自社サービスのリリース前にチェックしたりとか 何か新しい攻撃手法見つかったら調査 他社サービスの問題見つけて報告したり オープンソースプロダクトのバグ報告したり そもそも何でJavaScriptを書いてた人間が セキュリティに関することをやっているのか あらゆるデバイスでHTML + JavaScriptが使われている どこまで悪用できるのか、どうやって修正すべきなのか 社内でもっとも詳しい 基本的にはWebの人 iOS / Android アプリ開発あまり詳しく
単純ではない、最新「クロスサイトスクリプティング」事情
単純ではない、最新「クロスサイトスクリプティング」事情：HTML5時代の「新しいセキュリティ・エチケット」（2）（1/3 ページ） 連載目次 皆さんこんにちは。ネットエージェントのはせがわようすけです。第1回目は、Webアプリケーションセキュリティの境界条件であるオリジンという概念について説明しました。 現在のWebブラウザーでは、同一オリジンのリソースは同じ保護範囲にあるものとし、オリジンを超えたアクセスについてはリソースの提供元が明示的に許可しない限りはアクセスできないという、「同一オリジンポリシー（Same-Origin Policy）」に従ってリソースを保護しています。 その保護範囲であるオリジンを超え、リソースにアクセスする攻撃の代表事例であるクロスサイトスクリプティング（XSS）について、今回、および次回の2回に分け、HTML5においてより高度化された攻撃と、その対策を説明しま
今夜つける HTTPレスポンスヘッダー （セキュリティ編） - うさぎ文学日記
Webサーバーがレスポンスを発行する際に、HTTPレスポンスヘッダーに付けるとセキュリティレベルの向上につながるヘッダーフィールドを紹介します。 囲み内は推奨する設定の一例です。ブラウザによっては対応していないヘッダーフィールドやオプションなどもありますので、クライアントの環境によっては機能しないこともあります。 X-Frame-Options ブラウザが frame または iframe で指定したフレーム内にページを表示することを制御するためのヘッダーフィールドです。主にクリックジャッキングという攻撃を防ぐために用いられます。 X-Frame-Options: SAMEORIGIN DENY フレーム内にページを表示することを禁止（同じサイト内であっても禁止です） SAMEORIGIN 自分自身と生成元が同じフレームの場合にページを表示することを許可（他のサイトに禁止したい場合は主にこ
Masato Kinugawa Security Blog: U+2028/2029とDOM based XSS
ECMAScriptの仕様では、0x0A/0x0D以外にU+2028/2029の文字も改行とすることが明記されています。 これはあまり知られていないように思います。 以下はアラートを出します。 <script> //[U+2028]alert(1) </script> 知られていないだけでなく、知っていたとしても、スクリプトで文字列を処理するときに、U+2028/2029まで考慮する開発者がどれだけいるのかという話です。 実際、U+2028/2029を放り込むと文字列リテラル内にその文字が生のまま配置され、エラーが出るページは本当にたくさんあります。まあ、エラーがでるだけなら、大抵の場合大きな問題にはなりません。 ところが、U+2028/2029によってXSSが引き起こされてしまう場合というのを最近実際に見ました。 Googleのサービスで見つけた2つのケースを取り上げたいと思います。 ケ
Masato Kinugawa Security Blog: たぶんXSSが理由でインターネットがとまった
昔自分が利用者だったサイトのセキュリティ問題(XSS)をいくつか報告していたのですが、おそらくそのリクエストを理由にインターネットが使えなくなりました。プロバイダに接続を止められたのです。 そのサイトで問題をみつけたとき、サービス提供者側の反応を示す兆候がありました。 問題を発見後、しばらくしてアクセスしようとすると、アクセスを拒否されたからです。 サービス提供者には問題を報告し、アクセス拒否についても、一応、今報告してる通りこれは攻撃ではないので誤解なきようよろしくとメール連絡したところ、問題は修正されました。 これで真意は伝わり、アクセスと関連付けられ、アクセス拒否に対する誤解も解決しただろうと思ったのですが、その後急にインターネットが使えない事態にまでなるとはだれが予想できたでしょうか…。(今は携帯の回線を使っています) プロバイダから書面が届き、書面には問題の報告時とほぼ同じ日付に
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
文字列からHTMLを組み立てる話 Shibuya.XSS techtalk #5