FRONTEND CONFERENCE 2017 にて、 - リモートチームで社内ハッカソンをやったエピソード - その時に使ったフロント技術の紹介 を発表した時の資料です。
![React/FluxベースのElectronアプリをリモートチームで開発した話](https://cdn-ak-scissors.b.st-hatena.com/image/square/5496868278554bbff8c4df6e265f8e0769a1c67c/height=288;version=1;width=512/https%3A%2F%2Ffiles.speakerdeck.com%2Fpresentations%2F9e2216bc58664c34adcdb3f3e6d6854e%2Fslide_0.jpg%3F7694597)
FRONTEND CONFERENCE 2017 にて、 - リモートチームで社内ハッカソンをやったエピソード - その時に使ったフロント技術の紹介 を発表した時の資料です。
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を発生させないようにしなければならない。 これまでWebアプリケーション上でXSSが存在したとしても、影響範囲はそのWebアプリケーションの中に留まるので、Webアプリケーションの提供側がそれを許容するのであればXSSの存在に目をつむることもできた。しかし、ElectronアプリでDOM-based XSSが一か所でも発生すると、(おそらく)確実に任意コード実行へとつながり、利用者のPCの(そのユーザー権限での)全機能が攻撃者によって利用できる。 そのため、Electronでアプリケーションを作成する開発者は気合いと根性でXSSを完全につぶさなければならない。 nodeIntegration:falseやContent-Security-Pol
1. This results in a 30% performance hit. It is unclear if it is supported in version 0.13. 2. This is a very weak protection. It’s basically a TAR archive of all the project files. 3. On a MacBook Pro Retina running Mac OS X.5.5 (Yosemite). Higher is better. 4. Unzipped. Depending on platform and architecture. See details in Jared’s comment below. 5. This can be done by using the “node-main” inst
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く