PSIRT 開運研修 2022 セキュリティ

もくじ PSIRTの紹介 情報セキュリティの基礎 CVE、CWE、CVSS 脆弱性を知る SQLインジェクション XSS CSRF ブラウザが提供するセキュリティ機能 まとめとおまけ資料

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

PSIRTとは PSIRT = Product Security Incident Response Team 製品のセキュリティ品質向上やインシデント対応・⽀援などを⾏うチーム サイボウズのPSIRTは対外的にはCy-PSIRTとして活動している

Cy-PSIRTの活動 サイボウズ製品の脆弱性検証 第三者機関による脆弱性検証 社内検証に加え、２つのセキュリティ監査/検証を実施しています。 監査結果は公開中︓https://www.cybozu.com/jp/productsecurity/ 検出された脆弱性の評価 製品で利⽤されるOSSの脆弱性情報の収集 製品関連の⼤きな脆弱性が発覚した際の社内調整 脆弱性報奨⾦制度の運⽤ 外部のセキュリティ専⾨家に脆弱性を報告していただいたら、その脆弱性に応じて 報奨⾦をお⽀払いする制度

CSIRT(セキュリティ室)との違い サイボウズにはCSIRTもある CSIRT:Computer Security Incident Response Team サイボウズのCSIRTは「セキュリティ室」と呼ばれています。 セキュリティ室は会社の情報セキュリティ セキュリティ室とPSIRTは連携して動くことも

Webセキュリティ

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

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

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

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

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

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

脆弱性の評価 CVSS CVSS（Common Vulnerability Scoring System） 脆弱性の深刻度を数値化するための汎⽤的な仕組み CVSSがあれば、世の中にある様々な脆弱性の深刻度を同じものさしで⽐べられる v2、v3、v3.1がある v3.1はv3のマイナーアップデート版 v2とv3は評価項⽬や評価⽅法が異なる 最近はv3 or v3.1で計算されることが多い

脆弱性の評価 CVSS CVSSv3(Common Vulnerability Scoring System v3.0)とは 脆弱性の深刻度を数値化するための世界中で使われるシステム 基本値、環境値、現状値の3種類が存在する 基本値は、CIAに以下の５項⽬を加え、計8項⽬で脆弱性を評価 攻撃経路(AV):ネットワーク or 隣接 or ローカル or 物理 攻撃の複雑さ(AC):低 or ⾼ 攻撃に必要な権限(PR):なし or 低 or ⾼ 被害者の操作の有無(UI):不要 or 要 影響の範囲(S):変更なし or 変更あり 基本値は0.0-10.0の値＋それぞれの評価項⽬で表現される 例︓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

脆弱性の原理と対策

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

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

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

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

反射型XSSの例

さん

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

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

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

DOM-Based XSS の例 const txt = decodeURIComponent(location.hash.substring(1)); // ソース document.getElementById(“sample”).innerHTML = txt; // シンク

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

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

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

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

• ⼗分強度のあるCSRF対策チケットの付与、検証を⾏う • またはX-Requested-Withヘッダの付与・検証を⾏う • 実績のあるフレームワークを使う • CSRF対策チケットが発⾏・検証されていない • または X-Requested-With ヘッダが付与・検証されていない。[補⾜2] • CSRF対策チケットの強度が弱い CSRFの原因と対策 原因 対策

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

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

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

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

もっと勉強したい⼈のための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 _Series OWASP Top 10 2021 https://owasp.org/Top10/ja/

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

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

補⾜② [補⾜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/ [補⾜4] ⼀部のブラウザではSameSite属性を指定しなかった場合、Laxが指定されていると⾒なすようになっています。 Samesite＝Laxが指定されている場合、リンクをクリックすることで発⽣するようなGETリクエストではCookieが付与されま すが、それ以外のリクエストで、かつリクエストの発⾏元と宛先が同⼀のSiteでない場合はCookieが付与されなくなります。そ の結果、Cookieで保管されているセッションID等が付与されなくなり、リクエストが受け付けられないので、CSRFが成⽴しな くなります。 参考︓https://blog.tokumaru.org/2022/01/impact-conditions-for-no-CSRF-protection-sites.html

脆弱性の評価 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 ⾼

おつかれさまでした 講義はこれで終了です