Electronのwebview要素ではallowpopups属性をつけてはいけない - 葉っぱ日記
Electronを使ってブラウザのようなアプリケーションを作る場合には webviewタグが使用される。例えば、アプリケーション内にexample.jpのサイトを表示するには以下のようにHTMLに記述する。 <webview src="http://example.jp/"></webview> ここで、webviewタグにallowpopups属性を付与すると、example.jpサイト内のコードからwindow.open等を使って新たにウィンドウを開くことができるようになる。このとき、example.jpに悪意があり以下のようなコードが含まれているとする。 if( typeof require === "undefined" ) window.open( 'http://example.jp/', '', 'nodeIntegration=1'); else require( "chi
iframe sandbox は万能ではない - 葉っぱ日記
HTML5で導入されたiframe要素のsandbox属性は、そのiframe内のコンテンツに対しJavaScriptの実行を始め様々な制約を課すことでセキュリティの向上に役立つ機能である。例えば、以下のように指定されたiframeでは、iframe内からformのsubmitなどはできるが、iframe内でのJavaScriptの実行やtarget=_blankなどによってウィンドウを開くことなどは禁止される。 <iframe sandbox="allow-forms" src="..."></iframe> sandbox属性に明示的に allow-scripts という値を指定しない限りはiframe内では直接的にはJavaScriptは実行できないが、かといってiframe内から間接的にJavaScriptを必ずしも実行させることが不可能かというとそうでもない。 sandbox属性
Electronでアプリを書く場合は、気合いと根性でXSSを発生させないようにしなければならない。 - 葉っぱ日記
そのうちもう少しきちんと書きますが、とりあえず時間がないので結論だけ書くと、タイトルが全てでElectronでアプリを書く場合は気合いと根性でXSSを発生させないようにしなければならない。 これまでWebアプリケーション上でXSSが存在したとしても、影響範囲はそのWebアプリケーションの中に留まるので、Webアプリケーションの提供側がそれを許容するのであればXSSの存在に目をつむることもできた。しかし、ElectronアプリでDOM-based XSSが一か所でも発生すると、(おそらく)確実に任意コード実行へとつながり、利用者のPCの(そのユーザー権限での)全機能が攻撃者によって利用できる。 そのため、Electronでアプリケーションを作成する開発者は気合いと根性でXSSを完全につぶさなければならない。 nodeIntegration:falseやContent-Security-Pol
JavaScriptでbaseを指定して相対URLを絶対URLに変換する - 葉っぱ日記
メモがわり。 baseとなるURLを指定して相対URLを絶対URLに変換するには、ChromeやFireofxではURLUtilsを用いて以下のように書くことで簡単に実現できる。 var absolute = (new URL( "foo", "http://example.jp/bar/baz" ) ).href; // http://example.jp/bar/foo IEではURLコンストラクタはサポートされていないが、IE9以上ではDOMParserやcreateHTMLDocumentを使って現在のDOMとは分離したdocumentを生成し、その中に<base>要素を用いてbase URLを指定し、そのdocument内で<a>要素を用いて相対URLを絶対URLに変換するという手段によって相対URLを絶対URLに変換可能である。 function getAbsoluteUrl(
Host:リクエストヘッダによるXSS - 葉っぱ日記
本日、とある会合にてTwitterで交わされていたこの会話が話題になりました。 紹介されている例はHostヘッダの操作を経路とする攻撃ということであり、Hostヘッダインジェクションという脆弱性はないと思いますよ / “PHPにおけるHostヘッダインジェクション脆弱性 ― A Day in Serenit…” https://t.co/sTzTQEE7a8— 徳丸 浩 (@ockeghem) 2015, 11月 6 @ockeghem @okumuri 実はIEでは細工したホストヘッダを送出できる手法が知られています。間違いなくIEのバグですが、このせいで値をそのまま出力しているサイトではXSSがありえてしまいます。ここが参考になります： https://t.co/G419aaUgNi— Masato Kinugawa (@kinugawamasato) 2015, 11月 9 知る人ぞ
脆弱性"&'\ Advent Calendar 2014 (17日目) - 葉っぱ日記
この記事は脆弱性"&'<<>\ Advent Calendar 2014の17日目の記事です。今日は少し昔話をしようと思います。がはは。 かつて、日本製TwitterのようなWassrというサービスがありました。当時、Twitterは数日に一度くらいはサービスが落ちていて、Twitterユーザーも「またか」と思いながら我慢して使うようなサービスであり、Twitterが落ちるたびにWassrはユーザーを増やすとともに、画像の添付のように当時Twitterにはまだなかった機能をどんどんアグレッシブに取り入れていく、使っていて楽しいサービスでした。 さて、そんなWassrがある日絵文字機能を導入しました。当時はUnicode絵文字もなくスマートフォンも普及しておらず、主にレガシーな携帯電話で使える絵文字をなんとかWeb上でも使えるようにしたという感じのものでした。 絵文字をパレットから選択すると
脆弱性"&'\ Advent Calendar 2014 (16日目) - 葉っぱ日記
この記事は脆弱性"&'<<>\ Advent Calendar 2014の16日目の記事です。 Enjoy! で終わらせようかと思ったんだけど、毎日Enjoyし過ぎじゃないのみたいに思われそうなのでここ数日のを少し解説。 //d.hatena.ne.jp/hasegawayosuke/20141212/p1">脆弱性"&'<<>\ Advent Calendar 2014 (12日目) :URLが示すとおりAppleのサイトで任意コンテンツを表示可能な脆弱性。見つけたときにはもともとAppleサイトの問題なのかなと思ったけれど、Oracleのサイトにも同じような問題があって、Oracleへ連絡したらJavadocの脆弱性ということでJavaの脆弱性修正にて対応された。 //d.hatena.ne.jp/hasegawayosuke/20141213/p1">脆弱性"&'<<>\ Adven
脆弱性"&'\ Advent Calendar 2014 (13日目) - 葉っぱ日記
この記事は脆弱性"&'<<>\ Advent Calendar 2014の13日目の記事です。 Enjoy!
JavaScriptでリンク先URLがhttp/httpsか確認する方法 - 葉っぱ日記
JavaScriptで動的にリンクを生成する際に、DOM-based XSSを防ぐためにリンク先がhttpあるいはhttpsに限定されていることを確認したい場合がある。典型的には以下のようなコードとなる。 var div, elm; // 変数 url は攻撃者がコントロール可能な文字列 if( url.match( /^https?:\/\// ) ){ div = document.getElementById( "info" ); elm = document.createElement( "a" ); elm.setAttribute( "href", url ); elm.appendChild( document.createTextNode( url ) ); div.appendChild( elm ); } この場合、変数urlに「http://example.jp」や「
ファイアウォール内のサーバに対するShellshockを利用した攻撃 - 葉っぱ日記
2014-09-27: 該当サイト上にXSSがなくても攻撃可能であることが id:mayuki さんのコメントで判明しましたので全面的に書き直しました。ファイアウォール内であっても攻撃者はファイアウォール内のShellshock攻撃が通用するCGIのURLがわかっているだけで攻撃可能ですので早急に対応が必要です！会社のブログにも書いてますが、ファイアウォール内に置いてあるサーバで攻撃者が直接アクセスできないからといってbashの更新を怠っていると、条件によっては攻撃が可能となります。 条件としては、 そのサーバにはシェルを経由して外部コマンドを起動するCGI等が動いている(通常のShellshockの攻撃と同条件) 攻撃者がそのURLを事前に知っている(あるいは推測可能) となります。 攻撃者は、ユーザーを罠URLへ誘導し、以下のようなJavaScriptを罠ページ上で動かし、攻撃対象のW
ブラウザ内で安全に文字列からDOMを組み立てるためのRickDOMというライブラリを書いた - 葉っぱ日記
RickDOM - ricking DOM elements safety from string https://github.com/hasegawayosuke/rickdom ブラウザ内のDOMParserあるいはcreatHTMLDocument APIを使って不活性なDOMを組み立てたのちに、必要な要素と属性、スタイルだけを切り出して複製しているので、原理的にDOM based XSSの発生を抑えることができます。 使いかたも簡単。 var rickdom = new RickDOM(); var container = document.getElementById( "container" ); var elements; var i; // read allowings property to show default rule // div.textContent =
mXSS - Mutation-based Cross-Site-Scripting のはなし - 葉っぱ日記
ここ数年、XSS業界の最先端で盛り上がっている話題として mXSS というものがあります。mXSS - Mutation-based XSS とは、例えば innerHTML などを経由してすでに構築されているDOMツリーを参照したときに、本来のDOM構造とは異なる結果を得てしまい、そのためにHTML構造の破壊を引き起こすという類のDOM based XSSの亜種とも言えます。 mXSSに関しては以下の資料などが参考になります。 The innerHTML Apocalypse mXSS Attacks: Attacking well-secured Web-Applications by using innerHTML Mutations どちらの資料にも掲載されていますが、mXSSのきっかけとなったのは 「教科書に載らないWebアプリケーションセキュリティ（1）：［これはひどい］IEの
5分でテンションを上げる方法 - 葉っぱ日記
ちょっとテンションを上げたくなる時ってありますよね！今日はそんなときに簡単にテンションをあげる方法をお伝えします！ まず、PowerPoint(画像は2010)に適当な写真を張り付け 四角形を置き、写真と同じ大きさの四角形を置きます。 四角形の枠線を「なし」にし、「塗りつぶし」の図を先ほどの写真にします。これで同じ写真が2枚ならぶ恰好になります。 「図ツール 書式」から「背景の削除」を選び、顔と首を残し残りの背景を削除します。 顔パーツの「透過性」を40%くらいにします。 「図ツール 書式」の「回転」で顔パーツを左右反転させ、位置を調整すれば完成！ テンションあがってきたー！
HTML5関連のセキュリティ情報 - 葉っぱ日記
HTML5に関連したセキュリティの話題で、とりあえずこれまでに話した資料の一覧や、考察した記事。今後もっと増える予定です。「このAPI使う上で気を付けることないの？」みたいなリクエストもあればぜひ言って下さいませ。 JavaScript Security beyond HTML5 (2013-09-20 Developers Summit Kansai 2013) HTML5セキュリティ その1:基礎編、XSS編 (2013-06-13 OWASP Night 6th) Web::Security beyond HTML5 (2012-09-28 YAPC::Asia 2012) HTML5時代のWebセキュリティ (2012-09-15 第5回愛媛情報セキュリティ勉強会) Same-Origin Policy とは何なのか。 - 葉っぱ日記 XMLHttpRequestを使ったCSRF対
セキュリティ・キャンプ2013 お疲れ様でした - 葉っぱ日記
今さらという感じもありますが、セキュリティ・キャンプ2013にWebセキュリティ・クラスの講師として今年も参加しました。 Webセキュリティ・クラス以外の実施内容については様々な記事をご参照いただくとして、ここではWebセキュリティ・クラスでの講義内容をご紹介したいと思います。 今年のWebセキュリティ・クラスでは、DOM based XSSを中心に、クライアントサイドで発生する脆弱性を中心に取り上げて講義および実習を行いました(参考:▶ セキュリティ・キャンプ2013：Webセキュリティクラスのご紹介)。ビデオ内でも話していますが、取り上げる内容をクライアントサイドに限定したのは、SQLインジェクションのような古くから存在するサーバ上の問題点については根本的な解決方法も見出されているものの、DOM based XSSのようなクライアントサイドで発生する問題についてはJavaScriptコ
補足編：機密情報を含むJSONには X-Content-Type-Options: nosniff をつけるべき - 葉っぱ日記
「機密情報を含むJSONには X-Content-Type-Options: nosniff をつけるべき - 葉っぱ日記」の補足編です。 結局、よくわからないんだけど。 よくわからない場合は、とにかく全てのレスポンスに X-Content-Type-Options: nosniff をつけましょう。 機密情報を含むJSONにX-Content-Type-Options:nosniffをつける理由はわかったけど、「あらゆる」コンテンツにつける理由はなぜ？ 機密情報を含まなくても、<script>のような文字列を含むコンテンツをIEで直接開いた場合にはXSSにつながる可能性もあります。どのようなコンテンツにX-Content-Type-Options:nosniffが必要かを考えるくらいであれば、全てのコンテンツに付与したほうが間違いがなくていいでしょう、ということです。 IEのためだけの問
葉っぱ日記
在宅生活が本格化してからは多い時では1日10杯以上コーヒーを飲んでいたけど、さすがに飲みすぎなので1日1杯に減らした話。 2年以上ぶりにブログを書いてるんだけど、ほんとに個人的などうでもいい話です。このブログにはテクニカルな話は今後もほとんど書くことはないと思うので、テクニカルな話が読みたい人は会社のエンジニアブログを読んでください！（それもあんまりテクニカルな内容じゃないけど） もともとコーヒーが好きで、あんまり覚えてないんだけどたしか小学校3,4年生くらいのころから日常的にコーヒーを飲むようになったような気がする。親が飲んでたコーヒーがいい香りだったのでわけてもらって飲み始めたのがきっかけだったような記憶が。 で、コロナ禍以前はオフィスで自分で淹れたりバリスタの研修を受けた同僚に淹れてもらったりで毎日6,7杯は飲んでた。朝起きてコーヒー飲んで、会社についたら1杯、午前中にもう1杯、ラン
X-Content-Type-Options: nosniff つかわないやつは死ねばいいのに! - 葉っぱ日記
2011-01-06: IE8ということを追記 & ちょっと間違いを修正。あけましておめでとうございます。 年明け早々ですが、Internet Explorerの話題です。IEはご存じの通り、Content-Type だけでなくコンテンツの内容なども sniff することでファイルタイプを決定しているため、画像ファイルやテキストファイルをHTMLと判定してしまい、クロスサイトスクリプティングが発生することが昔からたびたび報告されていました*1。現在は幾分マシになったとはいえ、IEのファイルタイプの判定アルゴリズムは非常に難解であり、現在でも状況によってはWebサイト運営者のまったく意図していないかたちでのXSSが発生する可能性があったりします。そういうわけで、IEがコンテンツを sniff してHTML以外のものをHTML扱いしてしまうことを防ぐために、動的にコンテンツを生成している場合に
機密情報を含むJSONには X-Content-Type-Options: nosniff をつけるべき - 葉っぱ日記
WebアプリケーションにおいてJSONを用いてブラウザ - サーバ間でデータのやり取りを行うことはもはや普通のことですが、このときJSON内に第三者に漏れては困る機密情報が含まれる場合は、必ず X-Content-Type-Options: nosniff レスポンスヘッダをつけるようにしましょう(むしろ機密情報かどうかに関わらず、全てのコンテンツにつけるほうがよい。関連:X-Content-Type-Options: nosniff つかわないやつは死ねばいいのに! - 葉っぱ日記)。 例えば、機密情報を含む以下のようなJSON配列を返すリソース(http://example.jp/target.json)があったとします。 [ "secret", "data", "is", "here" ] 攻撃者は罠ページを作成し、以下のようにJSON配列をvbscriptとして読み込みます。もちろ
JSONのエスケープをどこまでやるか問題 - 葉っぱ日記
Ajaxなアプリケーションにおいて、サーバからJSONを返す場合に、JSON自体はvalidであるにも関わらず、(IEの都合で)エスケープが不足していて脆弱性につながってる場合があるので、書いておきます。 発生するかもしれない脆弱性 JSONのエスケープが不足している場合に発生する可能性のある脆弱性は以下の通りです。 JSON内に含まれる機密情報の漏えい XSS それぞれの詳細については後述します。 開発側でやるべきこと 文字列中のUnicode文字は "\uXXXX" な形式にエスケープするとともに、ASCIIな範囲であっても「/」「<」「>」「+」も同様にエスケープすることにより、前述の脆弱性を防ぐことができます。 Perlであれば、以下のような感じになります。JSON->ascii(1) に続けて、JSON文字列を正規表現で置換しているあたりがキモになります。 use utf8; u
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
