11.9K Views
June 23, 23
スライド概要
本資料は、2023年度に開催されたセキュリティミニキャンプ 東京大会において発表した、「コンテキストを読み解き進めるモダンWebセキュリティ入門」における公開資料です。
関連する資料は下記のリンクをご覧ください
https://gist.github.com/a-zara-n/8a8df8969ff0179e77b255ea35b2ed74
コンテキストを読み解き進める モダンWebセキュリティ入門 - 公開版 セキュリティミニキャンプ in Tokyo 2023 2023/05/13 @a_zara_n セキュリティキャンプ地方大会 2023 東京開催
本資料を作成にあたっての謝辞 本資料および講義作成にあたり助言いただいた、とある診断員様@tigerszk、Tsubasa様@Sz4rny、関連する資料 (https://speakerdeck.com/lhazy/paburitukukuraudote-you-noxie-wei-noxiang-kihe-ifang)の作成にあたり共に準備をしたHazy 様@kawada_syogo225、udon様@_sumisaka、そして各種業務の調整をくださったFlatt Securityのメンバーに対して感謝 を申し上げます。 また、講義実施にあたり、開催までの運営を行ってくださったセキュリティキャンプ協議会の皆様にも重ねて感謝申し上 げます。 セキュリティキャンプ地方大会 2023 東京開催
自己紹介 - プロフィール ❏ HN: Azara ❏ Twitter: Azara / @a_zara_n ❏ 所属 ❏ 株式会社Flatt Security プロフェッショナルサービス事業部 ❏ 活動 ❏ ISOG-J WG1 新技術に関する診断手法分科会 ❏ セキュリティキャンプ 全国大会 2019 / 2020 Bトラック チューター ❏ セキュリティキャンプ 全国大会 2021 Bトラック講師 ❏ AWS Dev Day 2023 Tokyo登壇予定(6/23登壇) ❏ Security-JAWS DAYS CTF 作問(8/27開催) ❏ 脆弱性リサーチ等々 セキュリティキャンプ地方大会 2023 東京開催 3
自己紹介 - プロフィール ❏ HN: Azara ❏ Twitter: Azara / @a_zara_n ❏ 関心事 ❏ Offensive ❏ Cloud Security ❏ Web Application Security ❏ AuthN & AuthZ ❏ Design & Development ❏ Serverless ❏ DDD ❏ Secure By Design ❏ Container セキュリティキャンプ地方大会 2023 東京開催 4
本講義の目標 本講義の目標 アプリケーションの文脈に基づいた安全な開発や脆弱性の発見が行える素地を作る 本講義のトピック ● サーバレスやマイクロサービスといったモダンなアプリケーションにおいて、 いかにセキュリティを意識し開発をするか ● 開発や設計におけるセキュリティの勘所を認識する ● 疎結合なソフトウェアが互いに連携することによって生まれる利点と欠点を 把握する セキュリティキャンプ地方大会 2023 東京開催 5
講義における各種伝達事項 倫理の話 ● 所有者の許可のないサービスやアプリケーションに対して本講義で学んだ攻撃手法や考え方を無闇 に試すなどを行わず倫理的に取り扱いをすることを求めます。 ● 出典元/参考資料に記載された攻撃手法についても同様に注意を払い上記同様、倫理的な取り扱いを することを求めます。 セキュリティキャンプ地方大会 2023 東京開催 6
本日の流れ 1. 2. 3. 4. 5. 6. 座学 基礎: Webアプリケーションを取り巻く技術の変遷 座学 基礎:Webアプリケーションの脆弱性と対策/防御機構の概略 座学 発展: “設計上の抜け漏れ”というセキュリティリスク 座学 発展: サービスの相互作用によって発生するセキュリティリスク ハンズオン ~ Mini hands-on CTF ~(本資料ではスキップ) まとめ セキュリティキャンプ地方大会 2023 東京開催 7
#1 Webアプリケーションを取り巻く技術の変遷 技術には変わるものと変わらないものが存在する。技術の変化の歴史は一見振り子のよ うに見える。でも実は螺旋構造と同じところには戻らない。差分と、それを可能にした 技術こそが重要なものである。そして、変わらないように見える強固なものもある。 意訳/参考: 技術選定の審美眼 デブサミ2018 和田卓人氏資料 セキュリティキャンプ地方大会 2023 東京開催 8
Webアプリケーションを取り巻く技術の変遷 本章で学んでほしいこ と Web技術における技術変遷(歴史)を学び、過去にどのような課題があり、解決をしてきたかといった モダンなWeb技術に対しての理解。 本章の概要 Web技術はクライアントサーバーモデルやWebの三層構造に代表されるように、複数のソフトウェア が分散し連携することでアプリケーションを提供しています。 これら分散システム的な構成は近年より複雑になり、多く企業で”マイクロサービス”や”モジュラモノ リス”、”サーバレス”、”クラウドネイティブ”といった技術スタックの採用が進んでいます。 本章ではこれらモダンなWeb技術に対して”歴史”的な視点で見ることにより、これまでのWebに対する 課題感について学んでいきます。 セキュリティキャンプ地方大会 2023 東京開催 9
Webアプリケーションを取り巻く技術の変遷 ~ ザックリとした変遷 セキュリティキャンプ地方大会 2023 東京開催 10
Webアプリケーションを取り巻く技術の変遷 ~ ザックリとした変遷 セキュリティキャンプ地方大会 2023 東京開催 11
Webアプリケーションを取り巻く技術の変遷 ~ 90年代前半 / Web1.0時代 ● ● ● HTMLやJavaScriptによるWebUIの発展 JavaやPHP、RubyといったWebを支える言語の登場 ASPやSalesforceなどの顧客管理等のエンタープライズ向けWebサービスの登場 ~ SaaSの原型 ○ ○ ● CGIの活用 ○ ○ ● WebUI上から各種操作が可能に 娯楽から仕事と幅広い利用が可能になる 動的なWebUIアプリケーションの構築にCGI(Common Gateway Interface)が活用される サーバーでUIを構築する時代 自前のサーバーかホスティングサービスか ○ 当時はクラウドというものはなく、自前でサーバーを構築しサービスを提供するか、ホスティングサービスを利用し公開するかのどちらかでし た HTTP 通信 Client セキュリティキャンプ地方大会 2023 東京開催 Web Server (CGI) Database / Datasource 12
Webアプリケーションを取り巻く技術の変遷 ~ 90年代前半 / Web1.0時代 この年代のWebアプリケーションや企業 ● ● ● ● ● ● 1991年 GMOインターネット株式会社 1994年 amazon.com 1996年 ○ ヤフー株式会社 ○ Netflix 1997年 ○ サイボウズ株式会社 ○ 株式会社カカクコム 1998年 ○ Google ○ 株式会社サイバーエージェント ○ 株式会社カカクコム 1999年 ○ 2ちゃんねる(現5ちゃんねる) ■ ソースコード https://github.com/nekoruri/readcgi ○ Salesforce ○ VMware ○ 株式会社ディー・エヌ・エー ○ 株式会社ミクシィ ○ さくらインターネット株式会社 セキュリティキャンプ地方大会 2023 東京開催 13
Webアプリケーションを取り巻く技術の変遷 ~ ザックリとした変遷 セキュリティキャンプ地方大会 2023 東京開催 14
Webアプリケーションを取り巻く技術の変遷 90年代後半 ~ 00年代前半 / Web2.0時代 ● XMLの登場による表現幅の増加 ○ ○ ○ ● JQueryやXHR、AJAX、Flashなどの登場で、WebUIの高機能化 ○ ○ ● 1998年にW3Cにて仕様が採択される XMLを用いた通信プロトコルSOAPの登場 簡易なXMLを用いて非同期通信を行うためのブラウザAPIとしてXHRが登場 JQueryの登場でDOM操作やAjaxによる非同期通信などが当時としては容易に行えるようになる ■ 上記の機能が容易に利用できるようになり、SPAの走りのような高機能なUIが表現できるようになる グラフィックエンジンとしてFlashがブラウザに搭載される ■ Flash prayerが搭載されることで、ブラウザでゲームや動画が見れるようになる ■ 現在は廃止されている REST APIの登場 ○ ○ 当初はSOAPなどは用いずに簡易的なXML形式でやり取りをする 2006年のRFC4627(JSONの仕様)が採択されたあたりからJSON形式が採用されるようになる HTTP/S通信やRPC HTTP/S通信 (SOAP) (通 常 のRequest / Responseや非同期での通信) Web Server HTTP/S通信 (SOAPに よる非同期での通信) Client セキュリティキャンプ地方大会 2023 東京開催 Application Server Database / Datasource 15
Webアプリケーションを取り巻く技術の変遷 ~ 90年代後半 ~ 00年代前半 / Web2.0時代 ● エンタープライズアプリのWeb化の浸透 ○ Javaの安定化やStruts、Tomcatなどの周辺ソフトウェアの充実とエンタープライズサポートの拡充によりエンタープライズアプリケーションの 構築はWebが一般的になる ● Ruby On RailsのようなWeb Application Frameworkの登場 ● ● WordPressのようなCMSの登場 クラウドの登場と勃興の兆し ○ ○ ○ ○ 動的アプリケーションを作成する際により容易に構築可能にするフレームワークの登場で、ITの大衆化に向けた素地を整える SaaSという考え方の登場 AWSの登場 コンテナやVM技術の発展 PHPで書かれたCMS WordPress Webサービスをより容易に構築できるようになる セキュリティキャンプ地方大会 2023 東京開催 DRY原則に基づくMVCパターンのWeb Application Framework「Ruby On Rails」 2004年に発表 Amazon SQSから始まりS3やEC2などを2006年から2008年にかけて一般公開 16
Webアプリケーションを取り巻く技術の変遷 ~ 90年代後半 ~ 00年代前半 / Web2.0時代 1990年からの環境変化 ● 実用性のない言語から主役に、JavaScript ○ ○ ● 企業向けのアプリケーションの肥大化 / 同様の機能を持ったアプリケーションの増加 ○ ○ ● ブラウザクラッシャーやウィルスなどの悪ふざけや、UIの装飾(文字を光らせるなど)に使われていた AjaxやJQueryなどの登場や、同時代に登場した技術と合わせることで、UIを動的に変更できるSPAのさきがけ的なことができるようになりWeb の主役へ → CGIからの移管や共存 SOAのようなサービスレベルでの分割とその統合でシステムを構築する考え方の登場 SOAPやXMLによるデータ形式の明確化により疎結合なソフトウェアの連携を行いやすくなる アプリケーションの構築の複雑さとコスト増大 ○ ○ 同様な機能を再利用可能にするSOAのようなアーキテクチャが登場したものの、以前複雑でアプリケーションの構築コストが高い Ruby On RailsやWordPressの登場でtoC向けサービスなどでは小さく始めるスモールスタートが可能になり、コストを抑えることも可能に ■ ※選択肢が増えたということで共存することになる 有名なブラウザクラッシャー「You are an idiot」 参考: https://www.youtube.com/watc h?v=GF 5bR6GE2rk セキュリティキャンプ地方大会 2023 東京開催 [SOAの例]ステークホルダーごとに異なるSOAのとらえ方 参考: https://atmarkit.itmedia.co.jp/fdotnet/special/realsoa01/reals oa01_01.html 17
Webアプリケーションを取り巻く技術の変遷 ~ 90年代後半 ~ 00年代前半 / Web2.0時代 この年代のWebアプリケーションや企業 ● ● ● ● ● 2000年 ○ KLab株式会社 ○ LINE株式会社 2001年 株式会社はてな 2003年 GMOペパボ株式会社 2004年 ○ Facebook ○ グリー株式会社 2005年 ○ Youtube ○ ピクシブ株式会社 開設当初のYoutubeのTopPage 参考: https://www.youtube.com/watch?v=wYUY3Cb7-ks Pixiv ベニヤ板とDCのハイブリッド! pixivインフラの今 @ITmedia 参考: https://atmarkit.itmedia.co.jp/news/201007/21/pixiv.html セキュリティキャンプ地方大会 2023 東京開催 18
Webアプリケーションを取り巻く技術の変遷 ~ ザックリとした変遷 セキュリティキャンプ地方大会 2023 東京開催 19
Webアプリケーションを取り巻く技術の変遷 ~ 00年代後半 ~ 10年代 / クラウド勃興時代 ● LAMPの普及と派生 ○ ○ ● ● ● GoやTypeScriptといった既存の言語を改善する言語(言語拡張)が登場する クラウド利用の活発化 ○ ○ ○ 多くのアプリケーションにおいてOSSのライブラリを活用しアプリケーションを作成 IE以外のブラウザの勃興 ○ ● ● パブリッククラウドの高機能化やコンテナ技術の発展でオンプレからクラウドへと一部が流れる PaaSの登場(Heroku, Google App Engineなど) より多くの企業がインターネット業界に参入できるようになる OSSの利活用が活発に ○ ● 2000年代から普及したものとしてLAMP(Linux, Apach httpd, MySQL, PHP)Stackが定着し始める また、派生としてApach httpdをNginxに、MySQLをmariaDBやpostgresSQLに、PHPをPythonへと変更し構築するといった技術選定にも変化が 生まれるようになる ChromeやFireFoxなどがIEに変わりユーザーに使われるように WebSocketの登場 モバイル端末の普及 HTTP/S通信やWebSocket (Request / Response) Client セキュリティキャンプ地方大会 2023 東京開催 20
Webアプリケーションを取り巻く技術の変遷 ~ 00年代後半 ~ 10年代 / クラウド勃興時代 ● ブラウザ上で動作するアプリケーションの更なる高機能化 ○ ○ ○ ○ ● JavaScriptの実行の高速化やクライアント端末の高性能化に伴う高機能化 VueやReactといったライブラリの登場で、ブラウザで動作するアプリケーションが高機能化 ■ DOMの操作を行うことで動的にページの内容を変更するSPAの台頭 JSONを用いたREST APIの提供が本格化 ブラウザの仕様として、セキュリティ機構が多く組み込まれるようになる ■ CSPやCORS、SOPなど 仮想化やコンテナ技術の発展 ○ ○ ○ 個人レベルでの仮想化端末の利用の加速 ■ VMWare Playerの登場 ■ Vagrantの登場 Dockerの登場 Kubernetesの公開 React, Angular, Vue.jsといった現代でも用いられる フロントエンドライブラリの登場 Dockerやkubernetesが登場することにより 開発の効率化やサーバーの運用効率化、デプロイの 簡素化が進む結果になった Vue.js logo: ©︎ Evan You (CC BY-NC-SA 4.0) with extra conditions(It’s OK to illustrate a commercial product’s Vue.js integration in its marketing copy .) / React logo: ©︎ Meta Platforms, Inc. (CC BY 4.0) / Angular Logo: ©︎ Google (CC BY 4.0) セキュリティキャンプ地方大会 2023 東京開催 21
Webアプリケーションを取り巻く技術の変遷 ~ 00年代後半 ~ 10年代 / クラウド勃興時代 2000年からの環境変化 ● 複雑なアプリケーション構成からモノリスへ ○ ○ ○ ○ ○ ● フロントの大規模化と保守性の向上 ○ ○ ○ ○ ○ ● クラウドサービスの登場で、今までと異なった容易で安価なサービス提供基盤を利用できるようになった クラウドサービスは、運用面や開発やスケールの速度が重要なWeb業界にとっての必要資源となる コンテナの登場で、より容易に開発環境の構築や、サービスのデプロイが行えるようになった モバイル端末の普及 ○ ● サーバーとクライアントのアプリケーションにおいて明確な分離の流れが到来する クライアント端末の高性能化やJavaScriptエンジンの高速化などが相まったこと インターネットの普及による通信量の増加によるサーバー側負荷が増加した フロントエンドの大規模化や専門性の増加から明確にフロントエンドとバックエンドの分離を行う これまでの技術で非同期な通信が、VueやReactの登場によるWebUIの単独構築が可能となり、分離が可能に クラウドサービスの拡充とコンテナの登場 ○ ○ ○ ● toC向けのサービスの増加とベンチャーの増加 コンピュータリソースの性能向上 構築したアプリケーション基盤の流用 フロントとサーバーのアプリケーション分離の動き CDNなどの登場とキャッシュの利用 容易にWebサイトにアクセスが可能になる一方で、通信量の制限や極小の帯域(3Gなど)、端末のスペック等の理由からパフォーマン スチューニングなどが叫ばれるようになった インターネット産業の繁栄 ○ 俗にいう難しさにより発生していた参入障壁が下がる ■ クラウド利用の活発化や言語的な課題によって発生していた セキュリティキャンプ地方大会 2023 東京開催 22
Webアプリケーションを取り巻く技術の変遷 ~ 00年代後半 ~ 10年代 / クラウド勃興時代 この年代のWebアプリケーションや企業 ● ● ● ● ● ● ● ● ● ● 2007年 Sansan株式会社 2009年 ラクスル株式会社 2010年 ○ 株式会社アカツキ ○ ウォンテッドリー株式会社 ○ Retty株式会社 2011年 株式会社プレイド 2012年 ○ 株式会社マネーフォワード ○ スマートニュース株式会社 ○ freee 株式会社 ○ 株式会社Gunosy ○ BASE株式会社 ○ STORES 株式会社 2013年 株式会社メルカリ 2014年 bitFlyer 2015年 OpenAI 2016年 AbemaTV 2018年 株式会社LayerX セキュリティキャンプ地方大会 2023 東京開催 23
Webアプリケーションを取り巻く技術の変遷 ~ ザックリとした変遷 セキュリティキャンプ地方大会 2023 東京開催 24
Webアプリケーションを取り巻く技術の変遷 ~ 2020年代 / 現代 ● ● モノリスの分割 ○ ○ ○ 開発体制の抜本的変化 ○ ○ ○ ● ● マイクロサービス モジュラーモノリス サーバレス ウォーターフォールからアジャイルへ SOAな考えの派生としてDDDなどの登場 ソフトウェアアーキテクチャの多様化 クラウドネイティブへ ○ ○ ○ ○ パブリッククラウドの発展と利用 コンテナ技術の一般化 疎結合なアプリケーションの連携 管理と維持の自動化 APIの多様化 ○ ○ gRPC-Webの登場によるBodyの圧縮 GraphQLによるオーバーフェッチやアンダーフェッチ、管理コストの改善 以 前 作 っ た AWSサ ービ スで構 築され たサー バーレ スなSNSの 構成図 セキュリティキャンプ地方大会 2023 東京開催 25
Webアプリケーションを取り巻く技術の変遷 ~ 2020年代 / 現代 ● ● ● フロントエンドの技術革新とフロントエンド疲れ ○ フロントエンド技術の発展速度が早まる一方、新たな概念やライブラリの新陳代謝が早くフロントエンドのキャッチアップ疲れが発生 インターネットの普及とUXとSEO ○ ○ ○ 2000年代中期から普及し始めたSEO Webが一般社会に溶け込むことで、UXや速度というものが重視されるようになった また、広告や検索といったものにサービスの発展が左右されることからSEOの重要性が大きくなる OSSの利活用が一般化 セキュリティキャンプ地方大会 2023 東京開催 26
Webアプリケーションを取り巻く技術の変遷 ~ 2020年代 / 現代 2010年からの環境変化 ● アプリケーションの巨大化 ○ ○ ○ ● クラウド活用 ○ ○ ● Ruby On Railsなどのフレームワークを用いて作成されたサービスが成熟期から安定期をむかえ、巨大なコードの維持管理が課題に 保守性や開発速度向上やスケールを行いやすくするため、サービスの分割を行うようになる(SOAの再来) 結果マイクロサービスやモジュラモノリスの採用が増える AWSやGCP、Azureといったパブリッククラウドの他、より有る機能に特化したクラウドサービス(Auth0やNetlify、Cloudflareなど)の登場により、 多くのアプリケーションでクラウドが採用されるようになる 一方で、慣れないクラウドサービスを活用することで、設定のミスや連携における課題が発生し、セキュリティリスクの増加も話題となる ■ 例: S3における顧客情報のアクセス制御の不備 OSSの利活用の一般化 ○ ○ 一般化することで、便利なソフトウェアを自身のアプリケーションに組み込みやすくなった 代償として脆弱性等が確認された際に、世界規模での騒動になりうる状況に セキュリティキャンプ地方大会 2023 東京開催 27
Webアプリケーションを取り巻く技術の変遷 ~ 似たような技術課題 具体・抽象・応用の繰り返しによる「技術の螺旋」 ● 過去にここで実装や保持をしていたものの抽象化 ○ ● 抽象化に伴う技術の大衆利用 ○ ● 応用が進み、技術に対して慣れが発生することで具体的にシステムが固定化される システムの肥大化と抽象化 ○ ● 抽象化されたものは大衆に利用され、応用的にあらゆるプロダクトやシステムに組み込まれる 抽象化された技術に”慣れ”が発生することでシステムの肥大化が発生 ○ ● サーバーや機能レベルのコードの具体をクラウドやサービスとして抽象化 似た構成や抽象化可能なレイヤーが存在するようになるそのため抽象化される 利便の追求と不便の発見 ○ 機械語からアセンブリ言語、低レベルな言語から高レベルな言語、物理インフラからクラウドインフラ、手動での構築からIaC、プログラミング からローコードへ セキュリティキャンプ地方大会 2023 東京開催 28
Webアプリケーションを取り巻く技術の変遷 ~ モダンWebにおける技術的課題 モダンWebにおける技術的課題等 ● システムの複雑性の増大 ○ ○ ○ ● サイバーセキュリティへの注目 ○ ○ ● マイクロサービス/モジュラモノリス/サーバレスといったアーキテクチャの多様化とアプリケーションの分割 可観測性(Observability)の低下 ■ DataDogやKubernetesにおけるサイドカーパターンによる補助などで観測はできる ビジネスドメインの専門化と複雑なコンテキスト ■ DDD的な考えを持ち込む インターネットの大衆化に伴い、悪意を持った攻撃者の増加 ソフトウェアやシステムを構成する”部品”の増加とその脆弱性への対応 ■ OSSをプロダクトに多く組み込むようになる → 既知の脆弱性への対応 ■ クラウドサービスを用いた一部機能のサービスからの切り離し → サービスの設定不備による被害 ■ 疎結合なのシステムを連携させるマイクロサービスの普及 → コンテキストを跨いだデータの悪性作用 品質と可用性 ○ ○ 大衆化に伴いサービスの品質が重要となる サービスの品質といえばUXなどもそうだが、サービスの可用性なども重要 ■ 極力ダウンタイムを減らすことで機会損失を減らす セキュリティキャンプ地方大会 2023 東京開催 29
Webアプリケーションを取り巻く技術の変遷 ~ Web3.0は? 本資料で書くには余白が少なすぎる。 というのは冗談で、技術革新が激しく、「これだ」と書くにはまだまだ時間がかかる可能性があるので 本講義では一旦飛ばします。 セキュリティキャンプ地方大会 2023 東京開催 30
Webアプリケーションを取り巻く技術の変遷 ~ まとめ セキュリティキャンプ地方大会 2023 東京開催 31
#2 Webアプリケーションの脆弱性と対策/防御機構の概 略 OWASP Top Tenに取り上げられる脆弱性を筆頭にアプリケーションのセキュリティを守るためには、 脆弱性への理解と、その脆弱性に対して適切な対策や防御機構の導入を必要とします。 本章では、Webアプリケーションの”代表的な脆弱性”や”対策”、”防御機構”についてざっくりとお話しし ます。 セキュリティキャンプ地方大会 2023 東京開催 32
Webアプリケーションの脆弱性と対策/防御機構の概略 本章で学んでほしいこ と Webアプリケーションのセキュリティにおいて、発生しうる脆弱性や発生しやすい箇所、原理、 またそれら脆弱性の対策について学ぶ 本章の概要 技術の発展に伴い、利便性が増す中で脆弱性の種別なども細分化されています。 本章では、OWASP Top10で紹介されている脆弱性をピックアップし、モダンなWebアプリケーショ ン環境における、発生要因や発生時のリスクを踏まえながら、セキュリティ機構や対策について話し ていきます。 セキュリティキャンプ地方大会 2023 東京開催 33
OWASP Top 10に見る近年の脆弱性トレンド OWASP Top 10 2021 OWASP Top 10 2017 A01 インジェクション系攻撃 ↑4 A01 アクセス制御の不備 A02 認証の不備 ↑1 A02 暗号化の失敗 A03 機微情報の露出 ↓2(Merge XSS) A03 インジェクション系攻撃 A04 XXE New 安全が確認されない不安な設計 A05 アクセス制御の不備 ↑1(Merge XXE) A05 セキュリティに関わる設定の不備 A06 セキュリティに関わる設定の不備 ↑3 A06 脆弱で古くなったコンポーネント A07 XSS ↓5 A07 識別と認証の失敗 A08 Insecure Deserialization → A08 ソフトウェアとデータの生合成の不具合 A09 既知の脆弱性のあるコンポーネントの使用 ↑1 A09 セキュリティログとモニタリングの失敗 A10 不十分なロギングとモニタリング New A10 SSRF A04 出典: https://owasp.org/Top10/ja/ セキュリティキャンプ地方大会 2023 東京開催 34
OWASP Top 10に見る近年の脆弱性トレンド A01 アクセス制御の不備 SaaSやECサイトのようなtoC向けのWebアプリケーションが2000年代から徐々に増えてきま した。そのような中、ユーザーがどのような操作を可能にするかといった権限設計というの はどの時代においても悩まされてきているのは事実です。 OWASP Top 10 2021 ↑4 A01 アクセス制御の不備 ↑1 A02 暗号化の失敗 ↓2(Merge XSS) A03 インジェクション系攻撃 New 安全が確認されない不安な設計 A04 後に説明する内容ではありますが、インジェクション系の脆弱性や認証に関しては、ライブ ラリやSaaSなどを用いることでデフォルトセキュリティや独自実装を行わなくて良いことに より安全な状況を担保できるようになりました。 一方、アクセス制御に関しては実現したいロジックや動作におけるコンテキストが複雑にな ること、また独自実装が多いことから、誤った実装や考慮から漏れることにより意図しない アクセスを行えてしまいます。 どのような脆弱性? ● ↑1(Merge XXE) A05 セキュリティに関わる設定の不備 ↑3 A06 脆弱で古くなったコンポーネント ● ↓5 A07 識別と認証の失敗 ● → A08 ソフトウェアとデータの生合成の不具合 ↑1 A09 セキュリティログとモニタリングの失敗 ● New A10 SSRF ● デフォルト拒否原則の無視 ○ ユーザーの有する権限の超越 ○ テナント間の不十分な権限分離 ゆるいセキュリティ設定 ○ CORSにおけるオリジンの “*” 指定 検証の不備 ○ ユーザー権限の検証不備 ○ JWTや各種Tokenの改竄 ○ IDaaSからの情報の無条件の信用 / 意図しない属性変更 IDの検証不備 ○ 指定するIDの所有の確認不備 CSRF ○ ライブラリ特性による検証不備 出典 https://owasp.org/Top10/ja/A01_2021-Broken_Access_Control/ セキュリティキャンプ地方大会 2023 東京開催 35
OWASP Top 10に見る近年の脆弱性トレンド A01 アクセス制御の不備 どのような機能で発生しやすいか? ● APIの操作権限 ● パスワード再設定メール送信 ● IDなどを指定してCRUDを行う機能 ○ OWASP Top 10 2021 ↑4 A01 アクセス制御の不備 ↑1 A02 暗号化の失敗 ○ ○ ○ ● インジェクション系攻撃 New 安全が確認されない不安な設計 A04 送信先とは関係のないユーザーを紐付け送信 投稿内容の変更機能で投稿IDを変更することで自身以外のユーザーが投稿した内容を変更できる PUT https://dummy.azara.jp/api/v 1/post/100 権限管理 ○ ↓2(Merge XSS) A03 APIそのものが認証していなかったり、権限を持っていなくても操作/取得ができてしまう 権限を管理するダッシュボードにおいて、権限変更を行えないユーザーが変更できてしまい権限昇格 が行える 具体例による脆弱性と防御機構の解説 ↑1(Merge XXE) A05 セキュリティに関わる設定の不備 ↑3 A06 脆弱で古くなったコンポーネント ↓5 A07 識別と認証の失敗 → A08 ソフトウェアとデータの生合成の不具合 ● ● ● ● ● ↑1 A09 セキュリティログとモニタリングの失敗 概念 New A10 SSRF ● CSRF TokenとContent-Type IDOR(Insecure Direct Object Reference) CORSヘッダー Path Traversal 認可制御とライブラリ 最小権限の原則 出典 https://owasp.org/Top10/ja/A01_2021-Broken_Access_Control/ セキュリティキャンプ地方大会 2023 東京開催 36
OWASP Top 10に見る近年の脆弱性トレンド A01にみる脆弱性とセキュリティ機構 CSRF TokenとContent-Type 近年多く見られるものとして、Content-Typeを変更することにより、本来確認すべきCSRF Tokenの存在を確認せ ずにAPIなどへアクセスできてしまうケースなどが報告されることがあります。 例: 本来であれば、application/jsonで送信するところ、application/x-www-form-urlencodedで送信するとCSRF Tokenの検証を行わない 参考: https://hackerone.com/reports/753386 https://github.com/fastify/fastify/security/advisories/GHSA-3fjj-p79j-c9hh セキュリティキャンプ地方大会 2023 東京開催 37
OWASP Top 10に見る近年の脆弱性トレンド A01にみる脆弱性とセキュリティ機構 認可制御とライブラリ 多くのアプリケーションにおいて、認可制御 /アクセス制御を 無視してアプリケーションが成り立つことは少ないでしょう。 そんな中で、「認可」というものはなんなのか、一旦分解して 考えてみましょう。 認可に関わる2つの要素 1. 2. インターフェースへのアクセス データへのアクセス インターフェースのアクセスは、そのインターフェースにその ユーザーがアクセスしていいのかという「権限」というもので あると考えます。一方でデータへのアクセスは、「所有」や 「管理」と言った考えになります。 多くの場合、「権限」と言った認可制御に関しては、ライブラ リやフレームワークで管理を行うことが可能でこれらを用いる ことで実装が行いやすくなるでしょう。 一方で、データに対しての認可制御となると、データの所有や 管理が可能なものなのか、独自実装が必要になるケースが多く、 対策や検証をより詳しく行う必要があります。 セキュリティキャンプ地方大会 2023 東京開催 参考 https://github.com/varvet/pundit https://larav el.com/docs/10.x/authorization https://docs.aws.amazon.com/ja_jp/cognito/latest/developerguide/cognito-user-pools-user-groups.html 38
OWASP Top 10に見る近年の脆弱性トレンド A02 暗号化の失敗 OWASP Top 10 2021 ↑4 A01 アクセス制御の不備 ↑1 A02 暗号化の失敗 ↓2(Merge XSS) A03 インジェクション系攻撃 New 安全が確認されない不安な設計 A04 ↑1(Merge XXE) A05 セキュリティに関わる設定の不備 ↑3 A06 脆弱で古くなったコンポーネント ↓5 A07 識別と認証の失敗 → A08 ソフトウェアとデータの生合成の不具合 ↑1 A09 セキュリティログとモニタリングの失敗 New A10 SSRF A01同様2000年代から徐々にWebアプリケーションが機密性の高いデータを取り 扱うようになりました。近年では顧客情報や、クレジットカードの流出に始まり、 弱い暗号化アルゴリズムの利用や認証情報の流出などインシデントや報告が多々 報告されています。 また、社会的にセキュリティ/プライバシー重視の流れとなっていることも事実 で、EUにおける一般データの保護規則(General Data Protection Regulation)や日 本における改正電気通信事業法などの立法もなされています。クレジットカード や金融における業界団体においては、従来の規定をモダナイズする動きがありま す。 どのような脆弱性? ● ● データの暗号化不備 ○ クラウドにおける平文保存 ○ DB内部のパスワードの復号可能な状態での保存 通信の暗号化不備 ○ 機微情報を取り扱うアプリケーションにおけるHTTP通信の許容 ○ HSTSの設定ミス ○ 脆弱な暗号化プロトコルの利用 ■ 脆弱性のあるプロトコル例 ● SSLv3 ● TLSv1.1 出典 https://owasp.org/Top10/ja/A02_2021-Cryptographic_Failures/ セキュリティキャンプ地方大会 2023 東京開催 39
OWASP Top 10に見る近年の脆弱性トレンド A02 暗号化の失敗 どのような機能で発生しやすいか? ● OWASP Top 10 2021 ↑4 A01 アクセス制御の不備 ↑1 A02 暗号化の失敗 ↓2(Merge XSS) A03 インジェクション系攻撃 New 安全が確認されない不安な設計 A04 ↑1(Merge XXE) A05 セキュリティに関わる設定の不備 ↑3 A06 脆弱で古くなったコンポーネント ↓5 A07 識別と認証の失敗 → A08 ソフトウェアとデータの生合成の不具合 ↑1 A09 セキュリティログとモニタリングの失敗 New A10 SSRF ● 通信の送受信 ○ HTTP/FTP/SMTPなどの通信プロトコルの利用 データの保存 具体例による脆弱性と防御機構の解説 ● ● ● ● クラウドサービスにおけるデータの暗号化 パスワードのデータベース保存 HSTS(HTTP Strict Transport Security) ネットワークレベルでの暗号化 出典 https://owasp.org/Top10/ja/A02_2021-Cryptographic_Failures/ セキュリティキャンプ地方大会 2023 東京開催 40
OWASP Top 10に見る近年の脆弱性トレンド A03 インジェクション サービスやソフトウェアをまたぐ際に発生しやすいインジェクション攻撃、 OWASP Top 10が公表された2003年から毎年トレンド入りするほどWebアプ リケーションセキュリティといえばこの脆弱性と言えます。 OWASP Top 10 2021 ↑4 A01 アクセス制御の不備 ↑1 A02 暗号化の失敗 ↓2(Merge XSS) A03 インジェクション系攻撃 New 安全が確認されない不安な設計 A04 ↑1(Merge XXE) A05 セキュリティに関わる設定の不備 ↑3 A06 脆弱で古くなったコンポーネント ↓5 A07 識別と認証の失敗 → A08 ソフトウェアとデータの生合成の不具合 ↑1 A09 セキュリティログとモニタリングの失敗 New A10 SSRF 昨今のWeb Application Frameworkやライブラリの発展およびデフォルトセキ ュア化の流れ、インジェクション攻撃の認知の拡大から、少しではあります が順位を低下させました。 ただ、依然脅威度としては高く、モダンなアプリケーションであっても対策 や意識を払う必要があります。 どのような脆弱性? SQL InjectionやOS Command Injection、XSS、Template Injectionに代表され るように、あるソフトウェアやサービスにおいて特殊な意味を持つ文字列を 適切な処理を行わずに利用することにより、悪性の副作用が起こる脆弱性で す。 出典 https://owasp.org/Top10/ja/A03_2021-Injection/ セキュリティキャンプ地方大会 2023 東京開催 41
OWASP Top 10に見る近年の脆弱性トレンド A03 インジェクション どのような機能で発生しやすいか? OWASP Top 10 2021 ↑4 A01 アクセス制御の不備 ↑1 A02 暗号化の失敗 ↓2(Merge XSS) A03 インジェクション系攻撃 New 安全が確認されない不安な設計 A04 ↑1(Merge XXE) A05 セキュリティに関わる設定の不備 ↑3 A06 脆弱で古くなったコンポーネント ↓5 A07 識別と認証の失敗 → A08 ソフトウェアとデータの生合成の不具合 ↑1 A09 セキュリティログとモニタリングの失敗 New A10 SSRF 特定のサービスやソフトウェアに限らず、あるコンテキストをまたぐ操作を 行う場合に発生しやすいです。例えば下記のような機能が考えられます。 ● ● ● ● SQLなどのデータを保存する機能 OSコマンドなどを直接実行する機能 HTTP Headerを指定する機能 HTMLの生成機能 セキュリティ機構の発展 XSSやSQL injectionなどをはじめとしたインジェクション攻撃は脅威度が高 いことから多くのフレームワークやライブラリにおいて、通常の機能ないに セキュリティ機構を組み込むような実装になりつつあります。 出典 https://owasp.org/Top10/ja/A03_2021-Injection/ セキュリティキャンプ地方大会 2023 東京開催 42
OWASP Top 10に見る近年の脆弱性トレンド A03にみるセキュリティ機構 A03にみるライブラリのデフォルトセキュア化 (SQL injection対策) 近年のWebアプリケーションを作成する上でほぼ必須となってきたObject Relational Mapping(ORM)ライブラリ。多くの WebApplicationFrameworkにも同梱されており、生でSQL文を組み立てることが少なくなりました。 このORMはSQL injection対策として提唱される文字列のエスケープをORM上で実施するため、安全にSQL文を組み立てる ことが可能になりました。 一方で注意点として、ORMのrawやexecuteのようなMethodを用いて生のSQL文を実行したり、execなどといったSQLの 実行関数などを用いる場合、これらORMを利用した場合でもSQLインジェクションが発生する可能性があります。 LaravelのORM “Eloquent” セキュリティキャンプ地方大会 2023 東京開催 Ruby On Railsの ORM “Active Record” 43
OWASP Top 10に見る近年の脆弱性トレンド A03にみるセキュリティ機構 A03にみるライブラリのデフォルトセキュア化 (XSS対策) Reactでは生のHTMLを出力したい場合は、 dangerouslySetInnerHTMLを呼び出す必要がある → 危険性を呼び出す属性名で伝える セキュリティキャンプ地方大会 2023 東京開催 Laravelのテンプレートエンジンでのエスケープ なしHTMLの表示 → !!を両端に設定することで、危険性を表現 44
OWASP Top 10に見る近年の脆弱性トレンド A03にみるセキュリティ機構 A03にみるブラウザのセキュリティ機構(XSS対策 / CSS Injection対策等) サーバーサイドやライブラリレベルでのセキュリティ対策以外にも、クライアントとしてのブラウザでもセキュリティ機構が存在し ます。A03でいえば、Content Security Policy(CSP)が代表的な例です。 CSPは、ブラウザが提供するXSSやデータインジェクション系統の攻撃の影響を軽減するための仕組みで、ウェブサーバーからのレ スポンスヘッダに含まれるContent-Security-Policyを解釈し、違反したものをブロックや通知することのできる機構です。 GET /js/app.js CSPの例 originA.azara.jp Client HTTP/1.1 200 OK …. Content-Security-Policy: default-src 'self' …. GET /xss.js (Block) assets.azara.jp セキュリティキャンプ地方大会 2023 東京開催 45
OWASP Top 10に見る近年の脆弱性トレンド A03にみるセキュリティ機構 A03にみるブラウザのセキュリティ機構(CSP Bypassの可能性) ● ● 許可したOriginにXSSを含むファイルをアップロード可能な場合 ○ StaticなJSのファイルの配信ドメインとアップロードしたファイルを配信するドメインが一緒な場合 ■ 例: https://demo.azara.jp/js/app.js と https://demo.azara.jp/image/profile/icon.png 許可したOriginにJSONPなどが存在し、任意のScriptが挿入可能な場合 HTTP/1.1 200 OK …. Content-Security-Policy: default-src 'self' …. HTTP/1.1 200 OK …. Content-Security-Policy: default-src none; script-src ‘self’; …. CSPの例 セキュリティキャンプ地方大会 2023 東京開催 46
OWASP Top 10に見る近年の脆弱性トレンド A04 安全が確認されない不安な設計 先のWeb技術の変遷内でも2020年代において、サイバーセキュリティの重要 性が増しており、プロダクトを展開する上で顧客・提供する価値・企業の利 益を守るためになくてはならない存在になりました。 OWASP Top 10 2021 ↑4 A01 アクセス制御の不備 ↑1 A02 暗号化の失敗 ↓2(Merge XSS) A03 インジェクション系攻撃 New 安全が確認されない不安な設計 A04 ↑1(Merge XXE) A05 セキュリティに関わる設定の不備 ↑3 A06 脆弱で古くなったコンポーネント ↓5 A07 識別と認証の失敗 → A08 ソフトウェアとデータの生合成の不具合 ↑1 A09 セキュリティログとモニタリングの失敗 New A10 SSRF このA04は抽象的な表現であり、様々な脆弱性に対して広範的に内包するよ うな形になっており、少しわかりにくいカテゴリになると思います。また、 本講義における主題になるので、ここでは触れずに、後の3章にて解説を行い ます。 どのような脆弱性? ● ● ● ● ビジネスロジックの不備 認証情報の回復におけるフローの不備 セキュリティ機構の有効化漏れ SaaSの設定の定義漏れ どのような機能で発生しやすいか? ● ロジックや設定のある全ての範囲 関連する概念 ● セキュリティ・バイ・デザイン 出典 https://owasp.org/Top10/ja/A04_2021-Insecure_Design/ セキュリティキャンプ地方大会 2023 東京開催 47
OWASP Top 10に見る近年の脆弱性トレンド A05 セキュリティの設定ミス OWASP Top 10 2021 ↑4 A01 アクセス制御の不備 ↑1 A02 暗号化の失敗 ↓2(Merge XSS) A03 インジェクション系攻撃 New 安全が確認されない不安な設計 A04 ↑1(Merge XXE) A05 セキュリティに関わる設定の不備 ↑3 A06 脆弱で古くなったコンポーネント ↓5 A07 識別と認証の失敗 → A08 ソフトウェアとデータの生合成の不具合 ↑1 A09 セキュリティログとモニタリングの失敗 New A10 SSRF 近年、プロダクトを展開する上で多くのライブラリやソフトウェア、SaaSを 利用するようになりました。それらの設定を適切に設定しなかった場合、本 来アクセスされたくない機能や、見られては困るリソースにアクセスができ てしまう可能性があります。 どのような機能で発生しやすいか? ● ● ● ● ● ● 認証機能におけるデフォルトパスワード エラー発生時のスタックトレース デバッグ機能の有効化 ライブラリにおける副作用のあるデフォルトファイル 副作用のあるアクセス制御設定 ○ 新規登録の有効化 ○ ユーザー属性の変更 不要なページの表示 具体的な例の紹介 ● ● ● Debugモード ライブラリにおける副作用のあるデフォルトファイル ミスコンフィグの発見 出典 https://owasp.org/Top10/ja/A05_2021-Security_Misconfiguration/ セキュリティキャンプ地方大会 2023 東京開催 48
OWASP Top 10に見る近年の脆弱性トレンド A05 セキュリティの設定ミスの具体例 ライブラリにおける副作用のあるデフォルトファイル 出典 https://vulners.com/zdt/1337DAY-ID-37301 https://jvndb.jvn.jp/ja/contents/2017/J VNDB-2017- 005280.html セキュリティキャンプ地方大会 2023 東京開催 49
OWASP Top 10に見る近年の脆弱性トレンド A05 セキュリティの設定ミスの具体例 ミスコンフィグの発見 出典: https://github.com/yandex/gixy セキュリティキャンプ地方大会 2023 東京開催 出典: https://github.com/sa7mon/S3Scanner 50
OWASP Top 10に見る近年の脆弱性トレンド A05 セキュリティの設定ミスの具体例 出典 https://decoded.avast.io/vladimirmartyanov/research-shows-over-10-of-sampled-firebase-instances-open/ https://www.comparitech.com/blog/information-security/firebase-misconfiguration-report/ セキュリティキャンプ地方大会 2023 東京開催 51
OWASP Top 10に見る近年の脆弱性トレンド A05 セキュリティの設定ミスの具体例 出典 https://rhinosecuritylabs.com/aws/s3-ransomware-part-1-attack-vector/ https://new s.netcraft.com/archives/2019/08/29/uniqlo-and-the-guardian-among-thousands-of-sites-loading-malicious-code-froms3.html セキュリティキャンプ地方大会 2023 東京開催 52
OWASP Top 10に見る近年の脆弱性トレンド A06 脆弱で古くなったコンポーネント OSSの利活用で車輪の再発明がなくなり、プロダクトやアプリケーションの 構築においては、より速度のある事業展開が可能になりました。 OWASP Top 10 2021 ↑4 A01 アクセス制御の不備 ↑1 A02 暗号化の失敗 ↓2(Merge XSS) A03 インジェクション系攻撃 New 安全が確認されない不安な設計 A04 ↑1(Merge XXE) A05 セキュリティに関わる設定の不備 ↑3 A06 脆弱で古くなったコンポーネント ↓5 A07 識別と認証の失敗 → A08 ソフトウェアとデータの生合成の不具合 ↑1 A09 セキュリティログとモニタリングの失敗 New A10 SSRF 一方、OSSにおいて発見された脆弱性については適切な管理を行わない場合、 甚大な被害をもたらす可能性もあります。 どのようなトレンド? 多くのライブラリやソフトウェアにおいて、脆弱性が発見され修正がなされ た場合、CVEと呼ばれるIDが採番され、アップデートや注意喚起のため脆弱 性情報を公開します。 アップデートや注意喚起のため脆弱性情報が公開されますが、裏返せば攻撃 者にも攻撃の糸口を提供することにもなり、大規模な攻撃を誘発する場合も あります。 過去の例で言うと、2021年12月10日にはログ用のライブラリであるLog4jに おいて、任意コード実行の脆弱性が公開され、その後攻撃者は見境なしに、 公開されたPoCを用いて攻撃を試みました。発表時期が年末に差し掛かる金 曜日であったこともあり、Java系を用いる企業は自社のサービスや、ライブ ラリやソフトウェアの内部でLog4jを用いたサービスなどがないか調査を行っ ていました。 参考: https://www.jpcert.or.jp/at/2021/at210050.html 出典 https://owasp.org/Top10/ja/A06_2021-Vulnerable_and_Outdated_Components/ セキュリティキャンプ地方大会 2023 東京開催 53
OWASP Top 10に見る近年の脆弱性トレンド A06 脆弱で古くなったコンポーネントの検知 パッケージツールの拡張や既知の脆弱性の検知 Npmにおける既知の脆弱性の検知 出典: Auditing package dependencies for security vulnerabilities https://docs.npmjs.com/auditing-package-dependencies-for-security-vulnerabilities snykやDependabot、Vulsなどといった既知の脆弱性の検知を行う ソフトウェアやサービスの登場 Snyk: https://snyk.io/ Dependabot: https://docs.github.com/ja/code-security/dependabot/working-with-dependabot Vuls: https://github.com/future-architect/vuls/ 出典 https://snyk.io/press-kit/ https://github.com/future-architect/vuls/blob/master/img/vuls _logo.png https://github.com/dependabot セキュリティキャンプ地方大会 2023 東京開催 54
OWASP Top 10に見る近年の脆弱性トレンド A07 識別と認証の失敗 OWASP Top 10 2021 ↑4 A01 アクセス制御の不備 ↑1 A02 暗号化の失敗 ↓2(Merge XSS) A03 インジェクション系攻撃 New 安全が確認されない不安な設計 A04 ↑1(Merge XXE) A05 セキュリティに関わる設定の不備 ↑3 A06 脆弱で古くなったコンポーネント ↓5 A07 識別と認証の失敗 → A08 ソフトウェアとデータの生合成の不具合 ↑1 A09 セキュリティログとモニタリングの失敗 New A10 SSRF 2017年に比べ大幅に下げた識別と認証の失敗、その要因としてWeb Application FrameworkやIDaaSの利用による認証の独自実装の減少やセッシ ョン機能のライブラリ化などの技術的な要因があります。また、NISTのよう な公的機関がガイドライン(NIST 800-63-3)を公開などといった非技術的な要 因も影響していると考えられます。 どのような脆弱性? ● ● ● ● パスワードリスト攻撃等への耐性不足 ログインの試行回数制限がない エラー情報によるユーザー情報の漏洩 多要素認証の回避 どのような機能で発生しやすいか? 認証やSession、Tokenの検証といった箇所で脆弱性が発生をしやすい。 参考 https://openid-foundation-japan.github.io/800-63-3-final/sp800-63-3.ja.html 出典 https://owasp.org/Top10/ja/A07_2021-Identification_and_Authentication_Failures/ セキュリティキャンプ地方大会 2023 東京開催 55
OWASP Top 10に見る近年の脆弱性トレンド A07 識別と認証の失敗 IDaaSとフレームワークと認証機能の共通化 認証機能を独自で実装せずに、認証機能を提供するSaaS(IDaaS)を用いる事による 独自実装での脆弱性埋め込みの減少 セキュリティキャンプ地方大会 2023 東京開催 メジャーなWeb Application Framew orkにおける認証機能のライブラリ提供 による独自実装の減少と脆弱性の埋め込み減少 56
OWASP Top 10に見る近年の脆弱性トレンド A08 ソフトウェアとデータの整合性の不具合 OWASP Top 10 2021 ↑4 A01 アクセス制御の不備 ↑1 A02 暗号化の失敗 ↓2(Merge XSS) A03 インジェクション系攻撃 New 安全が確認されない不安な設計 A04 ↑1(Merge XXE) A05 セキュリティに関わる設定の不備 ↑3 A06 脆弱で古くなったコンポーネント ↓5 A07 識別と認証の失敗 → A08 ソフトウェアとデータの生合成の不具合 ↑1 A09 セキュリティログとモニタリングの失敗 New A10 SSRF この項目は二つの観点が存在しており、一つは”Insecure Deserialization”とい ったシリアル化したデータを安全ではない形で戻してしまった際に発生する データの生合成の確認、もう一つは、”ソフトウェアサプライチェーン”を標 的とした攻撃が該当します。 どのような脆弱性? ● ● ● シリアル化されたデータの検証不備 Typo Squatting ソフトウェアの悪意のあるアップデート どのような機能で発生しやすいか? ● ● ● シリアル化されたデータをシステム外に送り、復号する機能 CI/CDにおいてライブラリのアップデート時に自動で取り込む 署名付きの外部入力において署名検証の不備がある機能 出典 https://owasp.org/Top10/ja/A08_2021-Software_and_Data_Integrity_Failures/ セキュリティキャンプ地方大会 2023 東京開催 57
OWASP Top 10に見る近年の脆弱性トレンド A08 ソフトウェアとデータの整合性の不具合 Web Application Framework内におけるgadget Web Application Frameworkやライブラリを利用している場合、Insecure Deserializationに活用可能な既知の gadgetというものが存在しています。そのため、悪意のある攻撃者がフレームワークやライブラリ名の露出や、 デフォルトファイルの出力は次なる攻撃に繋がる可能性なども存在します。 講義内で紹介したツールや資料等については 直接的な攻撃や被害が拡大する可能性があるため、 本資料においては削除いたしました。 セキュリティキャンプ地方大会 2023 東京開催 58
OWASP Top 10に見る近年の脆弱性トレンド A08 ソフトウェアとデータの整合性の不具合 ライブラリやソフトウェアを標的にした攻撃 出典 https://www.bleepingcomputer.com/news/s ecurity/troj anized-dnspy-app-dr ops-malware-cock tail-on-res earchers-devs/ https://www.bleepingcomputer.com/news/s ecurity/py pi-python-pack ages-caught-sending-stolen-aws-keys-to-unsec ured-sites/ https://docs.npmjs.com/threats- and-mitigations セキュリティキャンプ地方大会 2023 東京開催 59
OWASP Top 10に見る近年の脆弱性トレンド A09 セキュリティログとモニタリングの失敗 OWASP Top 10 2021 ↑4 A01 アクセス制御の不備 ↑1 A02 暗号化の失敗 ↓2(Merge XSS) A03 インジェクション系攻撃 New 安全が確認されない不安な設計 A04 ↑1(Merge XXE) A05 セキュリティに関わる設定の不備 ↑3 A06 脆弱で古くなったコンポーネント ↓5 A07 識別と認証の失敗 → A08 ソフトウェアとデータの生合成の不具合 ↑1 A09 セキュリティログとモニタリングの失敗 New A10 SSRF クラウドへのシフトが加速する中、多くのサービスにおけるログの取得と整 理は大変重要です。DevSecOpsにおいて、疑わしい行動をタイムリーに検知 できることは大変重要で、インシデントが発生した際の初動において大きな 差が生まれます。 また、近年ではSOAR(Security Orchestration Automation and Response)をは じめとするインシデントの対応を自動化する流れが多くあり、クラウドへの シフトの助けもあり重要度が増しています。 出典 https://owasp.org/Top10/ja/A09_2021-Security_Logging_and_Monitoring_Failures/ セキュリティキャンプ地方大会 2023 東京開催 60
OWASP Top 10に見る近年の脆弱性トレンド A10 サーバーサイドリクエストフォージェリ ここ数年で大きく話題に上がったSSRF、この脆弱性はクラウドを利用する アプリケーションにおいて大きな課題となっています。 OWASP Top 10 2021 ↑4 A01 アクセス制御の不備 ↑1 A02 暗号化の失敗 ↓2(Merge XSS) A03 インジェクション系攻撃 New 安全が確認されない不安な設計 A04 ↑1(Merge XXE) A05 セキュリティに関わる設定の不備 ↑3 A06 脆弱で古くなったコンポーネント ↓5 A07 識別と認証の失敗 → A08 ソフトウェアとデータの生合成の不具合 ↑1 A09 セキュリティログとモニタリングの失敗 New A10 SSRF サービス間の通信の実装不備や、ミドルウェアにおける設定不備などによっ て発生する脆弱性です。 出典 https://owasp.org/Top10/ja/A10_2021-Server-Side_Request_Forgery_%28SSRF%29/ セキュリティキャンプ地方大会 2023 東京開催 61
OWASP Top 10に見る近年の脆弱性トレンド A10 サーバーサイドリクエストフォージェリ IMDSに対してのSSRF 画像出典: https://piyolog.hatenadiary.jp/entry/2019/08/06/062154 https://docs.aws.amazon.c om/ja_j p/AWSEC 2/latest/Us erGuide/instanc edata-data-retrieval.html セキュリティキャンプ地方大会 2023 東京開催 62
#3 “設計上の抜け漏れ”というセキュリティリスク フレームワークやブラウザのデフォルト機能を用いることで無意識的に防げる脆弱性も 多くなってきました。しかしながら、セキュリティを意識しなくて良くなったわけではありません。 設計段階でセキュリティを意識し、先立って懸念事項を書き出すことで実装段階で防げる脆弱性は 多く存在します。本章では、”シフトレフト”や”DesignDocs”、”テストコード”などの現代的な開発の要素 に合わせながら、セキュリティ上のリスクにどのように立ち向かうべきか話していきます。 セキュリティキャンプ地方大会 2023 東京開催 63
“設計上の抜け漏れ”というセキュリティリスク 本章で学んでほしいこ と 1. アプリケーションのロジックや分散したソフトウェア間で発生しうる解釈のずれによって 発生するセキュリティリスクについて 2. プロダクト開発における設計と改善、拡張でいかにセキュリティを意識すべきか 3. セキュリティを意識した開発は何を生み出すのか 本章の概要 フレームワークやブラウザのデフォルト機能を用いることで無意識的に防げる脆弱性も 多くなってきました。しかしながら、セキュリティを意識しなくて良くなったわけではありません。 設計段階でセキュリティを意識し、先立って懸念事項を書き出すことで実装段階で防げる脆弱性は 多く存在します。本章では、”シフトレフト”や”DesignDoc”、”テストコード”などの現代的な開発の要素 に合わせながら、セキュリティ上のリスクにどのように立ち向かうべきか話していきます。 セキュリティキャンプ地方大会 2023 東京開催 64
#3-1 設計とリスクとセキュリティ セキュリティキャンプ地方大会 2023 東京開催 65
おさらい OWASP Top 10に見る近年の脆弱性トレンド A04 安全が確認されない不安な設計 先のWeb技術の変遷内でも2020年代において、サイバーセキュリティの重要 性が増しており、プロダクトを展開する上で顧客・提供する価値・企業の利 益を守るためになくてはならない存在になりました。 OWASP Top 10 2021 ↑4 A01 アクセス制御の不備 ↑1 A02 暗号化の失敗 ↓2(Merge XSS) A03 インジェクション系攻撃 New 安全が確認されない不安な設計 A04 ↑1(Merge XXE) A05 セキュリティに関わる設定の不備 ↑3 A06 脆弱で古くなったコンポーネント ↓5 A07 識別と認証の失敗 → A08 ソフトウェアとデータの生合成の不具合 ↑1 A09 セキュリティログとモニタリングの失敗 New A10 SSRF このA04は抽象的な表現であり、様々な脆弱性に対して広範的に内包するよ うな形になっており、少しわかりにくいカテゴリになると思います。また、 本講義における主題になるので、ここでは触れずに、後の3章にて解説を行い ます。 どのような脆弱性? ● ● ● ● ビジネスロジックの不備 認証情報の回復におけるフローの不備 セキュリティ機構の有効化漏れ SaaSの設定の定義漏れ どのような機能で発生しやすいか? ● ロジックや設定のある全ての範囲 関連する概念 ● セキュリティ・バイ・デザイン 出典 https://owasp.org/Top10/ja/A04_2021-Insecure_Design/ セキュリティキャンプ地方大会 2023 東京開催 66
問. バグや脆弱性はなぜ生まれるのか? バグや脆弱性が発生しないようにするには? セキュリティキャンプ地方大会 2023 東京開催
なぜバグが生まれるのか? ソフトウェアにおけるバグは主に二つの設計と実装の二つの工程上の要因で発生します。 設計におけるバグ ● ● ● 要求や機能における仕様の誤り 不完全な仕様 表現や記述における不良 バグの要因 ● ● ● ● システムや機能に対しての理解不足 ○ 利用にあたり用いられるユースケースへの無理解 “検討”や”考慮”が不足したり、そもそも漏れている コミュニケーション不足や誤り 単純なミス セキュリティキャンプ地方大会 2023 東京開催 68
なぜバグが生まれるのか? ソフトウェアにおけるバグは主に二つの設計と実装の二つの工程上の要因で発生します。 実装におけるバグ ● ● ● ● ロジックバグ データ不整合やデータの競合、メモリのバグ 内部や外部におけるインターフェースにおけるバグ システムやソフトウェアの構成の誤用や性能不足 バグの要因 単純ミス / 機能や仕様の理解不足 / 実装時の考慮不足 / 検討の不足 / コミュニケーションの不足 / 仕様に おける言語レベルでの理解不足/ 環境に対しての理解不足 / 横展開の漏れ セキュリティキャンプ地方大会 2023 東京開催 69
バグや脆弱性が発生しないようにするには? バグを発生させない(少なくする)開発現場 (バグを少なくするための理想の現場) 人の命や各種システムの基礎となり得るソフトウェアに関してはバグを発生させない取り組みとして、 形式手法などを用いて、バグが発生しにくいソフトウェアの開発をしています。 三 菱 総 研 形 式 手法の 実践ポ ータル 応 用事例 DB http://f ormal.mri.co.jp/db/fmtool/ セキュリティキャンプ地方大会 2023 東京開催 https://www.shoeisha.co.jp/book/detail/9784798116846 70
バグや脆弱性が発生しないようにするには? Web業体における開発 ビジネスの変化や顧客の要望により、日々ソフトウェアの機能拡張などを行っており、形式手法など を適用しにくい状況にあります。その中で、バグや脆弱性の発見はテストやレビューの段階で行って おり、システムや仕組みにより一定の網羅性を担保していたとしても、最終的には実装者やテスト実 施者、脆弱性診断士などのセキュリティエンジニアの経験則からやってくるものが多く存在します。 アジャイル等による機能拡張や改善を行う開発 (厳しくない現実的な例) セキュリティキャンプ地方大会 2023 東京開催 きびい環境の例 出典 https://eiki.hatenablog.jp/entry/meteo_fall 71
バグや脆弱性を”完全”に無くすことはできないのか? 1.技術的に可能か? 形式手法を用いた場合でも現状は”仕様”に不備があった場合はバグや脆弱性は発生しやすい状況にありま す。形式手法やツールは、自然言語で記述された仕様やUMLなどの資料を元に形式仕様に落とし込むも のであり、記述されたものがあるべき状況・状態になっていることを立証するものです。 → あるべき状況・状態が確定している状態であれば、バグの”少ない”システムやソフトウェアを作るこ とは可能である。 2.バグを探索して潰すことは可能か? 理論の話でいえば、チューリングの停止性問題における任意のプラグラムの無限ループが停止するかを 別のソフトウェアを用いて判定することは有限時間では難しいという話もある。 実務的に話すと、その関数や機能が想定したものを出力するかをTDD(テスト駆動開発)などを用いて検証 することで一定の範囲は可能ではある。しかし、”完全”という文字がつく場合、有限な時間や金銭では利 用されているライブラリやOSやドライバレベルまで調査が必要になるこのような調査は消極的事実の証 明となりうるため、バグが”完全”に存在しないと立証することは難しい。 セキュリティキャンプ地方大会 2023 東京開催 72
ではどうするべきか? 先の2つの観点から考えるに、バグを完全に無くすことというのは困難であり、一定の受容が必要になる と考えます。そのため、バグを無くすのではなく、クリティカルなバグを少なくすることが重要である と考える方が良いでしょう。 そのためには、先にあげたバグの要因をできる限り改善し、バグが発生しづらい状態を作り出すことが 重要です。 バグ発生要因の例 ● ● 設計におけるバグ ○ 要求や機能における仕様の誤り ○ 不完全な仕様 ○ 表現や記述における不良 バグの要因 ○ システムや機能に対しての理解不足 ○ 利用にあたり用いられるユースケースへの無理解 ○ “検討”や”考慮”が不足したり、そもそも漏れている ○ コミュニケーション不足や誤り ○ 単純なミス セキュリティキャンプ地方大会 2023 東京開催 ● ● 実装におけるバグ ○ ロジックバグ ○ データ不整合やデータの競合、メモリのバグ ○ 内部や外部におけるインターフェースにおけるバグ ○ システムやソフトウェアの構成の誤用や性能不足 バグの要因 単純ミス / 機能や仕様の理解不足 / 実装時の考慮不足 / 検討の不足 / コミュ ニケーションの不足 / 仕様における言語レベルでの理解不足 / 環境に対して の理解不足 / 横展開の漏れ 73
クリティカルな脆弱性や設定ミスを減らすことが重要 - 企画から詳細設計における課題の解決 設計や仕様の問題への解決策 ● ソフトウェアにおけるビジネス的なドメインの曖昧さを無くす ○ ○ ○ ○ ● 技術的可能性や懸念事項を洗い出す ○ ○ ○ ○ ● 実装しようとしている機能や周辺のドメイン・知識・概念を定義し、ソフトウェアの仕様に落とし込む 開発しようとしている機能のユースケースはどのようなものなのか、その中でEntityやModelと言ったものが、 どのように振る舞うのかを把握し、意図しない利用のされ方をしないようにする ドメインにおける確認事項や決まり事について明確にして、ルールを定義する 最終的にそのユースケースやEntity(Model)はどのような出力を行うのかの要求を定義する データのIDの衝突や不整合の可能性を整理する アカウントやデータの統合等を行う場合の手順 排他制御などの必要性について検討する セキュリティレベルでの懸念事項を整理する ■ 検証レベルでの懸念事項が発生しうるか ASVSなどを利用した社内での検討 例外の想定 ○ ○ 外部への通信や特殊な操作をする際の例外を想定し、エラーが発生した場合の処理方法を定義する 例外時の流れを適切に定める セキュリティキャンプ地方大会 2023 東京開催 74
クリティカルな脆弱性や設定ミスを減らすことが重要 - 企画から詳細設計における課題の解決 ドメインの整理と共通言語化 要件定義やシステムの仕様策定時に発生する表現の揺れや曖昧さ、ビジネスをシ ステムに落とし込む際のドメインに関する定義不足などを解決するために考えら れた設計思想がドメイン駆動設計と言われるものです。 エンジニアにとってドメイン駆動設計というとどちらかと言えば、提唱される設 計思想に合わせたアーキテクチャ(Clean Architecture)に目が行きがちではありま すが、この書籍の核心的なトピックの一つとして、”ユビキタス言語”と呼ばれる利 害関係者内での共通言語の定義にあります。 このユビキタス言語を用いることで、表記の揺れやチーム内でのコミュニケーシ ョン齟齬が減ると共に、セキュリティ的観点でいえば、実装すべきユースケース の言語化や図解も行われ、技術的課題の整理や考えられるリスクの洗い出しが行 いやすくなります。 エリック・エヴァンスのドメイン駆動設計 https://www.shoeisha.co.jp/book/detail/9784798126708 セキュリティキャンプ地方大会 2023 東京開催 75
クリティカルな脆弱性や設定ミスを減らすことが重要 - 企画から詳細設計における課題の解決 DesignDocsのような考え方と技術的懸念事項の洗い出し 近年の開発プロセスとしてアジャイルや、それに近しい形でリリースを高頻度に行う開 発が増え、そのような開発環境の中、フルスペックの企画書から詳細設計まで書くのは 不可能に近くなっています。 そこで、出てきた設計書の一書式が、 ”DesignDocs”になります。この書式では、なぜ作 るのか(“Goal”)や意図しないもの(“NotGoal”)、作成の背景、概要、要求、技術詳細の設 計、各種懸念事項、利用するツールやライブラリなどを”開発者”や”開発チーム”自らが 書くことによって一定の裁量を当事者としての責任とともに移譲します。 この書式の特徴として、開発者や開発チームがより技術の詳細に対して明確にし、技術 的な議論を行いやすくする点にあります。 例えば、実装に関しての話であれば、そもそもフルスクラッチをするのかや、利用する ライブラリについての議論を行います。セキュリティの仕様や考慮事項に関しては、該 当する機能やシステムにおけるリスクにフォーカスをすることで、できる限り明確に懸 念事項を洗い出し、実行に落とし込むことが可能になります。 簡素なDesign Docの例 セキュリティキャンプ地方大会 2023 東京開催 76
クリティカルな脆弱性や設定ミスを減らすことが重要 - 企画から詳細設計における課題の解決 DesignDocsのような考え方とセキュリティレビューの前倒し(シフトレフト)の可能性 メリット 開発チームでDesignDocsを用いて開発をしている場合、多くのチームでは相互にレビューを行い、その設計に対して助言や懸念点を伝え代替案な どを提示します。パフォーマンスやデータの不整合、利用するライブラリの管理状況に関する点まで、記述されたもの、そしてされていないもの に対してレビューを行います。 DesignDocsのメリットとして、レビュー文化の醸成とともに、設計レベルでの問題点の早期発見と、誤って実装してしまった際の手戻りの省力化、 設計に関する合意形成や複数名の視点による懸念事項の洗い出しが可能になります。また、エンジニアの学習という観点でも有効で、ハイレベル なエンジニアの知見を組織に浸透させることや、個々人が陥りやすいミスなどを把握することで、フィードバックを行いやすくなります。 懸念点 セキュリティについても、DesignDocsで他の項目同様にレビューを実施すべきであるのですが、各組織ごとに状況が異なり、セキュリティに関す る専門家や知識を有するメンバーがおらず対応できない場合や、セキュリティに対しての認識不足などの組織の特性上セキュリティに関する項目 を入れていない場合もあります。 理想論だけで言えば、DesignDocsを早くから取り入れていたGoogleでは、全社横断のセキュリティチームやプライバシーチームがセキュリティ に関する項目をレビューをするのが良いでしょう。しかし現実問題、知識的、人的に不可能な場合がありえます。 参考: Design Docs at Google https://www.industrialempathy.com/posts/desi gn-docs-at-google/ セキュリティキャンプ地方大会 2023 東京開催 77
クリティカルな脆弱性や設定ミスを減らすことが重要 - 企画から詳細設計における課題の解決 そこでASVSを用いた懸念の洗い出し OWASP ASVSは、Web Applicationにおけるセキュリテ ィ要件の定義に焦点を当てたフレームワークで、仕様書 のレビューやアプリケーションへのテストなどの検証時 にも用いることが可能です。 Design Docsのレビュー時にこのフレームワークを用いる ことで、専門的知識を一部代替することや広範なエンジ ニアが再現性のあるレビューを実施することが可能にな ります。 例: 右の図はOWASP ASVS v4におけるパスワードにおけ る検証項目で、設計においても、パスワードの関わる機 能(新規登録におけるパスワード設定やパスワード再設定 機能など)でどのような要件を盛り込むべきかがわかりや すくまとめられています。 https://github.com/OWASP/ASVS https://github.com/owasp-ja/asvs-ja セキュリティキャンプ地方大会 2023 東京開催 78
クリティカルな脆弱性や設定ミスを減らすことが重要 - 企画から詳細設計における課題の解決 バグの発見において、流れは”設計 → 実装 → テスト→バグ/脆弱性の発見”というものです。 ウォーターフォール セキュリティキャンプ地方大会 2023 東京開催 アジャイル 79
クリティカルな脆弱性や設定ミスを減らすことが重要 - 企画から詳細設計における課題の解決 Topic: 例外の想定と想定された例外をBypassされる可能性 ソフトウェアに限った話ではないが、多くのシステムには例外というものがあり、”処理を続行させ る ための例外”と、”処理を安全に終了させるための例外”というものがあります。 処理を続行させるための例外は、例外発生時に正規の手段とは別に代替手段を用いてアプリケーシ ョンの動作を安定化させることが目的にあります。 処理を続行させるための例外は、多くの場合は通信の不良や意図しないインターフェースの利用な どが発生した際に、安全に処理を終了させ、システム全体の不整合などを防ぐことが目的にありま す。 処理を続行させるための例外の場合、これを使いやすいと考え乱用し、第三者に悪用されてしまう 例が存在します。 例えばクレジットカードにおけるオーソリのシステムでは、ガソリンなどの特殊な販売形態を取る 商材の場合、クレジットカードの有効性を確認するためのオーソリと、給油後の総額が確定した後 の売上依頼の金額に差額が存在しても良いと例外をもうけている場合がある。 しかし、ここ数年において、例外の裏をついた悪用が存在している。この例で言えば、加盟店であ るガソリンスタンドが本来意図しないインターフェース利用(給油ではなくタイヤの購入)で上記の 例外を活用してしまい、悪意のある顧客がタイヤ購入を行う。オーソリが確定した後に実額の売上 依頼をせずに、引き渡しをすることで物品を渡してしまうことで、システムの悪用が行われた。 セキュリティキャンプ地方大会 2023 東京開催 出 典 : 産経新聞 https://www.sankei.com/article/20230115WMOA4NSWMRM6VHXRHDT73USG7I/ 80
クリティカルな脆弱性や設定ミスを減らすことが重要 - 詳細設計から実装における課題の解決 実装および一部詳細設計も含む問題の解決 ● ● 仕様で定義したセキュリティ上の懸念事項を実装レベルで解決する方法の熟慮 ○ 例 ■ パスワードの設定の場合、文字数や文字種の規定がある場合はValidaterを実装する 5W1Hを意識しながら意図しない動作を許可しない ○ REST APIの場合、1つのエンドポイントで色々やらせるのではなく、一つの関心事執着させる ■ ■ ● ● ● 確定しているもの: “いつ”(APIを利用する時)、”どこで “(対象のAPI) 意識するもの: ”誰が”(そのユーザーがアクセスしていいのか?)、”何を”(操作するものはなにか?)、”なぜ”(操作する意義 は?)、”どのように”(CURDのいずれかの許可は?) “正しい使い方を簡単に、誤った使い方を困難に” ○ “良いインタフェースとは次の2つの条件を満たすインタフェースのことです ” ■ 正しく使用する方が操作ミスをするより簡単 ■ 誤った使い方をすることが困難 ■ Scott Meyers https://プログラマが知るべき97のこと.com/ より ○ あらかじめ誤った操作を想定し、そのような操作を行えないようにする データの書き換えを行えないようにする ○ 正確にはImmutableな形でプログラム上のメモリを書き換えないようにする 置き換えを可能にする(保守性の向上) ○ ソフトウェアを構成する部品が変えの効かないものの場合、チューニングやなんらかの可能性で変更が必要な場合に新たなバグを 埋め込みやすくなる セキュリティキャンプ地方大会 2023 東京開催 81
クリティカルな脆弱性や設定ミスを減らすことが重要 ~ 実装例 TypeScriptで書いた例 (1) ※ 複数の ファイ ルを一 つにま とめて いるの でご了 承くだ さい セキュリティキャンプ地方大会 2023 東京開催 82
クリティカルな脆弱性や設定ミスを減らすことが重要 ~ 実装例 TypeScriptで書いた例 (1) “正しい使い方を簡単に、誤った使い方を困難に” 1. 本来意図していない文字列を許可しない 2. 誤った入力を拒否をする “正しい使い方を簡単に、誤った使い方を困難に” 1. 意図しない権限や操作を入力できないよう にenum(列挙型)を用いることで意図しな い入力が行われないようにする セキュリティキャンプ地方大会 2023 東京開催 83
クリティカルな脆弱性や設定ミスを減らすことが重要 ~ 実装例 TypeScriptで書いた例 (1) 仕様で定義したセキュリティ上の懸念事項を実装 レベルで解決する方法の熟慮 1. 整数値を入力する際に意図した値の範囲の みにする 2. 意図しない文字列が含まれないようにする セキュリティキャンプ地方大会 2023 東京開催 84
クリティカルな脆弱性や設定ミスを減らすことが重要 ~ 実装例 TypeScriptで書いた例 (2) セキュリティキャンプ地方大会 2023 東京開催 85
クリティカルな脆弱性や設定ミスを減らすことが重要 ~ 実装例 TypeScriptで書いた例 (2) 仕様で定義したセキュリティ上の懸念事項を実装 レベルで解決する方法の熟慮 1. 生の値を扱う可能性がある 2. SQL等のコンテキストの異なるソフトウェ アへデータを入力する可能性がある (ソフトウェアにおける境界線) セキュリティキャンプ地方大会 2023 東京開催 86
クリティカルな脆弱性や設定ミスを減らすことが重要 ~ 実装例 TypeScriptで書いた例 (2) データの書き換えを行えないようにする 1. 同一のClassであっても a. データの生合成を壊しかねないの で変更後はデータソースから新規 さクセをする b. 同じメモリアドレスのデータを変 更しない セキュリティキャンプ地方大会 2023 東京開催 87
クリティカルな脆弱性や設定ミスを減らすことが重要 - 詳細設計から実装における課題の解決 テストコードを書く意義と変更への耐性 近年の開発において取り入れる組織も多い、TDD(テスト駆動開発) と呼ばれる開発手法、この手法は記述されたコードの品質を担保 し、保守性と可読性、そして機能の振る舞いをコードで定義する 意味合いがあります。 セキュリティにおいても、このTDDは流用が効くもので、メジャ ーなライブラリやフレームワークにおいては、一般的に考えられ る正常系や異常系のテストに加え、セキュリティ観点でのテスト に関しても追加されるようになってきています。 Djangoなどの例では、ソフトウェアで発生した脆弱性に対して、 今後の変更によって同様の脆弱性を生み出さないための回帰テス ト(リグレッションテスト)の意味合いでテストの追加をしています。 DjangoにおけるCVE-2022-34265のSQ L injection対応におけるテストコードの追 加 https://github.com/django/dj ango/blob/599f3e2cda50ab084915ffd08edb5ad6c ad61 415/tests/db_functi ons/datetime/test_extr act_tr unc.py#L214-L228 セキュリティキャンプ地方大会 2023 東京開催 88
クリティカルな脆弱性や設定ミスを減らすことが重要 - 詳細設計から実装における課題の解決 セキュリティを意識したテストコードとその勘所 開発を行うエンジニアからしてみればいきなりセキュリティを意識したテストコートをかけと言われても「どのように書けばいいの?」となっ てしまうのは仕方ありません。そこで考えるべきは、ソフトウェアにおける境界線です。例として、下記のThe Clean Architectureをもとに話し ていきたいと思います。 まずは、要素の小さいEnterprise Business Rules(Domain ObjectやEntity 以後、Entity)からみていきましょう。この層は、アプリケーションが実 現したロジックの最小単位を構成する層で、例えばショップであればUserというEntityやProductというEntity、PriceというDomainObjectなどが 生成されます。これらは登場人物やものの”振る舞い” を定義しているため主に検証する点としては、”生成のために入力された値が定義に基づい ている”かや”意図しない文字列が含まれていない”こと、”定義された形式に乗っ取っている”ことを確認することが大事になります。(単体テスト) 次に、Application Business Rulesです。この層ではアプリケーションが実現したい事柄を関心事ごとにまとめ、先のEntityなどを作成し、それら Entityの振る舞いを用いて一連のビジネスロジック(業務フロー等)を構成します。例えば、上記のような ショップであれば、Userがカートに入れる動作や、購入を行う動作ごとなどの単位でまとめ、それらの 所作をソフトウェアレベルで定義します。検証を行うべき点としては、主語となるもの(例の場合はUser) が、適切にそれら操作が可能かの権限や意図しない値が取得された場合はどのような動作になるのかを 確認してください。(結合テスト) 最後にInterface adapter層ですが、この層では大まかな入力値の検証(過不足)や出力の検証(過剰な出力、 意図しない出力)、などがないことを確認してください。 セキュリティキャンプ地方大会 2023 東京開催 89
ぼくらはセキュリティを知らない - コストと安全と運 いまここにいる受講生の皆さんはある程度セキュリティについて理解のある方が多いと思います。しか し、多くの現場では、「セキュリティを意識したことがない」といった人や、「興味はあるがプロフェ ッショナルではない」と考える人、はたまた「餅は餅屋」、「セキュリティはコスト」「開発のブレー キになる」といろんな考えを持っている人がいます。しかし、世間的にはセキュリティが大事であると 叫ばれています。 実際、開発現場とセキュリティの需要に発生するギャップにはどのような理由があり、いかに考えるべ きなのかについて、3-1の締めとして話していきます。 セキュリティキャンプ地方大会 2023 東京開催 90
ぼくらはセキュリティを知らない - コストと安全と運 御伽話とモダン開発とセキュリティ 昔から三匹の子豚はサイバーセキュリティの例として活用されることがあります。 三匹の子豚については、みなさん知っていると思うので割愛しますが、御伽話 には多くの教訓というものが詰まっています。 三匹の子豚の場合は”ものを作る時は手早く仕上げるよりも、時間や手間をかけた 方が、安全なものになりやすく、いざという時に役に立つ”、”勤勉な人ほど最後には大きな結果を残す”, “材料をフル活用する”、”運も大事”というものが教訓としてあります。 では、これをモダンなプロダクト開発の現場(市場)に合わせて考えてみましょう。まず初めに、”ものを 作る時は手早く仕上げるよりも、時間や手間をかけた方が、安全なものになりやすく、いざという時に 役に立つ”といった点です。これは、先に挙げた例に「セキュリティはコスト」「開発のブレーキにな る」というものに合わせると、この教訓における理論的な正しさと現実的な間違えが見えてきます。 セキュリティキャンプ地方大会 2023 東京開催 91
ぼくらはセキュリティを知らない - コストと安全と運 完璧なものを作ろうと、時間をかけていたら... 堅牢なものや完璧なものを作ることは理念としては大切です。しかし、市場の競争の中ではかなり危険があるの も事実です。プロダクトの市場価値を確かめるために、最小限でまずは製品を提供する考え方として MVP(Minimum Viable Product)というものがあります。近年のSaaSビジネスとしてはこのような考え方が主流と なっており、小さく始めて大きく育てるというものです。確かにはじめから多機能高性能なSaaSが登場したら利 用者はどよめくでしょう。しかし、多機能・高性能そしてセキュアなSaaSを、小さく始めて大きく育てるといっ た他のSaaSの環境に放り込み作る場合、多額の投資と大量の人員を必要とし、それらが柔軟に動いていく必要が あり、現実的ではありません。 また、三匹の子豚に戻っていきましょう。童話の中では、三匹目のレンガの子豚が一番最後に おそわれました。そして、完成してから狼がやってきたわけです。もし、この狼が完成前に やってきたら、三匹目の子豚は食べられていたわけです。そして、家を作り終えるまでに 何らか問題があればその家には住めない可能性もあります。 三匹目の子豚は運を持っていましたが、全員がそういうわけではない、であれば運だけではなく、 この三匹全員の良いところを通り入れながら藁から木材へ、木材からレンガへと改築していくのが 堅実なのかもしれません。プロダクトセキュリティもMVPで進めていくのが重要になってくるで しょう。 セキュリティキャンプ地方大会 2023 東京開催 92
ぼくらはセキュリティを知らない - コストと安全と運 今あるものはどうしよう? スクラップアンドビルド!というのは簡単ですが、実際そのようなことを実施できる組織はごく少数でしょう。端的にい えば、優先度を決めてできる範囲でコツコツと適用していくのがいいでしょう。 優先度の決め方としては色々あると思いますが、社内にプロダクトセキュリティの担当者がいるのであれば、そのメンバ ーと一緒に何を直していくべきかなどを相談するのが良いでしょう。もしいない場合は、専門的なベンダーやそういった 人を探し出す、育てるなどしなければいけません。 ただ、それではMVP的ではないので、まずは、自分たちでいろんな情報をかきあつめやってみる、というのが大事でしょ う。例えば、先に説明したOWASP ASVSなどを用いて1から順に検証観点の理解をし、プロダクトに適用していく出会っ たりするのが良いのかもしれません。 セキュリティキャンプ地方大会 2023 東京開催 93
その先へ ~ 脅威モデリングや脅威分析 ~ セキュリティを意識し始めて余裕が出始めたら、DesignDocsなどのその先に進んでみましょう。 自身の開発するプロダクトや組織に対して、どのような脅威があるのかを言語化・モデリングをし、サ ービスのどの箇所に重点的に対策を施していくかを明確にしていくことが可能です。 ● ビジネスにおいて考えられる脅威への対策は重要 ○ ● ● 類似例として ■ 災害復旧計画(DRP)や避難訓練の前に行われる災害などの想定 ITにおいても攻撃者というものがあり脅威が存在する 国内外における事例 ○ ○ ○ ○ ○ ○ メルカリ PLAID Freee Cyber Agent SAP Facebook [参考] https://engineering.merc ari.com/blog/entry/20220426-thr eat-modeling-atmercari/ https://tech.plaid.co.jp/threat-analysis https://speakerdeck.com/freee/freee-getting-started-to-thr eat-analysis-2023 https://developers.cyber agent.c o.jp/blog/archives/40939/ https://blogs.sap.com/2023/02/03/threat-modeling-in-sap-landscape/ https://www.facebook.com/notes/358733608517668/ セキュリティキャンプ地方大会 2023 東京開催 94
#3-2 設計上の抜けによる脆弱性と攻撃 セキュリティキャンプ地方大会 2023 東京開催 95
設計上の抜けによる脆弱性と攻撃 本章で指す”設計上の抜けによる脆弱性”とは? ● 構成上、本来意図していた防御機構をBypassできてしまうもの ○ 例 ■ ● 主にビジネスロジック上のバグやOracle的な役割を果たすような動作差分例 ■ ■ ■ ● CSPの設定不備や同一ドメイン上での不適切なファイルアップロード 不正な課金の処理 ユーザーの存在を確認 アカウント統合におけるバグ アプリケーションのコンテキスト上公開やアクセスがされてはいけないもの ○ 例 ■ ■ 第三者のアップロードした重要ファイル 他人のIDを指定してのパスワード再設定 セキュリティキャンプ地方大会 2023 東京開催 96
SSOのアカウント統合時のバグ Pre Account hijack 攻撃者が事前にアカウントへアクセスを可能にする認証経路を用 意し、標的となる被害者がアカウントを利用し始めてからアカウ ントを奪取する一連の攻撃手法。 機能の大まかな要件と構成 登場する要素に関する定義 ● ● ● ● Target Service: SSOで利用されるプロトコルで呼称され る “SP(サービスプロバイダ)”で、本検証で検証対象となる サービス IdP: クラウドサービスのIdentity provider Victim: 被害者 Attacker: 攻撃者 意訳 ● ● ID: メールアドレスや電話番号などのログイン時に利用す るIDで各種SSOで連携される際に照合されるもの。 標的ID: 被害者が利用すると想定されるID 出 典 : Pre-hijacked accounts: An Empirical Study of Security Failures in User Account Creation on the Web https://arxiv .org/pdf/2205.10174.pdf セキュリティキャンプ地方大会 2023 東京開催 97
SSOのアカウント統合時のバグ Pre Account hijack 各攻撃に対する前提条件の表 セキュリティキャンプ地方大会 2023 東京開催 略語 ● ● ● ● ● CFM: Classic-Federated Merge Attack US: Unexpired Session Identifier Attack TID: Trojan Identifier Attack UE: Unexpired Email Change Attack NV:Non-Verifying IdP Attack 表記に関して ● ● ● ▲: 攻 撃において必須の要件 △: 攻 撃においてある派生系において必須になる要件 -: 攻 撃 において必要としない 98
SSOのアカウント統合時のバグ Pre Account hijack Classic-Federated Merge Attack セキュリティキャンプ地方大会 2023 東京開催 99
SSOのアカウント統合時のバグ Pre Account hijack Unexpired Session Identifier Attack セキュリティキャンプ地方大会 2023 東京開催 100
SSOのアカウント統合時のバグ Pre Account hijack Trojan Identifier Attack セキュリティキャンプ地方大会 2023 東京開催 101
SSOのアカウント統合時のバグ Pre Account hijack Unexpired Email Change Attack セキュリティキャンプ地方大会 2023 東京開催 102
SSOのアカウント統合時のバグ Pre Account hijack Non-Verifying IdP Attack セキュリティキャンプ地方大会 2023 東京開催 103
SSOのアカウント統合時のバグ Pre Account hijack 対策 Pre-hijacking Attacks全体を通して根本的原因として主張されているものは、”IDの検証不備”になる。サービスによ ってはUXの観点からIDの検証を行わずに認証やサービスへのアクセスを許可している場合があるかもしれない。た だ、この状態ではPre-hijackingが解決されないままである。 対策として、UXの観点からサービスへのアクセス自体やアカウントの作成は許可をし、何らかの重要な機能を実行 する場合は、検証プロセスの完了をMustにすることで攻撃の緩和や軽減が可能になる。 サービスの検証をIdPに依存する場合は、連携するIdPへ一定の検証実施を行なってもらう必要がある。サービス側 でも追加の検証を行うこともできるが、UXの観点から悪影響を及ぼす可能性がある。 セキュリティキャンプ地方大会 2023 東京開催 104
IDOR (Insecure Direct Object Reference) アプリケーションにおいて、DBのデータやファイルなどに、本 来意図しないユーザーが権限を有しない状態でアクセスできてし まうアクセス制御の脆弱性です。 発生しやすい機能 APIやファイルの取得などにおいて発生しやすく、Path やQuery、parameterなどに含まれるIDを変更すること でアクセスができてしまうケースが多い。 セキュリティキャンプ地方大会 2023 東京開催 105
IDOR (Insecure Direct Object Reference) アプリケーションにおいて、DBのデータやファイルなどに、本 来意図しないユーザーが権限を有しない状態でアクセスできてし まうアクセス制御の脆弱性です。 発生しやすい機能 APIやファイルの取得などにおいて発生しやすく、Path やQuery、parameterなどに含まれるIDを変更すること でアクセスができてしまうケースが多い。 セキュリティキャンプ地方大会 2023 東京開催 106
IDOR (Insecure Direct Object Reference) 実装(机上) セキュリティキャンプ地方大会 2023 東京開催 107
IDOR (Insecure Direct Object Reference) 実装(机上) 本来であれば、userIdは認証したユーザー のIDや許可したIDである必要があるが、こ のコードでは、認証の可否以外はみておら ず、そのままファイルのPathに埋め込んで しまっている。 セキュリティキャンプ地方大会 2023 東京開催 108
IDOR (Insecure Direct Object Reference) リスク ● ● 個人情報や機微な情報が第三者に閲覧・取得 顧客情報を第三者から改ざん ○ 実装次第では、アカウント乗っ取り ソフトウェア側で制御された値(このコード ではcontextから取得されたID)を用いてPath を生成し、ファイルを取得するように変更 した。 対策 ● ● 対象のデータがアクセスしたユーザーが所有す るものか確認をする 自身のデータを操作させる場合は、外部からID を指定するのではなく、認証されたユーザーの IDをソフトウェア側で制御をし利用する セキュリティキャンプ地方大会 2023 東京開催 109
#4 サービスの相互作用によって発生するセキュリティリスク 近年マイクロサービスのような小さなサービス同士の関係や、SaaS等を用いたクラウドネイティブな アプリケーションを活用し構成される、プロダクトが多くなってきました。 その中で、発生しやすくなっているものが、サービスの相互作用によって発生するセキュリティリスクです。 このようなリスクに対して、私たちはどのように立ち回るべきか、”分散システム”、”クラウドサービス”、 “ブラウザアプリケーション”等のキーワードを交えながら話していきます。 セキュリティキャンプ地方大会 2023 東京開催 110
サービスの相互作用によって発生するセキュリティリスク 本章で学んでほしいこ と コンテキストを跨いだソフトウェアが連携した際に発生する、データ等の不整合によって発生しうる セキュリティリスクについて 本章の概要 近年マイクロサービスのような小さなサービス同士の関係や、SaaS等を用いたクラウドネイティブな アプリケーションを活用し構成される、プロダクトが多くなってきました。 その中で、発生しやすくなっているものが、サービスの相互作用によって発生するセキュリティリス クです。 このようなリスクに対して、私たちはどのように立ち回るべきか、”分散システム”、”クラウドサービ ス”、“ブラウザアプリケーション”等のキーワードを交えながら話していきます。 セキュリティキャンプ地方大会 2023 東京開催 111
#4-1 複数のシステムが複雑に絡み合うようになったWeb セキュリティキャンプ地方大会 2023 東京開催
複数のシステムが複雑に絡み合うようになったWeb 近年のWebは1章でお話しした離散集合の振り子でいう離散の時期です。そのよ うな中Webを構成するシステムはより特化したものに分割され、それらが互いに 連携しあってシステムを構築するようになっています。 例えば、ここ最近話題に上がる構成として、CDNはCloudFlare、ホスティングは Vercel、DBはSupabase、認証はAuth0のような完全に新興SaaSでサーバレスな アプリケーションを提供したり、FirebaseのようなmBaaSを用いたアプリケーシ ョン、AWS、Azureなどのサーバレスサービスを組み合わせたアプリケーション、 ContainerとKubernetesを活用したマイクロサービスやモジュラーモノリスなど多 岐に渡ります。 このような中で課題になるのが、”システム間のコンテキスト(文脈)”です。 セキュリティキャンプ地方大会 2023 東京開催 113
システム間のコンテキスト(文脈) 近年のプロダクト開発において、サービスとサービスを連鎖・繋ぎ合わせ構築さ れる構成が多くなっています。 しかし、各サービス間でそのデータのコンテキストを保持しているわけではない ので、意図しない改変や入力も受け入れてしまう可能性があります。 セキュリティキャンプ地方大会 2023 東京開催 114
#4-2 コンテキストの取り違えによる悪性の相互作用 セキュリティキャンプ地方大会 2023 東京開催
コンテキストの取り違えによる悪性の相互作用 ● Race ConditionやTOCTOC ○ ● ロジックの不備 ○ ● 意図しない課金額の設定 意図しないデータの設定 ○ ○ ○ ○ ● ● ● 競合状態によるビジネスロジックの崩壊 データの意図しない箇所への反映 ■ オブジェクトストレージサービスにおけるContent-Type問題 サービス間のコンテキストの違い ■ IDaaSにおけるUser Attributeの 変 更とそのAttributeの利用による副作用 ■ Email Addressの変更に基づく副作用 外部サービスから取得した値の不適切な扱い 認証サービスにおける意図しない登録フロー ContentTypeの違いにより発生する機能差異 Request smugglingやcrlfの挿入 SSOやOIDCに関わる ○ ○ SAML IdPか らの攻撃 OIDCのToken流出によるアカウント乗っ取り(Dirty dance) セキュリティキャンプ地方大会 2023 東京開催 116
IDaaSにおけるUser Attributeの変更とそのAttributeの利用による副作用 IDaaSと呼ばれる認証に特化したサービスでは、ユーザーに紐 づく各種属性として設定可能な機能が存在します。 これら属性は多くの場合、他の連携するシステムで用いられ、 ユーザーの識別や権限の把握などに用いられます。 ユーザーの情報は、多くの場合ユーザー自身が変更可能なこ とが多く、属性を変更することで、意図しない権限の取得や、 他の攻撃を引き起こす可能性というものが考えられます。 例として、右にはUser Attributeのカスタム属性である”role”を 変更することによる権限昇格のパターンを載せています。 出典 https://blog.flatt.tech/entry/cloud_security_aws_case セキュリティキャンプ地方大会 2023 東京開催 117
IDaaSにおけるUser Attributeの変更とそのAttributeの利用による副作用 出 典 : https://security.lauritz-holtmann.de/adv isories/flickr-accounttakeov er/ セキュリティキャンプ地方大会 2023 東京開催 118
IDaaSにおけるUser Attributeの変更とそのAttributeの利用による副作用 出典: https://medium.com/@_deshi ne_/acc ount-tak e-ov er-due-to-aws-cognito-misconfiguration-7b092c667ee3 セキュリティキャンプ地方大会 2023 東京開催 119
外部サービスから取得した値の不適切な扱い 独自実装したアプリケーションが連携する外部のサービスから値を取得した際に、 検証や意図しない挿入をしてしまうことがあります。 例えば、先のIDaaSの属性のような変更可能な値を安全なものだと認識し、生の SQL文などに埋め込んでしまったり、データの取得の際のKeyとしてしてしまう ことにより、SQL InjectionやIDORなどを起こすことが可能です。 セキュリティキャンプ地方大会 2023 東京開催 120
外部サービスから取得した値の不適切な扱い 出典: 実事例で学ぶクラウドコンピュートのクレデンシャル侵害 https://unit42.paloaltonetw orks.jp/c ompromised-cloud-c ompute-credenti als/ セキュリティキャンプ地方大会 2023 東京開催 121
出力先のサービスのコンテキストを理解せずに利用する 一見正しい対策をしているように見えても、送 信先/出力先のサービスで副作用を起こす実装も 存在します。 例えば、オブジェクトストレージであるAmazon S3のPrefixは有名で、Unix系やWindows系のPath という文化に慣れたエンジニアがこのPrefixに出 会うと混乱をします。 Unix系ではPathを “../../” と指定すると親のディ レクトリに移動しますが、オブジェクトストレ ージの場合、UXの観点からPrefixをディレクト リのように見せていますが、本来のPrefixには親 子関係がありませんそのため、 “../../”はただの文 字列になるので、Path Traversal 対策は逆効果と なり、意図しないPrefixにアクセスを可能にしま す。 セキュリティキャンプ地方大会 2023 東京開催 122
出力先のサービスのコンテキストを理解せずに利用する 一見正しい対策をしているように見えても、送 信先/出力先のサービスで副作用を起こす実装も 存在します。 例えば、オブジェクトストレージであるAmazon S3のPrefixは有名で、Unix系やWindows系のPath という文化に慣れたエンジニアがこのPrefixに出 会うと混乱をします。 S3のコンソールではフォルダと表記される が実際のフォルダやディレクトリのように Unix系ではPathを “../../” と指定すると親のディ ファイルツリーのような構造にはなってい レクトリに移動しますが、オブジェクトストレ ない ージの場合、UXの観点からPrefixをディレクト リのように見せていますが、本来のPrefixには親 子関係がありませんそのため、 “../../”はただの文 字列になるので、Path Traversal 対策は逆効果と なり、意図しないPrefixにアクセスを可能にしま す。 セキュリティキャンプ地方大会 2023 東京開催 123
出力先のサービスのコンテキストを理解せずに利用する 一見正しい対策をしているように見えても、送 取得の前にnormalizeすることで、本来であ 信先/出力先のサービスで副作用を起こす実装も ればTraversalできないPrefixの移動を可能 にしてしまう。 存在します。 例えば、オブジェクトストレージであるAmazon S3のPrefixは有名で、Unix系やWindows系のPath という文化に慣れたエンジニアがこのPrefixに出 会うと混乱をします。 Unix系ではPathを “../../” と指定すると親のディ レクトリに移動しますが、オブジェクトストレ ージの場合、UXの観点からPrefixをディレクト リのように見せていますが、本来のPrefixには親 子関係がありませんそのため、 “../../”はただの文 字列になるので、Path Traversal 対策は逆効果と なり、意図しないPrefixにアクセスを可能にしま す。 セキュリティキャンプ地方大会 2023 東京開催 124
SAMLやOIDC IdPからの攻撃 SaaSが多く登場する中、UXやゼロトラスト的な観点から、 SSOなどの採用が進むようになりました。そのようなSSO を実現するためには、認証基盤は外部のSAMLやOIDCと連 携をする必要があります。 このような観点から近年では、先のPre hijackから始まり、 SaaSのSSOおよび認証基盤を対象にした研究が盛んに行わ れています。 Google(Project Zero)では、SAMLを用いたSSOのコードを 利用するライブラリレベルまで解析し、ID基盤の乗っ取り まで持っていくといったことが行われています。 参考: Hacking the Cloud With SAML https://2022.hexacon.fr/slides/Hacking-the-Cloud-With-SAML.pdf セキュリティキャンプ地方大会 2023 東京開催 125
#5 資料のまとめ Summary セキュリティキャンプ地方大会 2023 東京開催 126
まとめ ● ● ● 歴史的文脈 : 技術の発展と脅威の増加 ○ 「Webの大衆化・一般化」と「課題の解決や利便の追求を目的とした技術発展」が相互に Web世界の発展に寄与した ○ 「Webの大衆化・一般化」に伴い、サービスが保持するデータがより機微なものになる ■ 発展と一般化は悪意のある者の参入も招いた 開発の流れとしての文脈 : 安全と安心、トレードオフではなく発展と伴走を ○ バグや脆弱性を断絶することは難しい ○ 完璧な安全は有限時間で実装・構築することはむずかしい ○ サービスの開発手法であるMVPと同様、プロダクトセキュリティに関しても一歩一歩プロダ クトの発展とともに進めていく方が良い ■ セキュリティが先行しすぎても、プロダクトが先行しすぎても躓く可能性がある システムとしての文脈 : シ ステム間が相互にやり取りするデータへの警戒 ○ 異なるシステムを組み合わせることは異なるコンテキストを組み合わせるものと同位 ○ システムが連鎖する場合、信頼のおける値を作り出すことが必要 ■ 値の形式や適当性の検証、データをimmutableにするなどの対策を取る セキュリティキャンプ地方大会 2023 東京開催 127
#参考資料 / 出典 / 今後の学習のためのリソース セキュリティキャンプ地方大会 2023 東京開催 128
出典 / 参考資料 (1/n) ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● Wikipedia ○ メインフレーム, CGI, Web2.0, Web3, JavaScript, JQuery, Ruby, RubyOnRails Go, Java, AWS, Vue.js, トリアージ, プログラミング言語年表 技術選定の審美眼https://speakerdeck.com/twada/understanding-the-spiral-of-technologies NeNA ウェブフロントエンド開発に Vue や React を選択する理由 https://techcon.dena.com/2021/session/17/ Aqua A Brief History of Containers: From the 1970s Till Now https://blog.aquasec.com/a-brief-history-of-containers-from-1970s-chroot-to-docker-2016 IT Media コレ1枚で分かる「クラウドの歴史的背景」https://www.itmedia.co.jp/enterprise/articles/1606/22/news069.html サービス指向アーキテクチャ(SOA)の実際 https://atmarkit.itmedia.co.jp/fdotnet/special/realsoa01/realsoa01_01.html https://www.youtube.com/watch?v=wYUY3Cb7-ks Pixiv ベニヤ板とDCのハイブリッド!pixivインフラの今@ITmedia https://atmarkit.itmedia.co.jp/new s/201007/21/pixiv.html OWASP Top 10 https://ow asp.org/Top10/ja/ React Why did w e build React? https://legacy.reactjs.org/blog/2013/06/05/why-react.html 日経 XTECH SaaS/ASPの歴史と仕組み https://xtech.nikkei.com/it/article/lecture/20070219/262331/ クックパッド基幹システムのmicroservices化戦略 〜お台場プロジェクト1年半の軌跡〜https://techlife.cookpad.com/entry/2018-odaiba-strategy GitHub’s Journey from Monolith to Microservices https://www.infoq.com/articles/github-monolith-microservices/ GitHub 元CTO Json Warner マイクロサービスにしたことがアーキテクチャ上の最大のミスだった https://twitter.com/jasoncwarner/status/1592227285024636928 Rettyマイクロサービス移行の旅、開始からの現在位置 https://engineer.retty.me/entry/2021/06/04/110000 ニコニコ生放送がwebサービスを大人数で開発する際に辿ってきたフロントエンド アーキテクチャ https://qiita.com/kondei/items/bdd725357b4dc9d7a8ab とほほ WWWの歴史 https://www.tohoho-web.com/wwwxx018.htm CNCF Toc DEFINITION https://github.com/cncf/toc/blob/main/DEFINITION.md エンジニアのための知的生産術 https://gihyo.jp/book/2018/978-4-7741-9876-7 ブラウザハック https://www.shoeisha.co.jp/book/detail/9784798143439 Pre-hijacked accounts: An Empirical Study of Security Failures in User Account Creation on the Web https://arxiv.org/abs/2205.10174 Account hijacking using "dirty dancing" in sign-in OAuth-flows https://labs.detectify.com/2022/07/06/account-hijacking-using-dirty-dancing-in-sign-in-oauth-flows/ Mozilla コンテンツセキュリティポリシー (CSP) https://developer.mozilla.org/ja/docs/Web/HTTP/CSP Hacking AWS Cognito Misconfigurations https://notsosecure.com/hacking-aws-cognito-misconfigurations Hacking the Cloud With SAML https://2022.hexacon.fr/slides/Hacking-the-Cloud-With-SAML.pdf 東京都福祉保健局トリアージ https://www.fukushihoken.metro.tokyo.lg.jp/iryo/kyuukyuu/saigai/triage.html メルカリの脅威モデリングプロセス https://engineering.mercari.com/blog/entry/20220426-threat-modeling-at-mercari/ セキュリティキャンプ地方大会 2023 東京開催 129
出典 / 参考資料 (2/n) ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● PLAID 継続的なセキュリティ対策をするために脅威分析をしました https://tech.plaid.co.jp/threat-analysis Freee 脅威分析始めました https://speakerdeck.com/freee/freee-getting-started-to-threat-analysis-2023 CA 脅威モデリングをソリューション化させるまでの歩み https://developers.cyberagent.co.jp/blog/archives/40939/ Threat Modeling in SAP Landscape https://blogs.sap.com/2023/02/03/threat-modeling-in-sap-landscape/ Facebook Understanding Online Threats with ThreatData https://www.facebook.com/notes/358733608517668/ 東京都産業労働局 https://www.cybersecurity.metro.tokyo.lg.jp/security/KnowLedge/439/index.html PRACTICAL CLIENT SIDE PATH TRAVERSAL ATTACKS https://mr-medi.github.io/research/2022/11/04/practical-client-side-path-traversal-attacks.html パブリッククラウド特有の脅威の向き合い方 https://speakerdeck.com/lhazy/paburitukukuraudote-you-noxie-wei-noxiang-kihe-ifang 形式手法とは? http://formal.mri.co.jp/outline/ ゼロから学んだ形式手法 https://swet.dena.com/entry/2020/04/08/140500 ソフトウェア工学の道具としての形式手法 https://www.nii.ac.jp/TechReports/public_html/07-007J.pdf OWASP ASVS https://github.com/OWASP/ASVS/ デザインドックで学ぶデザインドック https://www.flywheel.jp/topics/design-doc-of-design-doc/ GoogleのDesignDocsに学ぶ https://www.industrialempathy.com/posts/design-docs-at-google/ Content-TypeとCSRFの関係性についてで参考にした資料 ○ https://hackerone.com/reports/753386 ○ https://github.com/fastify/fastify/security/advisories/GHSA-3fjj-p79j-c9hh 認可制御についての参考資料 ○ https://github.com/varvet/pundit ○ https://laravel.com/docs/10.x/authorization ○ https://docs.aws.amazon.com/ja_jp/cognito/latest/developerguide/cognito -user-pools-user-groups.html PHP Unit 4.8.28の脆弱性について ○ https://vulners.com/zdt/1337DAY-ID-37301 ○ https://jvndb.jvn.jp/ja/contents/2017/JVNDB-2017-005280.html セキュリティキャンプ地方大会 2023 東京開催 130
出典 / 参考資料 (3/n) ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● https://decoded.avast.io/vladimirmartyanov/research-shows-over-10-of-sampled-firebase-instances-open/ https://www.comparitech.com/blog/information-security/firebase-misconfiguration-report/ https://rhinosecuritylabs.com/aws/s3-ransomware-part-1-attack-vector/ https://news.netcraft.com/archives/2019/08/29/uniqlo-and-the-guardian-among-thousands-of-sites-loading-malicious-code-from-s3.html https://github.com/yandex/gixy https://github.com/sa7mon/S3Scanner Snyk: https://snyk.io/ Dependabot: https://docs.github.com/ja/code-security/dependabot/working-with-dependabot Vuls: https://github.com/future-architect/vuls/ Auditing package dependencies for security vulnerabilities https://docs.npmjs.com/auditing-package-dependencies-for-security-vulnerabilities 実事例で学ぶクラウドコンピュートのクレデンシャル侵害 https://unit42.paloaltonetworks.jp/compromised-cloud-compute-credentials/ https://github.com/ambionics/phpggc https://github.com/frohoff/ysoserial https://github.com/GrrrDog/Java-Deserialization-Cheat-Sheet https://github.com/httpvoid/writeups/blob/main/Ruby-deserialization-gadget-on-rails.md https://www.bleepingcomputer.com/news/security/trojanized-dnspy-app-drops-malware-cocktail-on-researchers-devs/ https://www.bleepingcomputer.com/news/security/pypi-python-packages-caught-sending-stolen-aws-keys-to-unsecured-sites/ https://docs.npmjs.com/threats -and-mitigations https://piyolog.hatenadiary.jp/entry/2019/08/06/062154 セキュリティキャンプ地方大会 2023 東京開催 131