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-ND3
 トレーニング、講習を承ります
 プログラミング系 (JavaScript、PHP、Java、VB、C#)
 IT スキル (Office、ネットワークなど) 系
 情報セキュリティ系
 情報処理技術者試験対策 (IT パスポート、初級、中級、情
報セキュリティマネジメント)
 情報セキュリティマネジメント、個人情報保護のコ
ンサルティングと技術支援を承ります
 コミュニティ「ネットワークパケットを読む会
（仮）」をやってます
 http://pa.hebikuzure.com/

Agenda
 HTML5 Web アプリケーションのセキュリティに
ついて理解する
 守るべきものは何か
 何が脅威なのか
 発生する脆弱性について理解する
 発生する脆弱性を防ぐ方法を理解する
 脅威からどのように守るのか
 どのように脅威を正しく評価するのか
©Murachi Akira | This material provided by CC BY-NC-ND4 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) による定義
C
AI

情報セキュリティにおける脅威
 意図的な攻撃
 製品不具合（バグ）による障害発生
 人為的失敗（ミス）による障害発生
 災害（自然災害・人災）による
障害発生

インシデント
 脅威によりリスクが具現化した事象
 侵入/改竄の検知
 情報漏洩/流出の検知
 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_Project
https://www.owasp.org/images/7/79/OWASP_Top_10_2013_JPN.pdf

どんな脅威があるのか（２）
IPA 情報セキュリティ10大脅威 2017
昨年
順位
個人順位組織
昨年
順位
1位
インターネットバンキングや
クレジットカード情報の不正利用
1位標的型攻撃による情報流出 1位
2位ランサムウェアによる被害 2位ランサムウェアによる被害 7位
3位
スマートフォンやスマートフォンアプリを狙っ
た攻撃
3位ウェブサービスからの個人情報の窃取 3位
5位ウェブサービスへの不正ログイン 4位サービス妨害攻撃によるサービスの停止 4位
4位ワンクリック請求などの不当請求 5位
内部不正による情報漏えいとそれに伴う
業務停止
2位
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 のパターン
攻撃ページの作成
ページ内のリンクをクリック
サーバーに不正な
ユーザー入力を送信
攻撃者のスクリプトを含む
ページを送信
スクリプト実行

XSS の攻撃コード例
<script>alert(‘hacked’)</script>
この部分がサーバーサイドでページに
そのまま埋め込まれて返される

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)</scri
pt>"
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.href
 document.cookie
 document.referrer
 window.name
 Web Storage
 IndexedDB
外部から操作可能な
データの源泉

XSS -シンク (sinks)
 innerHTML
 location.href
 document.write
 eval
 setTimeout, setInterval
 Function
 jQuery(), $(), $.html()
テキストの出力
コードの生成
実行

XSS - Mutation-based XSS (mXSS)
 DOM based XSS の変種
HTML element String HTML element
innerHTML
で取得
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 の利用
 ライブラリの更新
（ライブラリに脆弱性があることも）

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

XSS -逆に利用を避けるべき
 innerHTML
 outerHTML
 document.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 を使用し
て読み込む

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 要素を指定してフレーム
内コンテンツに制限を掛ける
コンテンツを
動的に生成
<iframe sandbox id="foo">
制限された
コンテンツ

XSS - iframe sandbox の設定例
 <iframe sandbox src="frame1.html">
 すべての制限を有効にする
 <iframe sandbox="allow-forms"
src="frame1.html">
 フォームの動作を許可する
 <iframe sandbox="allow-same-origin"
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/progra
mming/
 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 アプリケーションのセキュリティ

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

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

Similar a HTML5 Web アプリケーションのセキュリティ (20)

Más de 彰村地

Más de 彰村地 (20)

Último

Último (10)