html5 web アプリケーションのセキュリティ

HTML5 Web アプリケーションのセキュリティMurachi Akira （ CPS Corporation ）

This material provided by CC BY-NC-ND 4.0. See http://creativecommons.org/licenses/by-nc-nd/4.0/

About me 村地　彰 aka hebikuzure

株式会社シーピーエス代表取締役 Microsoft MVP (Most Valuable Professional)

2011 年 4 月～受賞分野 Visual Studio and Development

Technologies(Front End Web Dev)

2 ©Murachi Akira | This material provided by CC BY-NC-ND 2017/2/25

宣伝

2017/2/25©Murachi Akira | This material provided by CC BY-NC-ND 3

トレーニング、講習を承りますプログラミング系 (JavaScript 、 PHP 、 Java 、 VB 、

C#) IT スキル (Office 、ネットワークなど ) 系情報セキュリティ系情報処理技術者試験対策 (IT パスポート、初級、中級、

情報セキュリティマネジメント ) 情報セキュリティマネジメント、個人情報保護の

コンサルティングと技術支援を承りますコミュニティ「ネットワークパケットを読む会

（仮）」をやってます http://pa.hebikuzure.com/

Agenda HTML5 Web アプリケーションのセキュリティ

について理解する守るべきものは何か何が脅威なのか

発生する脆弱性について理解する発生する脆弱性を防ぐ方法を理解する

脅威からどのように守るのかどのように脅威を正しく評価するの

か©Murachi Akira | This material provided by CC BY-NC-ND 4 2017/2/25

目次はじめにセキュリティのおさらい守るべき「情報資産」・資産に対する「脅威」脅威への対応脆弱性を作りこまないインシデントへの対処まとめ

©Murachi Akira | This material provided by CC BY-NC-ND 5 2017/2/25

はじめに

ありがちなシステム開発

システム開発頼むよ～

要件定義は？

ざっくりこんな感じ～

が、がんばります……

追加であれとこれとそれも～

できましたヽ (^o^) 丿

欲しかったシステムじゃない (-_-;)

・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・

ありがちなセキュリティ

セキュリティ対策頼むよ～

セキュリティポリシーは？

ざっくりこんな感じ～

追加であれとこれとそれも～

できましたヽ (^o^) 丿

欲しかったセキュリティじゃない (-_-;)

・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・

2017/2/259

どうしてこうなった？

開発者・運用者にセキュリティの当事者意識が欠けていた©Murachi Akira | This material provided by CC BY-NC-ND

開発者・運用者にとってのセキュリティ

セキュリティの当事者として守るべき情報資産脆弱性の存在あり得べき攻撃

セキュリティは「怖い」けれど「正しく怖がる」ことが必要過大評価も過小評価も禁物

を知る

セキュリティのおさらい

2017/2/2511 ©Murachi Akira | This material provided by CC BY-NC-ND

セキュリティって何？

一般的な意味としては安全確保・安全保障被害の防止

英語で有価証券を "securities" と言うのは、証券化＝出資の分散化により事業（貿易航海など）のリスクを分散化してきた歴史があるため

リスク、脅威、脆弱性

リスク

脆弱性

脅威

リスク：資産に対して損失や障害が生じる事態・状況が発現する可能性

脆弱性：資産に内在する、リスクを実際に発生させる要因

脅威：脆弱性を通じてリスクを発生させる手段や状況

資　　　産

情報セキュリティって何？

情報資産を対象としたセキュリティ情報の機密性、完全性、可用性を維持すること

機密性 (confidentiality) ：秘密を守る完全性 (integrity) ：改竄、破壊、消失しない可用性 (availability) ：必要な時に利用できる

+ α （拡張された定義）真正性 (authenticity) 責任追跡性 (accountability) 否認防止 (non-repudiation) 信頼性 (reliability) ※ JIS Q 27002 (ISO/IEC 27002) による定義

情報セキュリティにおける脅威

意図的な攻撃製品不具合（バグ）による障害発生人為的失敗（ミス）による障害発生災害（自然災害・人災）による

障害発生

インシデント

脅威によりリスクが具現化した事象侵入 / 改竄の検知情報漏洩 /流出の検知 DoS の検知ウイルス / マルウエア感染の検知物理的 /論理的障害の検知

脆弱性の発見 /検知（リスクが具現化する可能性が高いため）

Web アプリケーションをとりまく脅威Web アプリケーション / フロントエンドWeb アプリケーション / サーバーサイドアプリケーションフレームワーク

サーバーコンポーネントネットワーク / プロトコル

Web アプリケーションへの攻撃サーバー上の情報の窃取・漏洩サーバー上のシステム / データの改竄利用者データのクライアントからの窃取

（ ex. XSS ）なりすまし（ ex. CSRF ）他所への攻撃の踏み台（ ex. オープンリダイレクタ）

DoS （ Denial of Service ）ランサムウェア

どんな脅威があるのか（１）2010 2013

A1 – インジェクション A1 – インジェクション

A2 – クロスサイトスクリプティング (XSS) A2 – 認証とセッション管理の不備

A3 – 認証とセッション管理の不備 A3 – クロスサイトスクリプティング (XSS) A4 – 安全でないオブジェクト直接参照 A4 – 安全でないオブジェクト直接参照

A5 – クロスサイトリクエストフォージェリ (CSRF) A5 – セキュリティ設定のミス

A6 – セキュリティ設定のミス A6 – 機密データの露出 A7 – 安全でない暗号化データ保管 A7 – 機能レベルアクセス制御の欠落 A8 – URL アクセス制限の失敗 A8 – クロスサイトリクエストフォージェリ

(CSRF) A9 – 不十分なトランスポート層保護 A9 – 既知の脆弱性を持つコンポーネントの使用

A10 – 未検証のリダイレクトとフォーワード A10 – 未検証のリダイレクトとフォーワード

OWASP Top 10

https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Projecthttps://www.owasp.org/images/7/79/OWASP_Top_10_2013_JPN.pdf©Murachi Akira | This material provided by CC BY-NC-ND 19 2017/2/25

どんな脅威があるのか（２）

IPA 情報セキュリティ 10 大脅威 2017昨年順位個人順位組織昨年

順位

1位インターネットバンキングやクレジットカード情報の不正利用

1位標的型攻撃による情報流出 1位

2位ランサムウェアによる被害 2位ランサムウェアによる被害 7位

3位スマートフォンやスマートフォンアプリを狙った攻撃

3位ウェブサービスからの個人情報の窃取 3位

5位ウェブサービスへの不正ログイン 4位サービス妨害攻撃によるサービスの停止 4位

4位ワンクリック請求などの不当請求 5位内部不正による情報漏えいとそれに伴う業務停止

7位ウェブサービスからの個人情報の窃取 6位ウェブサイトの改ざん 5位

6位匿名によるネット上の誹謗・中傷 7位ウェブサービスへの不正ログイン 9位

8位情報モラル不足に伴う犯罪の低年齢化 8位 IoT 機器の脆弱性の顕在化ランク外

10位インターネット上のサービスを悪用した攻撃 9位攻撃のビジネス化（アンダーグラウンドサービス）

ランク外

ランク外 IoT 機器の不適切管理 10位インターネットバンキングや

クレジットカード情報の不正利用 8位

https://www.ipa.go.jp/security/vuln/10threats2017.html

守るべき「情報資産」資産に対する「脅威」

HTML5 Web アプリの「情報資産」

サービスの継続性アプリケーション提供の継続性アプリケーションレスポンスの品位維持 SLA

アプリケーションそのものサーバーサイドのソースコードサーバーサイドのデーターベースその他のアセット

ユーザーから預かる情報ユーザー個人情報パスワードハッシュ

サービスの継続性

アプリケーション提供の継続性アプリケーションのサービスが停止・中断し

てはいけないアプリケーションレスポンスの品位維持

ユーザーが苦痛を感じないレスポンスの品位を保たなければならない

SLA (Service Level Agreement)ユーザーとの契約は守らなければいけない

サービスの継続性への脅威

サーバーの破壊（侵入 / 物理攻撃）アプリケーションの停止 / パフォーマンス低下

サーバーの改竄 /不正利用（侵入 / インジェクション / 脆弱性経由）アプリケーションの乗っ取り（ページ改竄）踏み台として利用される

DoS (DDoS) アプリケーションの停止 / パフォーマンス低下

アプリケーションそのもの

サーバーサイドのソースコードビジネスロジック =営業秘密プレゼンテーションロジック =ノウハウの塊改竄 = アプリケーションの乗っ取り

サーバーサイドのデーターベース製品情報 /販売情報 / 価格情報

=文字通りの営業秘密その他のアセット

表示用のテキスト /画像など

アプリケーションそのものへの脅威

コードの漏洩（侵入 / 脆弱性経由）営業秘密 /ノウハウの流出

コード / アッセトの改竄（侵入 / インジェクション / 脆弱性経由）アプリケーションの乗っ取り = スニッフィング、攻撃者サイトへの誘導

データベースへの攻撃（インジェクション / 脆弱性経由）営業秘密 /ユーザー情報の流出・損失

ユーザーから預かる情報

ユーザー個人情報ユーザー登録情報（氏名、住所、メールアド

レス、カード番号…… etc. ）ユーザー入力フロントエンドの脆弱性に注意する所

パスワードハッシュ「パスワードそのもの」の保管は論外単純なハッシュはレインボーテーブルで解析可能

Salt + ハッシュストレッチングは必須

ユーザーから預かる情報への脅威

個人情報データーベースへの攻撃 SQL インジェクション侵入 / 脆弱性経由

パスワードハッシュデータベースへの攻撃 SQL インジェクション侵入 / 脆弱性経由

XSS によるユーザ情報の暴露 /漏洩 CSRF によるユーザ情報の暴露 /漏洩

脅威への対応

脅威への対処

脅威について知るここまでの話

脆弱性を作りこまないインシデントに正しく対処する

脆弱性を作りこまない

「脆弱性を作りこまない」

HTML5 Web アプリでありがちなフロントエンドの脆弱性クロスサイトスクリプティング (XSS)

　⇒ DOM based XSS既知の脆弱性を持つコンポーネントの使用

未検証のリダイレクトとフォーワード

XSS (DOM based XSS)

33 2017/2/25©Murachi Akira | This material provided by CC BY-NC-ND

クロスサイトスクリプティング外部入力を元にしたコンテンツの動的生成により実行可能なスクリプトが生成されWeb アプリケーションのセキュリ

ティコンテキストで実行されるセキュリティコンテキスト

= SOP (Same Origin Policy)= ユーザーの信頼

一般的な XSS のパターン攻撃ページの作成

ページ内のリンクをクリックサーバーに不正なユーザー入力を送信

攻撃者のスクリプトを含むページを送信

スクリプト実行©Murachi Akira | This material provided by CC BY-NC-ND 35 2017/2/25

XSS の攻撃コード例

この部分がサーバーサイドでページにそのまま埋め込まれて返される

DOM based XSS

攻撃ページの作成

ページ内のリンクをクリック

スクリプト実行

不正な入力値の提供

DOM 生成

DOM based XSS のコード例

https://www.owasp.org/index.php/DOM_Based_XSS より引用

DOM based XSS の発現…/page.html?

default=<script>alert(document.cookie)</script>"

document.location.href.indexOf("default=")+8)

取得される文字列 "<script>alert(document.cookie)</script>"

document.write("<script>alert(document.cookie)</script>“)

ブラウザーの XSS フィルターリクエストとレスポンスを比較して XSS を検出するとコード実効を抑止する機能

一般的な XSS : 〇検知・抑止できる場合が少なくない

DOM based XSS : × 検知・抑止できない場合が多い

DOM based XSS の実例（ 1 ）

に誘導参考 https://www.ipa.go.jp/files/000024729.pdf

参考 https://www.ipa.go.jp/files/000024729.pdf

http://utf-8.jp/public/20140908/owasp-hasegawa.pdf より引用

ハッシュ (# の後ろ ) はサーバーに送信されないので、サーバーでの検知ができないパターン

XSS - ソースとシンクソース (sources)DOM based XSS の攻撃コードが注入される場所

シンク　 (sinks)DOM based XSS の攻撃コードが JavaScript コードとして発現する場所

XSS - ソースからシンクへ

ユーザー入力ソースにセット

ソースから取得シンクに値を出力

XSS 発現

XSS - ソース (sources) location.hash location.search location.hrefdocument.cookiedocument.referrerwindow.nameWeb Storage IndexedDB

外部から操作可能なデータの源泉

XSS - シンク　 (sinks)innerHTMLlocation.hrefdocument.writeevalsetTimeout, setIntervalFunctionjQuery(), $(), $.html()

テキストの出力

コードの生成

実行

XSS - Mutation-based XSS (mXSS)DOM based XSS の変種

HTML element String HTML

elementinnerHTMLで取得

innerHTMLで書き出し

元の HTML と書きだした HTML が同一にならない

XSS - mXSS innerHTML / outerHTML を参照す

ると本来の DOM構造とは異なる文字列が取得される場合がある

取得した文字列をそのまま innerHTML / outerHTML などで出力すると、実行可能な JavaScript コードが生成される

XSS - Mutation-based XSS の例

http://utf-8.jp/public/20140908/owasp-hasegawa.pdf より引用

DOM based XSS の対策

XSS - DOM based XSS の対策 HTML 生成時にエスケープ

JavaScript Escape / HTML Escape / URL Escape

DOM 操作メソッド / プロパティの利用 URL 生成のスキームの限定 CSP （ Content Security Policy ）の利

用 Iframe sandbox の利用ライブラリの更新

（ライブラリに脆弱性があることも）©Murachi Akira | This material provided by CC BY-NC-ND 52 2017/2/25

XSS - DOM 操作メソッド / プロパティの利用createElement( )createTextElement( ) createTextNode( ) appendChild( ) insertBefor( )setAttribute( )

XSS - 逆に利用を避けるべき innerHTMLouterHTMLdocument.write( )document.writeln( )

String リテラルを組み立ててそのまま HTML として出力しないのが基本

XSS - URL 生成のスキームを限定するリンク（ URL ）の動的生成も危険 javascript: スキームなど任意の

スキームの URL を生成しないHTTP (HTTPS) の URL のみ生成す

XSS - CSP （ Content Security Policy ）ポリシーベースでスクリプトのロードと実行に強い制約を課す仕組み

XSS - CSP （ Content Security Policy ）の利用サーバーヘッダーContent-Security-Policyでポリシーを構成

Firefox, Chrome, Safari, Edge で利用可能 IE は IE10 以降で X-Content-Security-

Policy で部分的サポート

XSS - Content Security Policy の効果コンテンツを読み込むドメイン / プロトコルを制限できるコードインジェクションによる外部コンテンツの読み込みを防ぐ

インライン JavaScript を無効にする XSS / DOM base XSS の無効化

インラインイベントハンドラーを無効にする必要があれば外部スクリプトから

addEventListener() でハンドラーを設定する eval() も無効にする

XSS - Content Security Policy の設定例 Content-Security-Policy: default-src ‘self’

すべてのコンテンツをサイト自身のドメイン ( サブドメインを除く ) から読み込む

Content-Security-Policy: script-src ‘self’ スクリプトの読み込みをサイト自身のドメイン ( サブドメイン

を除く ) に制限する Content-Security-Policy: default-src ‘self’

*.mydomain.com サイト自身のドメインおよび、信頼されたドメインとそのすべ

てのサブドメインからのコンテンツを許可（それ以外は制限） Content-Security-Policy: default-src https://banking.

bank.com banking. bank.com サイトのすべてのコンテンツを SSL を使

用して読み込む©Murachi Akira | This material provided by CC BY-NC-ND 59 2017/2/25

XSS - Content Security Policy の利用は計画的に Content Security Policy は強力な分、副作用も強い

既存のアプリケーションに適用するのはハードルが高い

まずはContent-Security-Policy-Report-Onlyから

Content-Security-Policy-Report-Only

例Content-Security-Policy-Report-Only: ⏎default-src 'self'; ⏎report-uri http://example.com/csp-report

CSP違反レポートだけ report-uri で指定するサーバーに送信される（ブラウザーでのレンダリング、 JS 実行には影響を与えない）

違反レポートは簡単な JSON なので、サーバーは受信した JSON をデータベースに貯めるだけで OK

レポートを見て、直せるところから直す

（実際は 1行）

iframe sandbox の利用動的に生成する要素を iframe に封じ込める iframe に sandbox 要素を指定してフレーム内コンテンツに制限を掛ける

コンテンツを動的に生成

制限されたコンテンツ

XSS - iframe sandbox の設定例 <iframe sandbox src="frame1.html">

すべての制限を有効にする

XSS - iframe sandbox の効果許可の指定をしない限り強い制限フォームの動作不可スクリプト実行不可ポップアップの作成不可親コンテンツとは別のオリジンになる

(SOP の制限適用 )親レベルのコンテンツの読み込み・操作不

既知の脆弱性を持つコンポーネントの使用

既知の脆弱性を持つコンポーネントの使用最終的に信頼できるのは自分だけ

自分で書いたコンポーネント ( ライブラリ )だけ使う？

生産性でも信頼性でも現実的ではない

外部のコンポーネントには「脆弱性」があるかも

脆弱なコンポーネント – 必要以上に外部ライブラリに依存しないHTML5 で強化された機能を積極的

に利用することで外部ライブラリ依存は減らせる

単純な操作であればライブラリよりネイティブに書いた方が速い

脆弱なコンポーネント –最新のライブラリを使用 / 更新する作成時の「最新」 ⇒✖稼働時は「常に最新」 ⇒〇

脆弱性情報へのアンテナを張る最新のセキュリティ情報を把握する公開脆弱性データベース

JVN (Japan Vulnerability Notes) CVE (Common Vulnerabilities and Exposures) NVD (National Vulnerability Database)

ライブラリのプロジェクトのメーリングリストセキュリティ関連のメーリングリストセキュリティ系勉強会

セキュリティテストを実施する気づいていない脆弱性もテストで発見できる（かもしれない）

未検証のリダイレクトとフォーワード

未検証のリダイレクトとフォーワードオープンリダイレクターを作りこま

ない任意の場所へ遷移可能なフォーワーダーを作りこまない

リダイレクトとフォーワードの対策リダイレクトやフォーワードの使用を

できるかぎり避ける本当に必要ですか？

ユーザパラメータで遷移先を決定しない遷移先パラメータが必要な場合、提供さ

れた値の検証をおこなう遷移先を限定する

遷移先ドメインのリスト化

インシデントへの対処

インシデントが起きる理由

プログラム上の脆弱性組織マネジメントの脆弱性個人マネジメントの脆弱性

インシデント - 脆弱性の発見・報告

自社プログラム / サービスの脆弱性の発見・報告自社内で発見ユーザーや研究者から直接 IPA などの公的機関経由ネット上などで暴露

利用しているプラットフォームの脆弱性発見フレームワークの脆弱性データベースの脆弱性 OS / クラウドの脆弱性

インシデント - インシデントの発生

自社内で発生を発見外部からの報告

ユーザーや研究者から直接 IPA などの公的機関経由ネット上などで暴露

インシデント - 優先課題を切り分ける

優先するのは何？脆弱性の改修？ユーザーへの告知？

サービスを止める？ / 止めない？

判断基準は？

問題の深刻度を計測する

脆弱性の深刻度評価共通脆弱性評価システム CVSS概説

http://www.ipa.go.jp/security/vuln/CVSS.html CVSS 計算ツール

http://jvndb.jvn.jp/cvss/ScoreCalc2.swf?lang=ja 評価の着目点

攻撃の行いやすさ /成功しやすさ機密性・完全性・可用性への影響の大きさ発生する被害の大きさ

深刻度の評価は難しい

脆弱性の技術的詳細を理解しないと評価しにくい場合が少なくないしかし難解な場合も多い

公開されている CVSS が自組織に適合するとは限らない自組織固有の状況を考慮しなければならない

ユーザーに影響する場合、技術的な評価だけで判断できないユーザー心理に配慮しなければならない

評価の精度を上げるには

守るべき物＝自分（自社）のアプリケーション / システムの全体像を良く知る

脆弱性情報に親しむインシデント対応に慣れる

守るべきものの全体像を知る

利用しているテクノロジーを確認システムのインフラ

（サーバー OS/ ネットワーク /etc. ）ミドルウエア

（データベース /フレームワーク /etc. ）外部コンポーネント / ライブラリ

脆弱性情報へのアンテナを張る最新のセキュリティ情報を把握する公開脆弱性データベース

JVN (Japan Vulnerability Notes) CVE (Common Vulnerabilities and Exposures) NVD (National Vulnerability Database)

ライブラリのプロジェクトのメーリングリストセキュリティ関連のメーリングリストセキュリティ系勉強会

セキュリティ診断を実施するセキュリティ診断結果の評価は本番

インシデント評価に役立つ

予行演習を実施する

インシデント対応の予行演習を定期的に実施する

セキュリティの「防災訓練」

まとめ

本日の Agenda

HTML5 Web アプリケーションのセキュリティについて理解する守るべきものは何か何が脅威なのか脅威からどのように守るのかどのように脅威を正しく評価するのか

Call to Action IPA （情報処理推進機構）サイトのウオッチ

情報セキュリティhttps://www.ipa.go.jp/security/index.html

セキュア・プログラミング講座http://www.ipa.go.jp/security/awareness/vendor/

programming/ OWASP (Open Web Application Security Project ) を知

る Welcome to OWASP https://www.owasp.org/ OWASP Japan

https://www.owasp.org/index.php/Japan セキュアプログラミングの実践セキュリティ勉強会への参加

Web アプリセキュリティの参考図書・資料

体系的に学ぶ安全な Web アプリケーションの作り方脆弱性が生まれる原理と対策の実践 https://www.amazon.co.jp/dp/4797361190

徳丸浩の Web セキュリティ教室 https://www.amazon.co.jp/gp/product/

4822279987/ ブラウザハック

https://www.amazon.co.jp/dp/479814343X UTF-8.jp

http://utf-8.jp/ 安全なウェブサイトの作り方

https://www.ipa.go.jp/security/vuln/websecurity.html

勉強会情報 OWASP Night / OWASP Day

https://owasp.doorkeeper.jp/ 江戸前セキュリティ勉強会

https://sites.google.com/site/edomaesec/ Shibuya.XSS

http://shibuyaxss.connpass.com/ 脆弱性診断研究会

https://security-testing.doorkeeper.jp/

html5 web アプリケーションのセキュリティ

Technology

silk test 18 - micro focus · sap...

html5 tema4 atributos en html5

bangcle--世界最専門的なアプリケーション...

adobe air のセキュリティ1 最終更新日 2011/9/22...

industry trend of html5 in 2012 (2012년 html5 총정리)

サービス指向セキュリティ -...

html5 and security -...

html5 소개 및 배우기- html5 open conference

html5ではないサイトを html5へ - change html5 from...

ツール・アプリケーションmedia.kddi.com/app/publish/torisetsu/pdf/fjl22_torisetsu...ツール・アプリケーション...

· web viewapc smart-ups 1200 rm 1u lcd 100v 12...

開発者ファーストのアプリケーション...

2013년 html5 총정리 (summary of html5 trend in 2013)

html5 and security part 1 : basics and xss html5...

アプリケーション・デリバリ・コントローラへと進化 ·...

cisco ccie security...

アプリケーション...

デバイスwebapiコンソーシアム第7回技術wg...

ossossforum.jp/jossfiles/ss1.pdf · oss鳥瞰図2015...

1 html5 web - jpcert.or.jp · ―トピック1― html5...