Tweet
Tweet

Slide 1

Slide 1 text

開運研修 2023 セキュリティ

Slide 2

Slide 2 text

⽬次 ▌ PSIRTの紹介 ▌ 情報セキュリティの基礎 n CIA、情報資産・脆弱性・脅威 n CVE、CWE、CVSS ▌ Webの脆弱性を知る n SQLインジェクション n XSS n CSRF ▌ ブラウザが提供するセキュリティ機能 ▌ まとめとおまけ

Slide 3

Slide 3 text

この時間の⽬的 ▌情報セキュリティの3要素を知る ▌CVE、CWE、CVSSが何かを知る ▌具体的な脆弱性の原因や対策を知る ▌脆弱性をより正しく理解し、対策するための基礎を⾝に着けてもらう

Slide 4

Slide 4 text

PSIRTの紹介

Slide 5

Slide 5 text

PSIRTとは ▌PSIRT = Product Security Incident Response Team ▌製品のセキュリティ品質向上やインシデント対応・⽀援などを⾏うチーム ▌チームの理想: n エンドユーザに安全にサイボウズ製品を使えると⾔ってもらう n 開発チームにセキュリティ品質に⾃信を持って製品をリリースできると ⾔ってもらう ▌サイボウズのPSIRTは対外的にはCy-PSIRTとして活動している

Slide 6

Slide 6 text

PSIRTの活動 ▌製品の脆弱性検証(脆弱性診断) ▌検出された脆弱性の評価・報告・公開 ▌第三者機関による脆弱性検証の依頼 n 監査結果を公開:https://www.cybozu.com/jp/productsecurity/ ▌製品で利⽤されるOSSの管理・脆弱性情報の収集 ▌サイボウズ脆弱性報奨⾦制度の運営 ▌インシデントハンドリング対応

Slide 7

Slide 7 text

サイボウズ脆弱性報奨⾦制度 ▌外部のセキュリティ専⾨家に脆弱性を報告していただいたら、その脆弱性 に応じて報奨⾦をお⽀払いする制度 n https://cybozu.co.jp/products/bug-bounty/ ▌報告された脆弱性の調査や再現確認の実施や様々な施策の運営業 務をPSIRTで対応 n 施策の例: バグハン合宿 https://blog.cybozu.io/entry/2019/07/02/080000 7

Slide 8

Slide 8 text

CSIRT(セキュリティ室)との違い ▌サイボウズにはCSIRTもある n CSIRT:Computer Security Incident Response Team n サイボウズのCSIRTは「セキュリティ室」と呼ばれています。 ▌セキュリティ室は会社の情報セキュリティ n 「端末を紛失した︕」「不審なメールが届いた︕」など n ISMSやISMAPの対応もしている ▌セキュリティ室とPSIRTは連携して動くことも

Slide 9

Slide 9 text

情報セキュリティの基礎

Slide 10

Slide 10 text

情報セキュリティの３要素 ▌情報セキュリティとは「CIA(機密性、完全性、可⽤性)」を維持すること Confidentiality 認可されていない個⼈、 エンティティまたはプロセスに 対して、情報を使⽤させず、 また開⽰しない特性。 Integrity 正確さ及び完全さの特性。 Availability 認可されたエンティティが要 求したときに、アクセス及び使 ⽤が可能である特性。

Slide 11

Slide 11 text

情報資産 ▌情報セキュリティで保護すべき対象 n PC・スマートフォン n 設備 n 印刷物 n 情報 n ⼈ 情報資産

Slide 12

Slide 12 text

脆弱性 ▌セキュリティ上の問題箇所 n ソフトウェア製品の本来の機能や性能を損なう原因となりうる箇所 n 不適切な運⽤により、セキュリティが維持できなくなっている状態 脆弱性

Slide 13

Slide 13 text

脅威 ▌組織に損害を与える可能性のある潜在的な原因 n 外部からの攻撃 n ⾃然災害 n ⼈的ミス ▌脅威が脆弱性をつくことでリスクが発⽣する 脅威 リスクが発⽣

Slide 14

Slide 14 text

CWE・CVE・CVSS

Slide 15

Slide 15 text

共通脆弱性タイプ⼀覧 CWE ▌CWE(Common Weakness Enumeration) n ⾮営利団体のMITREが中⼼となって策定しているソフトウェアにおけ るセキュリティ上の脆弱性の識別番号 n 例 n CWE-89:SQLインジェクション n CWE-352:CSRF ▌参考情報 n https://www.ipa.go.jp/security/vuln/CWE.html

Slide 16

Slide 16 text

共通脆弱性識別⼦ CVE ▌CVE（Common Vulnerabilities and Exposures) n ⾮営利団体のMITREが中⼼となって採番している、 個々の脆弱性を識別する番号 n 例 n CVE-2014-6271:ShellShock(bash) n CVE-2022-22965:Spring4shell(Spring Framework) ▌参考情報 n https://www.ipa.go.jp/security/vuln/CVE.html

Slide 17

Slide 17 text

脆弱性の評価 CVSS ▌CVSS（Common Vulnerability Scoring System） n 脆弱性の深刻度を数値化するための汎⽤的な仕組み n CVSSがあれば、世の中にある様々な脆弱性の深刻度を同じものさしで⽐較 できる n v2、v3、v3.1が存在している n v2とv3は評価項⽬や評価⽅法が異なる n v4の検討も始まっている n 参考情報: FIRST https://www.first.org/cvss/

Slide 18

Slide 18 text

脆弱性の評価 CVSSv3 ▌CVSSでは基本値、環境値、現状値の3種類の基準で脆弱性を評価 ▌基本値は、CIAに以下の５項⽬を加え、計8項⽬で脆弱性を評価 n 攻撃経路(AV):ネットワーク or 隣接 or ローカル or 物理 n 攻撃の複雑さ(AC):低 or ⾼ n 攻撃に必要な権限(PR):なし or 低 or ⾼ n 被害者の操作の有無(UI):不要 or 要 n 影響の範囲(S):変更なし or 変更あり ▌基本値は0.0-10.0の値＋それぞれの評価項⽬で表現される n 例︓4.3(CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N) ▌参考情報: https://www.ipa.go.jp/security/vuln/CVSSv3.html

Slide 19

Slide 19 text

Webの脆弱性

Slide 20

Slide 20 text

CWE-89 SQLインジェクション ▌SQLインジェクションとは n Webアプリケーションを通じて任意のSQL⽂をデータベースに対して発 ⾏できる脆弱性 ▌原理 n 攻撃者によるSQL⽂の構造を破壊するような⼊⼒を、アプリケーション が適切に処理せずにSQL⽂が発⾏されることで予期しないSQL⽂が 実⾏される。

Slide 21

Slide 21 text

SQLインジェクション例 ▌SQL ⽂の構造を破壊され WHERE 句で指定される条件が常に「真」 になり、情報が漏えいします。 診断時には AND(ʻ and 1=0) を使うことが推奨です。 SELECT * FROM tbl_user WHERE id =ʻ{$_GET[ʻidʼ]}ʼ ʼ OR 1=1 -- id =ʻʼ OR 1=1 --ʼ

Slide 22

Slide 22 text

SQLインジェクションの原因と対策 原因 ユーザーが⼊⼒した⽂字列を適切にエスケープしていない 対策 静的プレースホルダやテンプレートエンジン等、フレームワークの⽀援機構を利 ⽤する 参照︓IPA「安全なSQLの呼び出し⽅」 https://www.ipa.go.jp/files/000017320.pdf

Slide 23

Slide 23 text

CWE-79 クロスサイトスクリプティング(XSS) ▌XSSとは n Webアプリケーションを通じて任意のスクリプトを利⽤者のブラウザで実⾏させる 脆弱性 ▌原理 n HTMLタグの構造を破壊する⼊⼒をすることでスクリプトが実⾏される ▌種類 n 蓄積型 XSS:攻撃コードがDBなどに保存されている n 反射型 XSS:攻撃コードがリクエストに含まれる n DOM-Based XSS:DOM操作時に発⽣する

Slide 24

Slide 24 text

反射型XSSの例 URL: index.php?name=AAA AAAさん

さん

GETリクエストパラメーター の値をそのまま表⽰させる index.php?name=alert(1) alert(1)さん

Slide 25

Slide 25 text

XSSの原因と対策 原因 • ⼊⼒値のエスケープ漏れ • ⽂字コードやコンテンツ型の⾃動判別への理解不⾜ 対策 • ⼊⼒値を正しくエスケープする • ⽂字コードは必ず宣⾔する • コンテンツ型が HTML と判定されないようにする

Slide 26

Slide 26 text

DOM-Based XSS について ▌DOM-Based XSSを構成する「ソース」と「シンク」 n ソース︓攻撃者によってスクリプトを埋め込まれる可能性のある箇所 n location.href, location.search, window.name など n シンク︓ソースに含まれる⽂字列を⽤いることで実際にXSSの原因と なる箇所 n document.write, element.innerHTML, $.html(), eval など

Slide 27

Slide 27 text

DOM-Based XSS の例
const txt = decodeURIComponent(location.hash.substring(1)); // ソース document.getElementById(“sample”).innerHTML = txt; // シンク 以下のようなURLにアクセスするとXSSが発⽣する http://xxx/test.html#

Slide 28

Slide 28 text

DOM-Based XSSに特化した対策 ▌Trusted Types n CSPで「trusted types」を指定することでシンクに代⼊できる値の型をTrusted Types型に制限することができる。 n Trusted Types型以外がシンクを経由して代⼊されそうになるとエラーになる。 n 注意 n 対応しているブラウザが少ない n https://caniuse.com/?search=trustedtype n Trusted Typesでの定義するエスケープ処理が適切でないとDOM-based XSSは防げない n 参考情報︓ https://chromium.googlesource.com/chromium/src/+/master/ docs/trusted_types_on_webui.md

Slide 29

Slide 29 text

CWE-352 クロスサイトリクエストフォージェリ (CSRF) ▌CSRFとは n 被害者に罠リンクをクリックさせることで意図しない処理を実⾏させる 脆弱性

Slide 30

Slide 30 text

CSRF例（対策前) パスワード変更 ページへ遷移を クリック /password-reset 新しい パスワードを⼊ ⼒ /password-update pass=abc 罠リンク /password-update pass=hacked_password →攻撃者が⽤意したパスワードに更新される クリック

Slide 31

Slide 31 text

CSRF例（対策後） csrf_token=6aS8... /password-update pass=abc csrf_token=6aS8... 罠リンク クリック /password_update pass=hacked_password →攻撃者はcsrf_tokenがわからないのでパス ワードの変更ができない × パスワード変更 ページへ遷移を クリック /password-reset 新しい パスワードを⼊ ⼒

Slide 32

Slide 32 text

CSRFの原因と対策 原因 • CSRF対策チケットが発⾏・検証されていない • または X-Requested-With ヘッダが付与・検証されていない。[補⾜1] • CSRF対策チケットの強度が弱い 対策 • ⼗分強度のあるCSRF対策チケットの付与、検証を⾏う • またはX-Requested-Withヘッダの付与・検証を⾏う • 実績のあるフレームワークを使う • CookieにSameSiteの設定をする(⼀部のCSRF攻撃以外には有効)

Slide 33

Slide 33 text

[補⾜] SameSiteについて ▌リクエスト元に応じてクッキーをセットするかを指定できるCookieの属性値です。 ▌None、Lax、Strictの3つが存在する。 n None: 全てのリクエストにCookieが付与される。 n Lax: ⼀部を除いて発⾏元と宛先が同⼀サイト以外のリクエストにはCookieが付与されない。 n 同⼀サイト以外でもトップレベルナビゲーション(フォームやリンクでの遷移など)による GETリクエストではCookieが付与されます。 n Strict: 発⾏元と宛先が同⼀サイト以外のリクエストでは全てCookieが付与されない。 ▌⼀部のブラウザではSameSite属性を指定しなかった場合、Laxが指定されます。

Slide 34

Slide 34 text

[補⾜] SameSiteとCSRF ▌SameSiteがCSRF対策と⾔われる理由 n SamesiteにLaxが指定された場合、トップレベルナビゲーションかつGETリ クエストの場合を除いて、発⾏元と宛先が同⼀サイトでない場合には Cookieが付与されません。 n そのため、Cookieで保管されているセッションID等も付与されなくなるため、 サービス側でリクエストを正常に処理されないため、CSRF攻撃が成⽴しなく なります。 ▌リンク遷移によるGETメソッドを⽤いたCSRF攻撃などは防げません。 ▌参考︓https://blog.tokumaru.org/2022/01/impact-conditions- for-no-CSRF-protection-sites.html

Slide 35

Slide 35 text

ブラウザが提供するセキュリティ機構

Slide 36

Slide 36 text

ブラウザが提供するセキュリティ機構について ▌Same-Origin Policy （SOP） n (スキーム, ホスト名, ポート番号)の組が異なる場合、DOMの参照や通信 の⼀部を禁⽌する。 [補⾜2] n (スキーム, ホスト名, ポート番号)の組のことをOriginと呼ぶ。 n Originが同⼀の時、Same-Origin、 異なる時Cross-Originと呼ぶ。 ▌Content Security Policy（CSP） n サーバーサイドWebアプリケーションが課した制約に違反する挙動をWebブ ラウザが検出する n 指定されたjavascript以外読み込まないなど。 n 詳細:https://developer.mozilla.org/ja/docs/Web/HTTP/CSP

Slide 37

Slide 37 text

セキュリティ機能 ▌ブラウザのセキュリティ機能として、以下を指定することができます n X-Content-Type-Options n 指定したMIMEタイプに従う n X-Frame-Options n iframeの中に表⽰していいかを⽰す n クリックジャッキング対策 n Content-Disposition: attachment; n 内容が添付ファイルかインラインのデータとして扱うかを制御する n Strict-Transport-Security n HTTPSを強制する

Slide 38

Slide 38 text

Cookieの扱い ▌Cookieの発⾏時に属性を指定することで扱いを制限できる。［補⾜3］ n Expires:絶対的な有効期限を指定 n Max-Age:相対的な有効期限を指定 n Domain:利⽤可能なホストを指定 n Path:利⽤可能なパスを指定 n Secure:HTTPSを利⽤しているときにのみ送信される n HttpOnly:jsなどからの呼び出し禁⽌ n SameSite:リクエスト元に応じてクッキーをセットするかを指定 n もっと詳しく知りたい︓ https://developer.mozilla.org/ja/docs/Web/HTTP/Cookies

Slide 39

Slide 39 text

まとめ ▌情報セキュリティはCIA(機密性・完全性・可⽤性)を維持すること。 ▌脆弱性を作り込まない基本的な対策は、ユーザーの⼊⼒は信⽤せず、 実績のあるフレームワーク等の機構を⽤いて適切にエスケープやサニタイ ズを⾏う。 ▌ブラウザの機能で⼀部の脆弱性の脅威は緩和されるが、過信せずにクラ イアントサイド/サーバーサイドのWebアプリケーション側で対策を⾏う。

Slide 40

Slide 40 text

もっと勉強したい⼈のためのWeb資料 ▌安全なウェブサイトの作り⽅ http://www.ipa.go.jp/security/vuln/websecurity.html ▌Webアプリケーション脆弱性診断ガイドライン https://github.com/OWASP/www-chapter- japan/tree/master/secreq ▌OWASP チートシート https://www.owasp.org/index.php/OWASP_Cheat_Sheet_Ser ies ▌OWASP Top 10 2021 https://owasp.org/Top10/ja/

Slide 41

Slide 41 text

もっと勉強したい⼈のための本 ▌徳丸浩『体系的に学ぶ 安全なWebアプリケーションの作り⽅ 第2版 脆 弱性が⽣まれる原理と対策の実践』 SBクリエイティブ ▌⽶内貴志『Webブラウザセキュリティ Webアプリケーションの安全性を⽀ える仕組みを整理する』 ラムダノート ▌上野宣『Webセキュリティ担当者のための脆弱性診断スタートガイド 第 ⼆版 上野宣が教える情報漏えいを防ぐ技術』 翔泳社

Slide 42

Slide 42 text

補⾜

Slide 43

Slide 43 text

補⾜① [補⾜1] 通常SOPではformタグのリクエストは制限されません。 しかし、リクエストにX-Requested-Withヘッダの付与することを条件にするとformタグでのリクエストの送出はできな くなり、fetch等のAPIを使う必要があります。さらに、プリフライトリクエストが必要になるため、SOPの制限を受けます。 つまり攻撃者がX-Requested-Withヘッダを付与する罠リンクを攻撃対象のサイトのSame-Originに配置しなけれ ばならないため、SOPが適切に機能するブラウザではCSRFの対策になります。 [補⾜2] リクエストには、「シンプルリクエスト」「プリフライトリクエスト」があります。 SOPで禁⽌されるのはプリフライトリクエストが必要になるリクエストの場合です。 https://developer.mozilla.org/ja/docs/Web/HTTP/CORS#simple_requests

Slide 44

Slide 44 text

補⾜② [補⾜3] 多くのセキュリティ機構はOriginをベースに設定されていますが、Cookieが提案された当初はOriginの考えが定着し ておらず、現在となってはCookieはやや特殊なセキュリティ境界を持っています。SameSite属性はOriginに近い考 えを適⽤できますが、若⼲異なります。 詳細︓ https://tools.ietf.org/html/rfc6265 https://tools.ietf.org/html/draft-ietf-httpbis-rfc6265bis-07 https://web.dev/same-site-same-origin/

Slide 45

Slide 45 text

脆弱性の評価 CVSSv3 例 ▌ 脆弱性︓攻撃者が⽤意した罠リンクをクリックすると意図せずパスワードが変 更されるCSRF。 n 攻撃経路(AV):ネットワーク or 隣接 or ローカル or 物理 n 攻撃の複雑さ(AC):低 or ⾼ n 攻撃に必要な権限(PR):なし or 低 or ⾼ n 被害者が操作を必要か(UI):不要 or 要 n 影響の範囲(S):変更なし or 変更あり n 機密性の侵害(C):なし or 低 or ⾼ n 完全性の侵害(I):なし or 低 or ⾼ n 可⽤性の侵害(A):なし or 低 or ⾼