Appの保護：脅威のモデリングとアンチパターン

Appの保護：脅威のモデリングとアンチパターン

脆弱性や潜在的な脅威について考慮し、お持ちのAppのどこに安全対策をすべきかを認識することは、かつてないほど重要になっています。脅威のモデリングを通じて潜在的リスクを見つけ、共通のアンチパターンを回避する方法を理解しましょう。リスクを最小化し、あなたのAppを使用中のユーザーを保護するために、暗号化のテクニック、そしてプラットフォームによる保護を最大限に活用する方法を学びます。

リソース
- iOS Security White Paper
- - HDビデオ
  - SDビデオ
関連ビデオ

WWDC20
- プライバシーの強化で信頼を築く
ダウンロード

こんにちは WWDCへようこそ “アプリケーションの保護：脅威のモデリングとアンチパターン” リチャード･クーパーですこのセッションでは― ユーザーから託されたデータやリソースを保護しながら― アプリケーションを更に安全に守る方法についてお話します Appleで大事なのは― アプリケーションがデータを正しく処理する事ユーザーのプライバシーを尊重する事そしてその努力が損なわれないようソフトウェアが― 攻撃に対して堅牢に設計されている事です私のチームはApple内のソフトウェアチームとハードウェアチームと協力し― 開発中の製品の安全性を向上させ― 既に完成した製品の問題を見つけられるよう支援しています
いくつか役に立つテクニックを紹介しますこのトークではアプリケーションのコンテキストでセキュリティについてどのように考える事ができるかについていくつかのアイデアを取り上げます
そのためここでは threat modelingや信頼性のないデータの判別方法についてそして犯しがちな一般的な間違いをお話しします問題を分かりやすくするために― Loose Leafと呼ばれるシンプルな架空のアプリケーションを使います Loose Leafには大きな期待を寄せていて― 熱いお茶冷たいお茶タピオカティーのどれを好む人にとっても― 主要なソーシャルプラットフォームになる事を期待していますもしかするとコーヒー派にさえ…
それを目指してこの素晴らしい機能をサポートします私たちはソーシャルネットワーキングであなたの活動を世界で共有したいのですカメラを使って写真を撮り投稿するだけでなく― ライブアクションのビデオを作る事もできますまた友人とだけ話す事ができる― プライベートなティークラブもサポートしたいと思っています最後にロング形式のレビューペアリングなどを― サポートする機能を付けますこれはとても単純な例ですが― 一般のアプリケーションに共通する多くの機能を備えていますアプリケーションに注目した時最初にしたい事は― 一歩下がって threat model について考える事です Threat modeling はセキュリティのコンテキストで― どんな問題が起こり得るかを考えるプロセスですどのようなリスクに対面するかそれをどう軽減するかを― 考慮する事が重要です特定の正式なプロセスは説明しません多くのデベロッパにとって― それだけを学ぶ事は現実的でないからです
その代わり threat modelingに使用できセキュリティとリスクについて考えるのに役立ついくつかの戦略を説明しますどうやるのか？アプリケーションが持つ重要なものの１つはアセットです
Xcodeのアセットカタログで見つかるようなアセットではなくユーザーが価値があり機密でありプライベートであるとみなすものですカメラとマイク　一データ連絡先情報　写真やファイルこれらはアセットのいい例です私たちが過去数年にわたり懸命に働いてきた理由はこれらの多くにプラットフォームレベルの保護を提供するためです一般的なルールとして― ユーザーがアクセスを許可する必要がある場合それはアセットです
そうする事で制御はあなたにゆだねられ― 保護する方法を考えるのはあなたの責任になりますしかし他にもアセットを表すものがあります
ユーザーがアプリケーションに入力する意見やビューは― 非常に重要なアセットですプラットフォームの保護は役に立ちますが― それは特に注意して保護が適用されている事を― 確認する必要があるアセットのクラスですさて攻撃者がいなければ Threat modelは完成しません
これは明らかな攻撃者の例はユーザーから盗む犯罪者やあなたのプラットフォームを弱体化したい競合他社ですところがアクセスレベルが異なる可能性のある他のクラスの攻撃者についても検討の必要があります恋人や家族がその例です
これらの攻撃者からどうやって身を守りますか？
これは重要ですなぜなら物理的にも共有アカウントを介してもデバイスへのアクセスレベルが大きく異なるからです攻撃者がLoose Leafに興味を持つ事はないと思うかもしれませんが― 便利なアセットにアクセスでき意図したとおりに成功すれば― ターゲットにもなり得るのです攻撃者は定期的にソーシャルメディアや銀行系生産系出会い系アプリケーション― 更にはゲームにまで攻撃するため誰も免疫を持ちません
一般的に攻撃者が誰であるかより― 彼らがどんな能力を持ちそれがどう影響してくるかの方が― より重要です攻撃者がどのデータをコントロールできアプリケーションのどこに行くかそれを視覚化するためにデータフローダイアグラムをお勧めしますまずシステムのデータシステムの場所を引き出します
私たちの場合はウェブサイトでホストされている情報がいくつかありますそれを公開投稿やアカウント情報などに使用します
情報の一部はCloudKitにも保存されているため― 分散型ティークラブやローカルバージョンの―
投稿や画像を保存するキャッシュを作成したりできます最終的にこれらは― ユーザーの機密情報を保持する場所になります
次に活用するシステムリソースを追加する必要がありますまたデータをアプリケーションに取り込む― 他の方法を考える必要があります
私たちの場合はリンクをパスする URLハンドラがあります
そして最後に― セキュリティ境界をシステムのどこに置くかを決めますこれらの配置は非常に重要で私たちが信頼する事としない事について行う全ての決定の基礎を提供しますここで自問してほしい重要な問いは― 攻撃者が影響を与える可能性のあるアプリケーションの場所は？攻撃者がコントロールしているデータは？それをどのように利用してアセットにアクセスできるのか？今回のケースではここ― システムリソースとアプリケーションの間に境界を置きます
システムを信頼していますがコンテンツはコントロールされていません例えばユーザーが選んだファイルは信頼性のないソースからきているかもしれませんですからコンテンツを処理する場合注意が必要です
これが起こり得るいい例はカスタム書類形式です
その他のローカルアプリケーションも信頼性がないため― URLハンドラにセキュリティ境界線を置きます提供されたデータに悪意があるかもしれないからです
またアプリケーションと全てのリモートアセットとの間に― 別の境界線を置きますリモートストアにデータを書き込むのは私たちのコードですが― そうでない場合もあります攻撃者が悪意のある投稿を作成するソフトウェアを書いた可能性があるからです攻撃者がシステムのどこに影響を及ぼすかを理解したら― システムを保護するためのアーキテクチャ的方法を考える必要がありますこれはアプリケーションとウェブサイト間の接続に― 特に関連しています
ここAppleではこの接続を強化するため― App Transport Securityと呼ばれる一般的なメカニズムを提供しています
ATSはアプリケーションがURLシステムを介して行う全ての接続が― インターネット経由で転送されるユーザーのデータを適切に保護する事を保証します ATSはデフォルトでオンになっていますが利用するには― NSURLSessionのようなハイレベルのAPIを確実に使用する必要があります
そのため開発ポリシーを作成して― 下位レベルのAPIで使用できるようにします
また出荷時に Info.plistでATS機能が無効でない事を確認してください
同様に考えなければならないのはデータを保存するために使う― サーバーとローカル両方の形式です
一般的に選びたいのは解析がシンプルで検証が簡単な形式です
plistやJSONはどちらも柔軟性とセキュリティの間でバランスの取れたいい選択ですただしスキーマの検証を実行できる形式が理想的です強力なチェックと集中型のロジックを提供するためです
またこれらのストア内のユーザーデータを保護する方法も検討します CloudKitの保護はティークラブにとって十分か？それともデータを手動で暗号化する必要があるか？セキュリティ境界を敷いた時― ローカルキャッシュとアプリケーションの間には置きませんでしたなぜかと言うとアプリケーションに向かう途中でデータを検証すべきだし― ローカルに保存されたコピーは信頼できるからです iOSでは他のアプリケーションがローカルファイルを変更できないため― これは強く強制される保証ですただしmacOSでは違いますですからmacOSをサポートするのであればこのデータを― どう保護するかを考えなければなりませんサードパーティーの依存関係についても考慮する必要がありますどのライブラリを使うかセキュリティへのアプローチが私たちのものと一致しているかまたこれらの依存関係を素早くアップデートする十分なテストを行っているかリスクをアーキテクチャ的に軽減する方法を見つけたら― アプリケーションの実装を見てみましょうこのアプリケーションではオブジェクトの３つの主要なクラスがあります外部ソースからデータを取得する役割そのデータを解析しモデルに変換する役割そしてユーザーにデータを表示する役割
私たちがまず判別するのはどれがどれに当たるか― そしてどの領域が最もリスクが高いかですなぜならこれらが攻撃者が制御するデータを― 直接操作しているため― 最も注意が必要な部分だからです
リモートサーバーに保存されているデータは最も高いリスクの１つです攻撃者は私たちのサーバーに情報を作成し保存できるため― 取り扱いには注意が必要ですですがティークラブのデータはメンバーのみ更新できます CloudKitがそれを保証しますここでは攻撃者セットがより制限されているため― リスクのレベルはどの攻撃者が― threat modelの一部だと考慮するかによって異なりますこれによりシステム全体でこのデータフローを追跡し― 対応するリスクプロフィールを取得できますデータ転送を担当するコンポーネントにはいくつかリスクがありますそしてこれが特に当てはまるのは― 信頼性のないエンティティとインタラクティブな接続がある場合ですですがデータを処理しその検証を担当するものが― 最も高いリスクを持ちますここではサーバーを除外している事にご注意くださいサーバーはこのディスカッションの範囲外のためです
アプリケーション全体でこのプロセスを実行し― リスクが存在する場所― 最もこだわらなければならない場所― そしてセキュリティ問題につながる間違いを犯す可能性が最も高い場所これらのビューを取得できますまとめるとシステムにどのようなアセットがあるかを特定し― それらを保護するためにどう設計できるか― 特に輸送中および保管中のデータを保護する方法について考えます
攻撃者がアプリケーションに影響を与える可能性のある場所を特定し― システムを介してそのデータを追跡する事で― リスクの高いコンポーネントの場所を理解し― 実装中に起こり得る問題を軽減する計画を立てる事ができます
それではライアンに信頼性のないデータについて話してもらいますありがとうクーパーさてアプリケーションのセキュリティを確保する前に― 信頼性のないデータがどう侵入してくるかを特定できなくてはなりませんそれでは信頼性のないデータとは何か？簡単な事です制御できない限りその外部データは信頼できないものだと常に想定します制御できるかどうか分からない場合は最悪の場合を想定します信頼性のないデータがどの様にして― アプリケーションに侵入できるか簡単な例を見てみましょう気づかないかもしれませんがアプリケーションがカスタムURL処理を使用している場合― URLは完全に信頼性がなくどこからでもやってきます予想もしていなかった人が iMessageを介してURLを送ってきた場合でも同様にカスタムドキュメント形式を使用している場合― 解析に脆弱性がありアプリケーションを危険に晒す可能性があります
まずしなければならない事は全てのデータエントリポイントを把握する事ですそうするとアプリケーションがどのように信頼性のないデータを処理しているかが分かりますデータフローダイアグラムが完成したので― この情報を利用可能にしますこれは１つの例であり iOSおよびmacOSがアプリケーションに公開する― 全エントリポイントの完全なリストではありません一般的にアプリケーションはある程度のネットワークを使用しますこれは信頼性のないデータを扱う上で最も高い相対性のリスクを表します攻撃者はユーザーのデバイスに物理的に近接する事なく― ユーザーを標的にできるからですこれはHTTPSやビデオ通話などのピアツーピア通信― または Bluetooth通信を介してサーバーと通信する形式で起こり得ますこの例では Loose Leafにはネットワーク上の― 信頼性のないデータを処理する機能がいくつかありますそして私たちにはティー狂信者のプライバシーとセキュリティが重要であるため― デバイス間のメッセージ全てにエンドツーエンドの暗号化を実装しますここではどうやってメッセージを暗号化するか詳しく説明しませんが― セキュリティで保護されたアプリケーションを開発する場合― これらの種類のセキュリティテクノロジーの本質的な特性を理解する事が重要です暗号化はメッセージに信用性があり有効である事を意味しません簡単に言うと― メッセージが友人からのものである事は暗号が保証してくれますが― その友人が私をハッキングしないとは限りません暗号化されたメッセージのコンテンツも信頼性のないデータなのですさてアプリケーションはネットワーク経由でメッセージを受け取りますねその後通常私たちはここでメッセージ処理を行いますこれは例えば暗号化されたシグネチャの復元や検証です次にアプリケーションが― メッセージのコンテンツを読むポイントまで到達しますそこで私たちはこれらのメッセージを見て― 信頼性のあるデータとないデータを判別しますそうすれば信頼性のないデータをどの様に使用しているかが分かります従ってプロトコルを確認すると― この送信者のｅメールアドレスが確認済みである事が分かりますこの例ではこれは暗号で検証されているため― なりすましや予期できないものにはなれませんですからこれは信頼できます
次にメッセージ識別子を調べると部分的に制御可能である事が分かります部分的に制御可能というのはつまり― 値の範囲または特定タイプに縛られている事を意味します例えばこれは UUIDである必要がありますが― 誰かが有効なUUIDを送信する可能性があります
そこでメッセージのペイロードを調べ― 送信者が完全に制御している事を確認しますこれは送信者が任意のメッセージペイロードを送信できる事を意味し― アプリケーションが想定する形式ではない場合もありますですから送信者が制御するものに関してはこの信頼性のないデータを使用する前に― 検証しサニタイズする必要がありますいいですねここまで信頼性のないデータの識別および分類方法を見ましたそれでは信頼性のないデータの誤った処理方法を見てみましょう自分のアプリケーションにある同様のバグを見つける方法を学びます
ここではパストラバーサルバグを見ます非常に一般的なタイプのセキュリティバグで― アプリケーションで見つかる事があります Loose Leafではティーラテアートの写真を― 友人に送る事ができますこれがその処理をするコードのようです
この例ではダウンロードした写真を撮っていますここでの目標はそれを一時ディレクトリに移動して― システムがダウンロードした写真を削除する前に使用できるようにしますまずメソッドに何が入るかを調べます信頼性のあるデータとないデータを分け― 信頼性のないデータをどう処理しているかを見るのが目的です
ですからここでメソッドを見ると― 着信したリソースURLがランダムなファイル名である事が分かりますインターネットからダウンロードした時に― デバイスでローカルに作られますこれは送信者の影響を受けないため信頼できます
そしてここでfromIDを確認しますこれは確認済みの送信者アドレスですこの例ではこれは暗号で検証されているため― なりすましや予期できないものにはなれませんですからこれは信頼できます
次にここで名前を確認しますこれは完全に送信者が制御していますファイルの名前を伝えているのですが― 任意の文字列をここで送信する事ができますどう使うか見てみましょう名前を取って追加パスコンポーネントに渡し― テンポラリディレクトリにこの宛先パスを作成します最初にこれらのバックトラッキングコンポーネントを含む文字列を送信するとどうなりますか？これでテンポラリディレクトリの外でトラバースできるようになりましたファイルをコピーすると送信者から与えられた任意の場所に― このファイルがコピーされますこれは明らかにかなりひどいですアプリケーションのコンテナにあるアクセス可能な機密ファイルを― 上書きする可能性があるからですそこであなたはこう言います “オーケーそれじゃあ lastPathComponentを使おう” この例ではそれでうまく行き安全なファイル名が得られますところが最後のコンポーネントがバックトラッキングだった場合もこれを返しますですからそれでもまだアプリケーションの機密ファイルを上書きする可能性があります
lastPathComponentを使った場合に起こり得るもう１つの問題は― URLWithStringを使用して URLを手動で作成した場合ですなぜならlastPathComponentはスラッシュがパーセントエンコーディングで― エンコードされていた場合もこれを返すからです URLを使用するとパーセントエンコーディングが― デコードされるため意図したディレクトリの外を― トラバースする事ができます
これをする正しい方法とは何でしょう？ lastPathComponentをファイルネームに使用して― 実際にファイル名がそこに残っている事を確認します特別なパスコンポーネントと等しくない事を確認しますそうしないと離脱してファイルの処理を拒否しますそしてfileURLWithPathを使用する事を確認しますこれによってパーセントエスケープが更に増加し― この類のパーセントエンコーディング攻撃に対して脆弱でなくなりますこれから何を学びましたか？ファイルパスでリモート制御可能なパラメータを使用しない事これは大変間違いやすいものです必要な場合は例に示したように― 追加検証とサニタイズを lastPathComponentと使用します
また必ずfileURLWithPathを使用してくださいそれによりファイルパスにパーセントエスケープが追加され― 同じパーセントエスケープの攻撃に対して脆弱でなくなります通常はできる限りこのパターンは避けてくださいローカルで作成されたランダムなファイルネームのテンポラリファイルパスを使用します現在実行できるアクションは― 次のメソッドに渡されている信頼できない文字列の全ての使用をチェックする事です信頼性のないデータを誤って処理する別の例は― 制御されていないフォーマット文字列ですアプリケーションには次のようなメソッドがある可能性がありますこのメソッドではデバイスから要求メッセージを取得し― 応答を生成してそれを送信しますここで同じ演習を行いますメソッドを見て― 何が信頼できて何ができないかを確認しますそして信頼性のないデータをどう使うかを決定しますそれを見て― この名前がデバイスのローカルユーザー名である事を確認しますローカルで生成され送信者には影響されませんですからこれは信頼できます
ところがこの彼らが送信してくる要求は送信者が制御するペイロードです彼らはどのような任意の要求メッセージでも送信してきますですからこれは信頼できませんこのパラメータをどう使っているか見てみましょうまず要求を受け取りますそしてこのローカライズされたフォーマット文字列を要求から取得して― NSLocalizedStringに渡しますここでの目標は正しい応答を― デバイス上のユーザーローカル言語に生成する事です
ただしこれは任意の文字列ですローカライズできなくても彼らはここに何でも送信できますこれをフォーマット付きの文字列に渡すと― 文字列を正しくフォーマットするのに十分な引数がここにはありませんそこで何が起こるかと言うと― このスタックのコンテンツをリークし― 相手に送り返しますこれによりアプリケーションのメモリから機密情報が― 漏洩する可能性があります場合によっては攻撃者が― アプリケーションの実行を制御できる事になりますこれは絶対に避けたい事ですこれから学んだ事は？信用できないデータからフォーマット文字列指定子を生成しない事です正しいやり方は存在しないのでできる限り避けるようにしてくださいまたフォーマット指定子を検証したりフィルタリングしたりしない事おそらく誤った方法で行ってしまうでしょう
-Wformat-securityコンパイラフラグが無効になっていな事を確認してくださいデフォルトでオンになっていますが― コードのセクションでは無効にしないでくださいこれがキャッチされない場合がある事に注意が必要です例えばたった今見た例では実際にはコンパイラ警告が出ませんなぜならフォーマット文字列が文字列リテラルでない場合― コンパイラが文字列リテラルに関して何も説明できない場合があるからです
Swiftのフォーマット文字列には特に注意が必要ですなぜならSwiftは CまたはObjective-Cのようにフォーマット文字列のコンパイラ検証レベルがないからですですからSwiftでは可能な限り文字列補間を使用しますフォーマット文字列を使用する必要がある事もありますローカライズされた文字列を構築する時などですこのようなバグが発生しないように十分に気を付ける必要があります現在実行できるアクションはフォーマット文字列として次のメソッドにパスされた― 信頼性のない文字列の使用を確認する事ですこれで２つの一般的なセキュリティ問題について見てみました何を探しているのかさえ分かっていれば見つけやすいものですですがいつも必ず簡単なわけではありません多くの場合信頼性のないデータがコードを予期しない方に向けるために利用できるロジックの問題を見つけるでしょうそのうち最初に取り上げるのは腐敗の問題です
Loose Leafではティークラブのメンバーと― ライブストリームでお茶会ができますこれを行うために招待ベースのセッションステートマシンをここで使いますここでお茶会に誰かを招待し― 受領されたらこの接続された状態になりデバイスのカメラからライブストリームをシェアできますここでもう少し詳しくこの状態で何が移行するかを見てみましょう
誰かに招待状を送ると― 私は招待中の状態になり相手は招待された状態になります相手が招待を受けると両者ともこの接続された状態になり― この接続済みソケットをデバイス間でシェアするかもしれません
もし私が誰かに招待を送り― 招待を受けるメッセージも送ったらどうなるでしょうか？彼らに招待を受けてもらう事なく強制的に接続された状態にできるでしょうか？このためのコードを見てみましょう
信頼性があるまたは信頼性のないデータの差が既に分かるので― ここを素早く見てこれが検証されたアドレスで― 信頼できる事が分かりますこれは送信者が制御しているメッセージで信頼できませんつまりここではメッセージのタイプを分けてタイプごとにハンドラにディスパッチしているのですですがこれは送信者制御のペイロードから来るので― どんなメッセージタイプでも送る事ができますこの場合 inviteAcceptメッセージを見たのいので― ここのハンドルにジャンプします送信者から送られたセッションIDに基づいてこのセッションが存在する事を確認し― “接続済”状態に設定しているようですこのケースでは― 送信者は私たちを強制的に接続された状態にできるようですおそらくここにチェックが足りません私たちが実際には招待中の状態にあり― 移行する前に“invite accept”のメッセージを待っている状態である事を確認しますそれで十分でしょうか？いえそうではないでしょうおそらく他にも確認事項があり実行前に― TRUEでなければならない state invariant条件がありますこの場合私たちを移行させる受諾メッセージが― 実際に招待した人からである事を確認したいのですこれから何を学びましたか？実行前にTRUEでなければならない明白なstate invariantを定義しますしかし本当に微妙であるため間違いを起こしやすい事もありますこの例では正しい状態にあるかを確認するだけでなく― 続行する前に検証する必要のある他のプロパティがありましたまたこのチェックのいずれかが失敗した場合早期に救済し続行を拒否します状態を変更する可能性のある予期しない方向に― コードを移動させたくないからですもう１つ見つける可能性のあるロジックのバグは信頼性のないデータに便乗していますそこでアプリケーションでは送信者からネットワーク経由で提供された― JSONデータを取得しそこからリモートエントリを持つディクショナリを作成して― 多くのメッセージ処理を行う必要があります
処理が終わったらこのエントリをディクショナリにピン止めします次にこのディクショナリをアプリケーションの他の場所に移動し― おそらくUI またはデータベースを更新しますそしてアプリケーションにたどり着きそれを使う時― 使用前にどれに信頼性があるのかを調べる必要がありますそこでディクショナリを見ます “これはリモートエントリ”で “これは送信者制御エントリ”だと分かりますインターネット経由で送信されると分かっているからですでも他のエントリは信頼できるものでしょうか？信頼できると思うかもしれませんなぜならアプリケーションがローカルに生成しているので― 送信者が制御しているものではないからですところが蓋を開けてみるとこれは信頼できませんなぜならこれは送信者が制御するメッセージから来ているためですこのエントリも同様に提供されますそしてこの他のエントリがピン止めされていない― 予想外のパスにアプリケーションを押しやると実際にメッセージを使用する時リモート送信者から来たのかローカルで生成されたのかが分からなくなりますですから信用できないものと想定する必要があります
もう１つの例を見てみましょう他の人のライブお茶会に参加できる機能を追加し― リアクションの画像を表示して考えを表す事ができるようになりました JSONデータからこのリアクションオブジェクトを作成したようです画像データが添付されている場合― メッセージ処理の間にローカルファイルにURLを書き込んでリアクションオブジェクトに imageURLとして設定しますそれからViewControllerにパスして表示しますここで何が起きるかを見てみましょう imageURLがnon-nilの場合それを表示します…
表示が終わったらディスクに書き込まれた画像を削除しますところが信頼性のないデータと一緒に作成された同じオブジェクトから― imageURLを取っているためアプリケーションのコンテナからアクセスできる任意のファイルを― 攻撃者が削除できるようになってしまいました imageURLが既に設定された状態で誰かがこのメッセージを送信すると― 画像データが設定されていなかったためこのコードブロックをスキップして― ここに直接表示しますところがimageURLは設定されているためファイルパスにあるものを表示しようとしますが実際にはJSONで指定されたファイルを全て削除してしまいますこれから何を学びましたか？信頼性のあるデータとないデータを完全に異なるオブジェクトに分離する事です１つのオブジェクトに結合しようとしないでくださいそれにより信頼性のあるパラメータとないパラメータの間が曖昧になってしまうからですどれに信頼性がないのかをいつも明白にして信頼性がないデータの使用を監査し― 使用前は必ず実証されサニタイズされているようにします次はクーパーによる NSCodingについてのトークですありがとうライアン NSCodingおよびより現代的な NSSecureCodingコンパニオンは― オブジェクトの複雑なグラフをシリアライズおよびデシリアライズする― 貴重な機能を長い間提供してきましたこれは解析されたデータをローカルキャッシュに格納したり― カスタムドキュメント形式に使用したりするものです今日はよく見る間違いや― 信頼性がないデータからアーカイブが来た場合に特に危険なケースを紹介します
まず始めに NSUnarchiverの使用を止めてくださいこれは長い間軽視され続けており― 信頼性がないソースからのデータには適していませんお勧めするのは NSKeyedUnarchiverです NSUnarchiverに似ていますがオブジェクトのグラフをパックやアンパックでき― 安全に使用できます
NSKeyedUnarchiverも長い間使用されているため― 好ましくない使われ方もあります多くが好ましくない方法で使用されておりソフトウェアを離れてユーザーが攻撃に晒されている事に気が付いていませんこの一番上のメソッドが使用していただきたいものです底のものは既に遺産と化しているため使用されている場合は― できるだけ早く移行する必要がありますこの２つのネーミングは非常に似ていますが― 非推奨のものは全て “from”ではなく“with”が付いていますこれらのメソッドを非推奨にした理由は― セキュアコーディングとの互換性がないためですセキュアコーディングとは何か完全にご存じないかもしれませんので― どのような働きをするか見てみましょう
セキュアコーディングがないと― アーカイブを取り上げて unarchiveObjectWithDataを呼び出す時オブジェクトグラフがアンパックされますこの例では文字列の配列が返される事を予期しています
ここでの問題は作成されるオブジェクトの種類がアーカイブ内で指定されている事です信頼性がないソースから来た場合または攻撃者が変更できる場合 NSCoding準拠オブジェクトを返す事ができます
つまり攻撃者がアーカイブを変更し全く予想もしていなかったクラスを WKWebViewのように― アンパックしてしまうという事ですこのオブジェクトは期待するインターフェイスと適合しないかもしれずタイプチェックを実行したとしても― セキュリティの問題が残りますクラスのアーカイブ解除中に攻撃者が達する事ができるバグが― 既にトリガされているからですセキュアコーディングでは互換性のあるクラスを制限する事でこれらの問題を解決しセキュアコーディングプロトコルを実装する― 各呼び出しサイトで期待するクラスを指定する必要があります
この情報はKeyedUnarchiverで使用され― デコードが施行される前に検証を実行します
こうする事で攻撃者が利用できるクラス数が― 劇的に減少するため攻撃対象領域も減少しますそれでもよくある間違いがまだまだありますいくつか見てみましょう
この簡単な例では― セキュアコーディングを使用してオブジェクト配列を取得しています
ここでの問題はallowedClassesセットで NSObjectを指定した事です
セキュアコーディングはプロトコルに準拠し allowedClassesセットまたは― 指定されたサブクラスのいずれかにあるオブジェクトをデコードします全てのオブジェクトは NSObjectから派生しているため安全にコード化されたオブジェクトがデコードされ― セキュアコーディングによる攻撃面の縮小が損なわれますこれは見つかりやすい簡単な例ですが― 複数のフレームワーク階層を通り― 最終的にKeyedUnarchiverメソッドに提供されるより複雑なケースでも散見されます
より簡単なパターンをお見せします文字列はアーカイブからデコードされますその後文字列はNSClassFromString経由でクラスの検索に使用され― 結果のクラスはオブジェクトを抽出するための allowedClassとして使用されます
ここでの問題は明らかです
classNameもその結果として許可された allowedClassも攻撃者の制御下にあります
そのため特定のクラスや NSObjectの名前を簡単に引き渡し― セキュアコーディングの利点を回避しますこれらの問題をどう解決するか？可能であれば制限された静的クラスのセットを使用し大きな階層のベースとなるクラスを避け攻撃者が利用できるクラス数を減らします動的クラスをサポートするケースの場合はどうでしょうか？これを一番よく見るのはプラグインのサポートを必要とする場所です
その場合 allowedClassリストを信頼できるデータからのみ― 作成する事をお勧めします一番簡単な方法はプラグインがプロトコルをサポートする場合です従ってランタイムが認識しているクラスを全て列挙し― プロトコルに準拠するクラスのセットを作成します
クラスリストは攻撃者の制御外にあるためセキュアデコーディングで安全に使用できます要約すると非奨励の全てのメソッドとクラスからコードを移行し― NSObjectを使用するかまたは過度に一般的な基本クラスの使用を避けて― 静的なallowedClassリストを可能な限り使用しますそれができない時は信頼性のあるデータから作成します
もう１つできる事はそれを完全に避けて― Swift Codable または柔軟性の少ない plistやJSONやprotobufのような― エンコーディング形式を使用します信頼性のないデータを扱う領域で― これらのデータを使用するためにコードベースを検索する事でこの情報に直ちに対応できます高リスクのコードを悩ませるもう１つの問題はメモリの破損です
Objective-C またはSwift's Unsafe-Pointerを使用する時はいつでも― メモリの安全性の問題が発生する可能性がありますバッファ文字列または構造化されたアーカイブからの― 信頼性のないデータを解析する時に特によくあります
いくつか例を見てみましょう
既にお話ししたように信頼性のないデータが― 信頼性のあるデータと間違えられた時セキュリティ問題が起こります
この例ではプライベートなティークラブのために― CloudKitをアンパックしますまず UUIDのバイトをiVarにコピーします
それぞれのエレメントを見ると CKRecordはCloudKitから生成されているため― 信頼性がありますしかしそこから引き出したデータは攻撃者の制御下にありますですからここに一定量のデータが含まれているか信頼できません
ここでの問題はデータの長さは攻撃者の制御下にあるものの― UUID iVarのサイズは固定されている事です
そのため提供されたNSDataが UUIDが保持できるより多い場合― 攻撃者の制御下にあるデータは範囲外に書き込まれます
これが問題となる理由を確認するには起こり得る事を調べる必要があります
UUIDを含むオブジェクトでは― 次のiVarがローカルキャッシュへのパスになっているのが見えますこのフィールドは CloudKit記録から設定されていませんそのため UUIDをオーバーフローさせる事で攻撃者は― 本来持つべきでないフィールドを制御できるようになります memcpy により攻撃者が制御できるデータが意図したとおりにUUIDに書き込まれますが― サイズが大きすぎるため localCachePathにオーバーフローします
これによってグループのキャッシュを再構成しファイルをダウンロードさせ― ユーザーのローカル設定を上書きする事ができます攻撃者は様々な手法やこれらのバグを使って― アプリケーション内でコードを実行しそれによってユーザーのデータへのアクセス権と― 与えられた全てのリソースへのアクセス権を得ますこれに対する修正は sizeof(_UUID)を使う事ですが― それによって更に別の問題が露呈します例えば攻撃者が予期していたより少ないデータを提供した場合― memcpy は“データ”の終わりを読み取ってメモリにある他のユーザーの機密情報を UUIDフィールドに開示させますアプリケーションがその情報をサーバーに同期すると― ユーザーデータはエンコードされ攻撃者に返されます
正しく検証しく修正するにはそのオブジェクトがNSDataであると検証し長さが正確に一致する事を確認しますこれにより宛先の上書きとソースの過剰な読み込みが両方防止されます
これはシンプルな例ですが― 信頼性のないデータを解析する時にはいつもより注意が必要です特にフォーマットが複雑であったりネストしている場合は注意してくださいいつも必ず長さを確認してください C構造体をバッファにキャストするだけでも― データが不十分だとユーザー情報が開示されてしまいます
注意が必要なもう１つのケースは整数を扱う場合ですこれはオーバーフローする傾向があるためです
この例では同じメソッドを更に掘り下げて― UNICHAR文字を含むNSDataを抽出し― 別のフィールドからカウントします以前と同じようにどのデータが信頼できるかを確認する必要がありますこのケースでは名前とカウントの両方に信頼性がありませんなぜなら両方とも攻撃者が制御するデータから来ているためです
さてデベロッパが盲目的にカウントを信頼する危険を予見したので― データの長さに対してそれを検証しますところがここに問題があります攻撃者がこの比較の両サイドを制御しデベロッパが作った推定がもはや正しくないという一連の値が存在します
この場合攻撃者が “名前”に長さ0の文字列と― nameCountに８千万の16進数を渡すと整数がオーバーフローし “if”ステートメントが失敗します
これにより“名前”の末尾から非常に大きな読み取りが行われ― ユーザーデータが開示される可能性がありますこれを修正するには包括的な検証チェックを追加し― タイプと長さを確認します一番大事なのは― os_overflowメソッドを利用して演算を行う事ですこの場合私たちはos_mul_overflowを使いましたご存じない方へ説明すると― os_overflowは数値を安全に処理しアンダーもしくはオーバーフローの状態を確実に検出できる便利な関数のセットです使うのは簡単です算術演算を関連するos_overflowメソッドに置き換えるだけです私たちは２つと３つのパラメータ両方を使用して― 加算減算乗算用パラメータを用意しました
オーバーフロー時にはゼロ以外を返しますこれらを使う事で攻撃者制御の値を使用して― 安全に計算できますつまりまとめると― 常に長さを検証しあらゆるケースを考慮する事大きすぎるもの小さすぎるもの丁度よくなければなりません
数値を扱う際は算術に注意してください os_overflow関数を使用していないかのように― 間違いを犯すリスクが高いからです
最後にリスクの高いコードパスに Swiftを使用する事を真剣に検討してくださいただしUnsafePointerやその他 rawメモリを操作する― 機能の使用は避けてください最後に― このトークでセキュリティについて考える方法のいくつかのアイデアと― 試みて回避すべき一般的な落とし穴の例をお伝えできている事を願っていますセキュリティは巨大なトピックで難しいものですこれまでに見てきたように― ほんの些細なエラーでアプリケーション全体が危険に晒される事もあります
ですがリスクがどこにあるかを理解してリスクを軽減するように設計し― 信頼性のないデータを扱う時に注意を払えば問題が発生する可能性を大幅に減らす事ができますご視聴ありがとうございました

func handleIncomingFile(_ incomingResourceURL: URL, with name: String, from fromID: String) {
    guard
         case let safeFileName = name.lastPathComponent, 
         safeFileName.count > 0,
         safeFileName != "..", safeFileName != "." else { return }

    let destinationFileURL = URL(fileURLWithPath: NSTemporaryDirectory())
                                 .appendingPathComponent(safeFileName)

    // Copy the file into a temporary directory
    try! FileManager.default.copyItem(at: incomingResourceURL, to: destinationFileURL)

}

22:26 - State management

func handleSessionInviteAccepted(with message: RemoteMessage, from fromID: String) {
    guard session = sessionsByIdentifier[message.sessionIdentifier],
          session.state == .inviting,
          session.invitedFromIdentifiers.contains(fromID) else { return }

    session.state = .connected
    session.setupSocket(to: fromID) { socket in
        cameraController.send(to: socket)
    }
}

30:56 - Safe dynamic allowedClasses

NSSet *classesWhichConformToProtocol(Protocol *protocol) {
    NSMutableSet *conformingClasses = [NSMutableSet set];
    
    unsigned int classesCount = 0;
    Class *classes = objc_copyClassList(&classesCount);
    if (classes != NULL) {
        for (unsigned int i = 0; i < classesCount; i++) {
            if (class_conformsToProtocol(classes[i], protocol)) {
                [conformingClasses addObject: classes[i]];
            }
        }
        free(classes);
    }
    return conformingClasses;
}

34:23 - Buffer overflows

@implementation
- (BOOL)unpackTeaClubRecord:(CKRecord *)record {
    ...
    NSData *data = [record objectForKey:@"uuid"];
    if (data == nil ||
        ![data isKindOfClass:[NSData class]] ||
        data.length != sizeof(_uuid)) {
        return NO;
    }
    memcpy(&_uuid, data.bytes, data.length);
    ...

36:06 - Integer overflows

@implementation
- (BOOL)unpackTeaClubRecord:(CKRecord *)record {
    ...
    NSData *name = [record objectForKey:@"name"];
    int32_t count = [[record objectForKey:@"nameCount"] unsignedIntegerValue];
    int32_t byteCount = 0;
    if (name == nil ||
        ![name isKindOfClass:[NSData class]] ||
        os_mul_overflow(count, sizeof(unichar), &byteCount) ||
        name.length != byteCount) {
        return NO;
    }
    _name = [[NSString alloc] initWithCharacters:name.bytes 
                                          length:count];
    ...

特定のトピックをお探しの場合は、上にトピックを入力すると、関連するトピックにすばやく移動できます。

クエリの送信中にエラーが発生しました。インターネット接続を確認して、もう一度お試しください。

リソース

関連ビデオ

WWDC20