Electronの基本/セキュリティ/エンタープライズ

html5jウェブプラットフォーム部
[第11回勉強会 jsアプリ怪獣エレクトロンの育て方と倒し方](https://webplat.doorkeeper.jp/events/39975)

# ざっくりまとめ 2016/3/7現在

Electronは、
Web技術を使って割と簡単にクロスブラウザなデスクトップアプリを作ることができるので、
非常に魅力的な技術ではある一方、
現状、セキュリティ対策機構がないため、開発には細心の注意が必要。
特にXSS脆弱性が混入しやすく、XSSが発生した際には、そのアプリの範囲を超えて
致命的な被害をもたらす恐れがある。

現状事故報告はないが、世に出ているアプリは軒並み脆弱性があると思うとのこと。

プロダクションレベルのアプリを作るのは非常に危険が伴うので、
せいぜい社内利用のためのアプリを作るのにとどめておいた方がよし。

# 以下セッション内容


## Electron アプリの作り方
https://speakerdeck.com/yosuke_furukawa/electron-app-falsezuo-rifang
**Electronの基本について**

- クロスプラットフォームで動作するデスクトップアプリケーションを作るためのフレームワーク
- 中身は Node.js + Chromium だと思っておくと理解しやすい
- 2つのプロセス
    - Main Process
        - Node.jsの担当
        - プログラムのエントリーポイント
    - Renderer Process
        - Node.js + Chromium が担当
        - Webページを表示するためのプロセス
        - 通常のブラウザができることに加え、Node.js APIをコールすることができるので、OSへの低レベルのアクセスが可能。
- Electronのすごいポイント
    - レンダラ―プロセスから、ファイル読み込み、外部プロセス呼び出しなどが行えてしまう。
    - クロスプラットフォーム　Windows でも Mac でも動く。
    - npm資産が使えるので、いろいろなライブラリがある。
    - 事例が豊富 [awsome-electron](https://github.com/sindresorhus/awesome-electron)
- 代表的なElectron API
    - Main Process Side
        - app : アプリのライフサイクル（起動 / 終了など）管理用
        - autoUpdater : 自動更新検知 / ダウンロード / アップデート機能
        - powerMonitor : 電源管理
        - Menu / MenuItem : いわゆるメニューバー
    - Renderer Process Side
        - desktopCapture : デスクトップのスクリーンショットが取れる
        - webframe : ページのカスタマイズが可能 例えばズームの制御など
    - Both
        - clipboard : クリップボードの中のコピーしたものを取得できる
    - その他たくさん
        - 詳細は [APIリファレンス](https://github.com/atom/electron/tree/master/docs/api)
- チュートリアルアプリ
    - electronica
        - ```npm install electronica -g``` でインストール
        - ```electronica``` で起動


## Electron の倒し方
http://utf-8.jp/public/2016/0307/electron.pdf
**Electronのセキュリティについて**

- Electronの**セキュリティ保護機構はない**
- セキュリティ対策の３つの観点
    - Electron固有のAPIの使用上の注意が必要
    - ローカルアプリとしてのセキュリティ対策が必要
    - Webアプリとしてのセキュリティ対策が必要
- DOM-based-XSS について
    - Electronでは DOM-based-XSS が発生しやすい ※innerHTMLとか使っていると
    - DOM-based-XSS が発生する = レンダラープロセスで任意のスクリプトが実行される
    - レンダラープロセスではOSへの低レベルのアクセスが可能なため**致命的な被害**をもたらす
        - 既存アプリケーションの破壊
        - オンラインバンキング用アプリの改ざん / 盗聴
        - マルウェア感染 / 配信
        - つまり、**該当アプリの範囲を超えてなんでもできてしまう**
- DOM-based-XSS の緩和方法
    1. レンダラ―プロセス内でnode.js APIの使用を不可に設定する  
       再活性化できてしまう方法があるため**効果なし**
    2. Content Security Policy の導入
       - スクリプトなどのリソースが Same Origin Policy に制限される
       - インラインスクリプトやevalが禁止される
       - webviewタグ内では自由にJSが実行可能なため**効果なし**
    3. iframe sandbox の利用  
       DOM操作をすべて iframe sandbox 内で行う  
       - allow-foms : フォームの実行を許可
       - allow-scripts : スクリプトの実行を許可 **危険 いわずもがな**
       - allow-same-origin : 同一オリジン扱いを許可
       - allow-top-navigation : topへの干渉を許可 **危険 windowにアクセスできてしまうので**
       - allow-popups : ポップアップを許可 **危険 ポップアップ内ではJSが実行できてしまうので**  

    結論として3.の方法であればXSSの被害を緩和できそう。


## エレクトロン 対 エンタープライズ光線
http://www.slideshare.net/MizuhoSakamaki/electron-vs-enterprise
**Electronのエンタープライズ利用について**

- 業務用デスクトップアプリ作るなら...
    .NET（UWP / WPF）> Electron > JavaFX > Others
    無理に Electron を利用する必要はない

- Pros
    - 社内にWebフロントエンドエンジニアが余っていればあるいはやってみてもいいかも
    - 常駐アプリなどが簡単に作れるので魅力的ではある
    - 内製 / 社内システムであるなら有用な場面はありそう
    - 外向けにデモアプリ作るとかなら Electron でやるのもあり。Web技術でUI作成ができるので。

- Cons
    - 既存WebシステムのElectron化はやめたほうがいい
    - windows7以前のOS対応は無理
    - 開発はいいが、運用はきつい
    - 既存資産の置き換えには向かない