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

1. 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/

2. 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

3. 宣伝 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/

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

5. 目次  はじめに  セキュリティのおさらい  守るべき「情報資産」・資産に対する「脅威」  脅威への対応  脆弱性を作りこまない  インシデントへの対処  まとめ ©Murachi Akira | This material provided by CC BY-NC-ND5 2017/2/25

6. はじめに 2017/2/25©Murachi Akira | This material provided by CC BY-NC-ND6

7. ありがちなシステム開発 2017/2/25©Murachi Akira | This material provided by CC BY-NC-ND7 システム開発頼むよ～要件定義は？ざっくりこんな感じ～が、がんばります…… 追加であれとこれとそれも～が、がんばります…… できましたヽ(^o^)丿欲しかったシステムじゃない(-_-;) ・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・

8. ありがちなセキュリティ 2017/2/25©Murachi Akira | This material provided by CC BY-NC-ND8 セキュリティ対策頼むよ～セキュリティポリシーは？ざっくりこんな感じ～が、がんばります…… 追加であれとこれとそれも～が、がんばります…… できましたヽ(^o^)丿欲しかったセキュリティじゃない(-_-;) ・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・

9. 2017/2/259 どうしてこうなった？開発者・運用者にセキュリティの当事者意識が欠けていた ©Murachi Akira | This material provided by CC BY-NC-ND

10. 開発者・運用者にとってのセキュリティ 2017/2/25©Murachi Akira | This material provided by CC BY-NC-ND10  セキュリティの当事者として  守るべき情報資産  脆弱性の存在  あり得べき攻撃  セキュリティは「怖い」けれど「正しく怖がる」ことが必要  過大評価も過小評価も禁物を知る

11. セキュリティのおさらい 2017/2/2511 ©Murachi Akira | This material provided by CC BY-NC-ND

12. セキュリティって何？ 2017/2/25©Murachi Akira | This material provided by CC BY-NC-ND12  一般的な意味としては 安全確保・安全保障 被害の防止  英語で有価証券を "securities" と言うのは、証券化＝出資の分散化により事業（貿易航海など）のリスクを分散化してきた歴史があるため

13. リスク、脅威、脆弱性 2017/2/25©Murachi Akira | This material provided by CC BY-NC-ND13 リスク脆弱性脅威リスク：資産に対して損失や障害が生じる事態・状況が発現する可能性脆弱性：資産に内在する、リスクを実際に発生させる要因脅威：脆弱性を通じてリスクを発生させる手段や状況資産

14. 情報セキュリティって何？ 2017/2/25©Murachi Akira | This material provided by CC BY-NC-ND14  情報資産を対象としたセキュリティ  情報の機密性、完全性、可用性を維持すること  機密性 (confidentiality)：秘密を守る  完全性 (integrity)：改竄、破壊、消失しない  可用性 (availability)：必要な時に利用できる  + α（拡張された定義）  真正性 (authenticity)  責任追跡性 (accountability)  否認防止 (non-repudiation)  信頼性 (reliability) ※ JIS Q 27002 (ISO/IEC 27002) による定義 C AI

15. 情報セキュリティにおける脅威 2017/2/25©Murachi Akira | This material provided by CC BY-NC-ND15  意図的な攻撃  製品不具合（バグ）による障害発生  人為的失敗（ミス）による障害発生  災害（自然災害・人災）による障害発生

16. インシデント 2017/2/25©Murachi Akira | This material provided by CC BY-NC-ND16  脅威によりリスクが具現化した事象  侵入/改竄の検知  情報漏洩/流出の検知  DoS の検知  ウイルス/マルウエア感染の検知  物理的/論理的障害の検知  脆弱性の発見/検知（リスクが具現化する可能性が高いため）

17. Web アプリケーションをとりまく脅威 Web アプリケーション/フロントエンド Web アプリケーション/サーバーサイドアプリケーションフレームワークサーバーコンポーネントネットワーク/プロトコル ©Murachi Akira | This material provided by CC BY-NC-ND17 2017/2/25

18. Web アプリケーションへの攻撃  サーバー上の情報の窃取・漏洩  サーバー上のシステム/データの改竄  利用者データのクライアントからの窃取（ex. XSS）  なりすまし（ex. CSRF）  他所への攻撃の踏み台（ex. オープンリダイレクタ）  DoS（Denial of Service）  ランサムウェア ©Murachi Akira | This material provided by CC BY-NC-ND18 2017/2/25

19. どんな脅威があるのか（１） 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 ©Murachi Akira | This material provided by CC BY-NC-ND19 2017/2/25

20. どんな脅威があるのか（２） 2017/2/25©Murachi Akira | This material provided by CC BY-NC-ND20 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

21. 守るべき「情報資産」資産に対する「脅威」 2017/2/2521 ©Murachi Akira | This material provided by CC BY-NC-ND

22. HTML5 Web アプリの「情報資産」 2017/2/25©Murachi Akira | This material provided by CC BY-NC-ND22  サービスの継続性  アプリケーション提供の継続性  アプリケーションレスポンスの品位維持  SLA  アプリケーションそのもの  サーバーサイドのソースコード  サーバーサイドのデーターベース  その他のアセット  ユーザーから預かる情報  ユーザー個人情報  パスワードハッシュ

23. サービスの継続性 2017/2/25©Murachi Akira | This material provided by CC BY-NC-ND23  アプリケーション提供の継続性  アプリケーションのサービスが停止・中断してはいけない  アプリケーションレスポンスの品位維持  ユーザーが苦痛を感じないレスポンスの品位を保たなければならない  SLA (Service Level Agreement)  ユーザーとの契約は守らなければいけない

24. サービスの継続性への脅威 2017/2/25©Murachi Akira | This material provided by CC BY-NC-ND24  サーバーの破壊（侵入/物理攻撃）  アプリケーションの停止/パフォーマンス低下  サーバーの改竄/不正利用（侵入/インジェクション/脆弱性経由）  アプリケーションの乗っ取り（ページ改竄）  踏み台として利用される  DoS (DDoS)  アプリケーションの停止/パフォーマンス低下

25. アプリケーションそのもの 2017/2/25©Murachi Akira | This material provided by CC BY-NC-ND25  サーバーサイドのソースコード  ビジネスロジック=営業秘密  プレゼンテーションロジック=ノウハウの塊  改竄=アプリケーションの乗っ取り  サーバーサイドのデーターベース  製品情報/販売情報/価格情報 =文字通りの営業秘密  その他のアセット  表示用のテキスト/画像など

26. アプリケーションそのものへの脅威 2017/2/25©Murachi Akira | This material provided by CC BY-NC-ND26  コードの漏洩（侵入/脆弱性経由）  営業秘密/ノウハウの流出  コード/アッセトの改竄（侵入/インジェクション/脆弱性経由）  アプリケーションの乗っ取り=スニッフィング、攻撃者サイトへの誘導  データベースへの攻撃（インジェクション/脆弱性経由）  営業秘密/ユーザー情報の流出・損失

27. ユーザーから預かる情報 2017/2/25©Murachi Akira | This material provided by CC BY-NC-ND27  ユーザー個人情報  ユーザー登録情報（氏名、住所、メールアドレス、カード番号……etc.）  ユーザー入力  フロントエンドの脆弱性に注意する所  パスワードハッシュ  「パスワードそのもの」の保管は論外  単純なハッシュはレインボーテーブルで解析可能  Salt + ハッシュストレッチングは必須

28. ユーザーから預かる情報への脅威 2017/2/25©Murachi Akira | This material provided by CC BY-NC-ND28  個人情報データーベースへの攻撃  SQL インジェクション  侵入/脆弱性経由  パスワードハッシュデータベースへの攻撃  SQL インジェクション  侵入/脆弱性経由  XSS によるユーザ情報の暴露/漏洩  CSRF によるユーザ情報の暴露/漏洩

29. 脅威への対応 2017/2/2529 ©Murachi Akira | This material provided by CC BY-NC-ND

30. 脅威への対処 2017/2/25©Murachi Akira | This material provided by CC BY-NC-ND30  脅威について知る  ここまでの話  脆弱性を作りこまない  インシデントに正しく対処する

31. 脆弱性を作りこまない 2017/2/2531 ©Murachi Akira | This material provided by CC BY-NC-ND

32. 「脆弱性を作りこまない」 2017/2/25©Murachi Akira | This material provided by CC BY-NC-ND32  HTML5 Webアプリでありがちなフロントエンドの脆弱性  クロスサイトスクリプティング (XSS) ⇒ DOM based XSS  既知の脆弱性を持つコンポーネントの使用  未検証のリダイレクトとフォーワード

33. XSS (DOM based XSS) 33 2017/2/25©Murachi Akira | This material provided by CC BY-NC-ND

34. クロスサイトスクリプティング  外部入力を元にした  コンテンツの動的生成により  実行可能なスクリプトが生成され  Web アプリケーションのセキュリティコンテキストで実行される  セキュリティコンテキスト = SOP (Same Origin Policy) = ユーザーの信頼 ©Murachi Akira | This material provided by CC BY-NC-ND34 2017/2/25

35. 一般的な XSS のパターン攻撃ページの作成ページ内のリンクをクリックサーバーに不正なユーザー入力を送信攻撃者のスクリプトを含むページを送信スクリプト実行 ©Murachi Akira | This material provided by CC BY-NC-ND35 2017/2/25

36. XSS の攻撃コード例 <script>alert(‘hacked’)</script> この部分がサーバーサイドでページにそのまま埋め込まれて返される ©Murachi Akira | This material provided by CC BY-NC-ND36 2017/2/25

37. DOM based XSS 攻撃ページの作成ページ内のリンクをクリックスクリプト実行不正な入力値の提供 DOM 生成 ©Murachi Akira | This material provided by CC BY-NC-ND37 2017/2/25

38. DOM based XSS のコード例 https://www.owasp.org/index.php/DOM_Based_XSS より引用 ©Murachi Akira | This material provided by CC BY-NC-ND38 2017/2/25

39. 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>“) ©Murachi Akira | This material provided by CC BY-NC-ND39 2017/2/25

40. ブラウザーの XSS フィルター  リクエストとレスポンスを比較して XSS を検出するとコード実効を抑止する機能  一般的な XSS : 〇検知・抑止できる場合が少なくない  DOM based XSS : × 検知・抑止できない場合が多い ©Murachi Akira | This material provided by CC BY-NC-ND40 2017/2/25

41. DOM based XSS の実例（1）に誘導参考 https://www.ipa.go.jp/files/000024729.pdf ©Murachi Akira | This material provided by CC BY-NC-ND41 2017/2/25

42. DOM based XSS の実例（2）参考 https://www.ipa.go.jp/files/000024729.pdf ©Murachi Akira | This material provided by CC BY-NC-ND42 2017/2/25

43. DOM based XSS の実例（3） http://utf-8.jp/public/20140908/owasp-hasegawa.pdf より引用ハッシュ (# の後ろ) はサーバーに送信されないので、サーバーでの検知ができないパターン ©Murachi Akira | This material provided by CC BY-NC-ND43 2017/2/25

44. XSS - ソースとシンク  ソース (sources) DOM based XSS の攻撃コードが注入される場所  シンク (sinks) DOM based XSS の攻撃コードが JavaScript コードとして発現する場所 ©Murachi Akira | This material provided by CC BY-NC-ND44 2017/2/25

45. XSS -ソースからシンクへ 2017/2/25©Murachi Akira | This material provided by CC BY-NC-ND45 ユーザー入力ソースにセットソースから取得シンクに値を出力 XSS 発現

46. XSS -ソース (sources)  location.hash  location.search  location.href  document.cookie  document.referrer  window.name  Web Storage  IndexedDB 外部から操作可能なデータの源泉 ©Murachi Akira | This material provided by CC BY-NC-ND46 2017/2/25

47. XSS -シンク (sinks)  innerHTML  location.href  document.write  eval  setTimeout, setInterval  Function  jQuery(), $(), $.html() テキストの出力コードの生成実行 ©Murachi Akira | This material provided by CC BY-NC-ND47 2017/2/25

48. XSS - Mutation-based XSS (mXSS)  DOM based XSS の変種 HTML element String HTML element innerHTML で取得 innerHTML で書き出し元の HTML と書きだした HTML が同一にならない ©Murachi Akira | This material provided by CC BY-NC-ND48 2017/2/25

49. XSS - mXSS  innerHTML / outerHTML を参照すると本来のDOM構造とは異なる文字列が取得される場合がある  取得した文字列をそのまま innerHTML / outerHTML などで出力すると、実行可能な JavaScript コードが生成される ©Murachi Akira | This material provided by CC BY-NC-ND49 2017/2/25

50. XSS - Mutation-based XSS の例 http://utf-8.jp/public/20140908/owasp-hasegawa.pdf より引用 ©Murachi Akira | This material provided by CC BY-NC-ND50 2017/2/25

51. DOM based XSS の対策 51 2017/2/25©Murachi Akira | This material provided by CC BY-NC-ND

52. 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-ND52 2017/2/25

53. XSS - DOM 操作メソッド/プロパティの利用  createElement( )  createTextElement( )  createTextNode( )  appendChild( )  insertBefor( )  setAttribute( ) ©Murachi Akira | This material provided by CC BY-NC-ND53 2017/2/25

54. XSS -逆に利用を避けるべき  innerHTML  outerHTML  document.write( )  document.writeln( )  String リテラルを組み立ててそのまま HTML として出力しないのが基本 ©Murachi Akira | This material provided by CC BY-NC-ND54 2017/2/25

55. XSS - URL 生成のスキームを限定する  リンク（URL）の動的生成も危険  javascript: スキームなど任意のスキームのURLを生成しない  HTTP (HTTPS) のURLのみ生成する ©Murachi Akira | This material provided by CC BY-NC-ND55 2017/2/25

56. XSS - CSP（Content Security Policy）  ポリシーベースでスクリプトのロードと実行に強い制約を課す仕組み ©Murachi Akira | This material provided by CC BY-NC-ND56 2017/2/25

57. XSS - CSP（Content Security Policy）の利用  サーバーヘッダー Content-Security-Policy でポリシーを構成  Firefox, Chrome, Safari, Edge で利用可能  IE は IE10 以降で X-Content-Security-Policy で部分的サポート ©Murachi Akira | This material provided by CC BY-NC-ND57 2017/2/25

58. XSS - Content Security Policy の効果  コンテンツを読み込むドメイン / プロトコルを制限できる  コードインジェクションによる外部コンテンツの読み込みを防ぐ  インライン JavaScript を無効にする  XSS / DOM base XSS の無効化  インラインイベントハンドラーを無効にする  必要があれば外部スクリプトから addEventListener() でハンドラーを設定する  eval() も無効にする ©Murachi Akira | This material provided by CC BY-NC-ND58 2017/2/25

59. 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-ND59 2017/2/25

60. XSS - Content Security Policy の利用は計画的に  Content Security Policy は強力な分、副作用も強い  既存のアプリケーションに適用するのはハードルが高い  まずは Content-Security-Policy-Report-Only から ©Murachi Akira | This material provided by CC BY-NC-ND60 2017/2/25

61. Content-Security-Policy-Report-Only 2017/2/25©Murachi Akira | This material provided by CC BY-NC-ND61  例 Content-Security-Policy-Report-Only: ⏎ default-src 'self'; ⏎ report-uri http://example.com/csp-report  CSP違反レポートだけ report-uri で指定するサーバーに送信される（ブラウザーでのレンダリング、JS 実行には影響を与えない）  違反レポートは簡単な JSON なので、サーバーは受信した JSON をデータベースに貯めるだけで OK  レポートを見て、直せるところから直す（実際は1行）

62. iframe sandbox の利用  動的に生成する要素を iframe に封じ込める  iframe に sandbox 要素を指定してフレーム内コンテンツに制限を掛けるコンテンツを動的に生成 <iframe sandbox id="foo"> 制限されたコンテンツ ©Murachi Akira | This material provided by CC BY-NC-ND62 2017/2/25

63. XSS - iframe sandbox の設定例  <iframe sandbox src="frame1.html">  すべての制限を有効にする  <iframe sandbox="allow-forms" src="frame1.html">  フォームの動作を許可する  <iframe sandbox="allow-same-origin" src="frame1.html">  フレーム内コンテンツを親と同じオリジンと見做す ©Murachi Akira | This material provided by CC BY-NC-ND63 2017/2/25

64. XSS - iframe sandbox の効果  許可の指定をしない限り強い制限  フォームの動作不可  スクリプト実行不可  ポップアップの作成不可  親コンテンツとは別のオリジンになる (SOP の制限適用)  親レベルのコンテンツの読み込み・操作不可 ©Murachi Akira | This material provided by CC BY-NC-ND64 2017/2/25

66. 既知の脆弱性を持つコンポーネントの使用最終的に信頼できるのは自分だけ自分で書いたコンポーネント(ライブラリ)だけ使う？生産性でも信頼性でも現実的ではない外部のコンポーネントには「脆弱性」があるかも ©Murachi Akira | This material provided by CC BY-NC-ND66 2017/2/25

67. 脆弱なコンポーネント – 必要以上に外部ライブラリに依存しない  HTML5 で強化された機能を積極的に利用することで外部ライブラリ依存は減らせる  単純な操作であればライブラリよりネイティブに書いた方が速い ©Murachi Akira | This material provided by CC BY-NC-ND67 2017/2/25

68. 脆弱なコンポーネント – 最新のライブラリを使用/更新する  作成時の「最新」 ⇒✖  稼働時は「常に最新」 ⇒〇 ©Murachi Akira | This material provided by CC BY-NC-ND68 2017/2/25

69. 脆弱性情報へのアンテナを張る  最新のセキュリティ情報を把握する  公開脆弱性データベース  JVN (Japan Vulnerability Notes)  CVE (Common Vulnerabilities and Exposures)  NVD (National Vulnerability Database)  ライブラリのプロジェクトのメーリングリスト  セキュリティ関連のメーリングリスト  セキュリティ系勉強会 ©Murachi Akira | This material provided by CC BY-NC-ND69 2017/2/25

72. 未検証のリダイレクトとフォーワード  オープンリダイレクターを作りこまない  任意の場所へ遷移可能なフォーワーダーを作りこまない ©Murachi Akira | This material provided by CC BY-NC-ND72 2017/2/25

73. リダイレクトとフォーワードの対策  リダイレクトやフォーワードの使用をできるかぎり避ける  本当に必要ですか？  ユーザパラメータで遷移先を決定しない  遷移先パラメータが必要な場合、提供された値の検証をおこなう  遷移先を限定する  遷移先ドメインのリスト化 ©Murachi Akira | This material provided by CC BY-NC-ND73 2017/2/25

75. インシデントが起きる理由 2017/2/25©Murachi Akira | This material provided by CC BY-NC-ND75  プログラム上の脆弱性  組織マネジメントの脆弱性  個人マネジメントの脆弱性

76. インシデント - 脆弱性の発見・報告 2017/2/25©Murachi Akira | This material provided by CC BY-NC-ND76  自社プログラム/サービスの脆弱性の発見・報告  自社内で発見  ユーザーや研究者から直接  IPA などの公的機関経由  ネット上などで暴露  利用しているプラットフォームの脆弱性発見  フレームワークの脆弱性  データベースの脆弱性  OS / クラウドの脆弱性

77. インシデント - インシデントの発生 2017/2/25©Murachi Akira | This material provided by CC BY-NC-ND77  自社内で発生を発見  外部からの報告  ユーザーや研究者から直接  IPA などの公的機関経由  ネット上などで暴露

78. インシデント - 優先課題を切り分ける 2017/2/25©Murachi Akira | This material provided by CC BY-NC-ND78  優先するのは何？  脆弱性の改修？  ユーザーへの告知？  サービスを止める？/止めない？判断基準は？

79. 問題の深刻度を計測する 2017/2/25©Murachi Akira | This material provided by CC BY-NC-ND79  脆弱性の深刻度評価  共通脆弱性評価システムCVSS概説 http://www.ipa.go.jp/security/vuln/CVSS.html  CVSS 計算ツール http://jvndb.jvn.jp/cvss/ScoreCalc2.swf?lang=ja  評価の着目点  攻撃の行いやすさ/成功しやすさ  機密性・完全性・可用性への影響の大きさ  発生する被害の大きさ

80. 深刻度の評価は難しい 2017/2/25©Murachi Akira | This material provided by CC BY-NC-ND80  脆弱性の技術的詳細を理解しないと評価しにくい場合が少なくない  しかし難解な場合も多い  公開されている CVSS が自組織に適合するとは限らない  自組織固有の状況を考慮しなければならない  ユーザーに影響する場合、技術的な評価だけで判断できない  ユーザー心理に配慮しなければならない

81. 評価の精度を上げるには 2017/2/25©Murachi Akira | This material provided by CC BY-NC-ND81  守るべき物＝自分（自社）のアプリケーション/システムの全体像を良く知る  脆弱性情報に親しむ  インシデント対応に慣れる

82. 守るべきものの全体像を知る 2017/2/25©Murachi Akira | This material provided by CC BY-NC-ND82  利用しているテクノロジーを確認  システムのインフラ（サーバーOS/ネットワーク/etc.）  ミドルウエア（データベース/フレームワーク/etc. ）  外部コンポーネント/ライブラリ

83. 脆弱性情報へのアンテナを張る  最新のセキュリティ情報を把握する  公開脆弱性データベース  JVN (Japan Vulnerability Notes)  CVE (Common Vulnerabilities and Exposures)  NVD (National Vulnerability Database)  ライブラリのプロジェクトのメーリングリスト  セキュリティ関連のメーリングリスト  セキュリティ系勉強会 ©Murachi Akira | This material provided by CC BY-NC-ND83 2017/2/25

87. 本日の Agenda ©Murachi Akira | This material provided by CC BY-NC-ND87 2017/2/25  HTML5 Web アプリケーションのセキュリティについて理解する 守るべきものは何か 何が脅威なのか 脅威からどのように守るのか どのように脅威を正しく評価するのか

88. 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  セキュアプログラミングの実践  セキュリティ勉強会への参加 ©Murachi Akira | This material provided by CC BY-NC-ND88 2017/2/25

89. Web アプリセキュリティの参考図書・資料 2017/2/25©Murachi Akira | This material provided by CC BY-NC-ND89  体系的に学ぶ安全な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

90. 勉強会情報  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/ ©Murachi Akira | This material provided by CC BY-NC-ND90 2017/2/25

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

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

Recommended

More Related Content

What's hot

What's hot(20)

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

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

More from 彰村地

More from 彰村地(20)

Recently uploaded

Recently uploaded(8)