開運研修 2021 セキュリティ PSIRT ⼤塚 純平

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

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

Cy-CSIRT(セキュリティ室)との違い ▌サイボウズにはCSIRTもある n CSIRT:Computer Security Incident Response Team n サイボウズのCSIRTは「セキュリティ室」と呼ばれています。 ▌セキュリティ室は会社の情報セキュリティ n PCなくした︕, あやしいメールが届いた︕ など ▌セキュリティ室とPSIRTは役割は違えど連携しています。

Webセキュリティ

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

情報資産 ▌情報セキュリティで保護すべき対象 n PC n 設備 n 印刷物 n 情報 n ⼈ 情報資産

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

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

共通脆弱性タイプ⼀覧 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

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

脆弱性の評価 CVSSv3 ▌CVSSv3(Common Vulnerability Scoring System v3.0)とは n 脆弱性の深刻度を数値化するための世界中で使われるシステム n CIAに以下の５項⽬を加え、計8項⽬で脆弱性を評価 n 攻撃経路(AV):ネットワーク or 隣接 or ローカル or 物理 n 攻撃の複雑さ(AC):低 or ⾼ n 攻撃に必要な権限(PR):なし or 低 or ⾼ n 被害者が操作を必要か(UI):不要 or 要 n 影響の範囲(S):変更なし or 変更あり n 0.0 ~ 10.0 の101段階

脆弱性の原理と対策

CWE-89 SQLインジェクション ▌SQLインジェクションとは n Webアプリケーションを通じて任意のSQL⽂をデータベースに対して発 ⾏できる脆弱性 ▌原理 n 攻撃者の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とは n Webアプリケーションを通じて任意のスクリプトを利⽤者のブラウザで実⾏させる脆 弱性 ▌原理 n HTMLタグやJavaScriptタグなどの構造を破壊する⼊⼒をすることでスクリプトを 実⾏される ▌種類 n 蓄積型 XSS:攻撃コードがDBなどに保存されている n 反射型 XSS:攻撃コードがリクエストに含まれる n DOM-Based XSS:DOM操作時に発⽣する

反射型XSSの例

さん

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

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

DOM-Based XSS についての補⾜ ▌DOM-BasedXSSを構成する「ソース」と「シンク」 n ソース︓攻撃者によってスクリプトを埋め込まれる可能性のある箇所 n 例 n location.href, location.search, window.name など n シンク︓ソースに含まれる⽂字列を⽤いることで実際にXSSの原因と なる箇所 n 例 n 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 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

Trusted Types 例 // サーバー側からtrusted typesの制限を課せられている const myPolicy = trustedTypes.createPolicy(“example”, { createHTML: (unsafe) => { /* 適切にエスケープされたsafe変数を⽣成する処理 */ return safe; } }); const txt = decodeURIComponent(location.hash.substring(1)); // ソース // エラー document.getElementById(“sample”).innerHTML = txt; // Trusted Typesを経由しているためエラーにならない document.getElementById(“sample”).innerHTML = myPolicy.createHTML(txt);

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

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

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

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

ブラウザが提供するセキュリティ機構 ▌Same-Origin Policy （SOP） n (スキーム, ホスト名, ポート番号)の組が異なる場合、DOMの参照や通信 の⼀部を禁⽌する。 [補⾜1] 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

セキュリティ機能 ▌以下を指定することで特定のセキュリティ機能を付与できます。 n X-XSS-Protection[補⾜3] n X-Content-Type-Options n X-Frame-Options n クリックジャッキングを防ぐ n Content-Disposition: attachment; n Strict-Transport-Security

Cookieの扱い ▌Cookieを発⾏時に属性を指定することで扱いを制限することができる。 ［補⾜4］ n Expires:絶対的な有効期限を指定 n Max-Age:相対的な有効期限を指定 n Domain:利⽤可能なホストを指定 n Path:利⽤可能なパスを指定 n Secure:HTTPSを利⽤しているときにのみ送信される n HttpOnly:jsなどからの呼び出し禁⽌ n SameSite:リクエストもとに応じてクッキーをセットするかを指定

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

お願い ▌脆弱性は極秘情報です。 n 皆さんが配属され、各チームに関係のある脆弱性情報が⾒えるように なりますが、オープンな場（権限が付いてないレコードのコメントや⽇ 報・分報など）で再現⼿順に関する議論はお控えください。

参考資料/書籍 ▌ 安全なウェブサイトの作り⽅ http://www.ipa.go.jp/security/vuln/websecurity.html ▌ ウェブ健康診断仕様 http://www.ipa.go.jp/files/000017319.pdf ▌ Webアプリケーション脆弱性診断ガイドライン https://github.com/OWASP/www-chapter-japan/tree/master/secreq ▌ OWASP チートシート https://www.owasp.org/index.php/OWASP_Cheat_Sheet_Series ▌ 脆弱性診断スタートガイド ▌ 安全な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の対策になります。 また、SESSIONIDなどのCookieにSameSite属性を付与することでもある程度CSRFを防⽌できます。

補⾜② [補⾜3] 現在では多くのWebブラウザで X-XSS-Protection の廃⽌の動きがあります。 https://caniuse.com/?search=X-XSS-Protection ChromeはXSS Auditor (X-XSS-Protection が有効のときに動作するXSS検出機構）を削除 https://www.chromestatus.com/feature/5021976655560704 Firefoxはもともと対応していない https://bugzilla.mozilla.org/show_bug.cgi?id=528661 EdgeはXSS filter を削除 https://blogs.windows.com/windows-insider/2018/07/25/announcing-windows-10- insider-preview-build-17723-and-build-18204/

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

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