Serverless ApplicationとSecurity 開発者だからこそしってほしいAmazon S3
>100 Views
August 19, 24
スライド概要
Security JAWS #34
関連スライド
各ページのテキスト
Serverless ApplicationとSecurity 開発者だからこそしってほしいAmazon S3 Security-JAWS #34 株式会社 Flatt Security - Azara / Norihide Saito
Norihide Saito / Azara 2020年に株式会社Flatt Securityに入社し、Webアプリケー ションやパブリッククラウドを対象としたプロフェッショナル サービス業務に従事。 Security-JAWSは今回で2度目 Security-JAWS Daysを含めると3度目 好きなサービス Amazon Cognito / Amazon S3 / AWS Lambda その他 https://x.com/a_zara_n/bio
多分、4年前の続編です(?) https://speakerdeck.com/azara/serverless-applicationto-sekiyuritei-cognitobian
Use this slide to highlight a single, important thing. To keep it short and https://speakerdeck.com/azara/serverless-applicationto-sekiyuritei-cognitobian sweet, you might link away to relevant Highlight doc or file.
前提の共有 責任共有モデルのおさらいと、マネージドサービスをサービス に組み込む際に気にすべき点についてお話しします。 Topic 気にすべきMetadataと脆弱性について Amazon S３におけるmetadataの特性と、そのメタデータの値 に任意のものが設定されることにより発生する脆弱性について お話しします。 実装のミスと対策 どのような実装をすることでS3のメタデータを操作できてしま うのかや、その対策について話します。
本発表は、開発者やS3を扱う事業者様に向けて要点整理を行ったものを発表するものです。 技術的詳細などにつきましては、以下のブログを参照いただければ幸いです。 オブジェクトストレージにおけるファイルアップロードセキュリティ - クラウド時代に"悪意のあるデータの書き込み"を再考する https://blog.flatt.tech/entry/object_storage S3経由でXSS!?不可思議なContent-Typeの値を利用する攻撃手法の新観点 https://blog.flatt.tech/entry/content_type
また、本件で取り扱わない内容については、こちらをご覧ください。 Amazon S3の脆弱な利用によるセキュリティリスクと対策 https://blog.flatt.tech/entry/s3_security
Amazon S3の大別して2つの セキュリティ観点
おさらい - 責任共有モデル https://aws.amazon.com/jp/blogs/news/applying-the-aws-shared-responsibility-model-to-your-gxp-solution/ 出典: AWS 責任共有モデルを GxP ソリューションに適用する
マネージドサービスで考えること マネージドサービスの設定値 暗号 バージョニン 削除保 オブジェクトロッ ロギング データへのアクセスや 情報やデータの取り扱い アプリケーション側との コンテキスト アクセス制 Bucket全体のアクセス制 ACLを用いたオブジェクトの アクセス制 IAMを用いたアクセス制御 データの取り扱 PI マルウェアスキャン アップロード時の検 署名付きURLの生成とその前 段階でのアプリケーションの アクセス制 メタデータの設定
マネージドサービスで利用者が考えること 設定値やサービスで 対応可能な範囲 マネージドサービスの設定値 暗号 バージョニン 削除保 オブジェクトロッ ロギング 実装やコンテキストに依存する範囲 データへのアクセスや 情報やデータの取り扱い アプリケーション側との コンテキスト アクセス制 Bucket全体のアクセス制 ACLを用いたオブジェクトの アクセス制 IAMを用いたアクセス制御 データの取り扱 PI マルウェアスキャン アップロード時の検 署名付きURLの生成とその前 段階でのアプリケーションの アクセス制 メタデータの設定
マネージドサービスで利用者が考えること 設定値やサービスで 対応可能な範囲 マネージドサービスの設定値 暗号 バージョニン 削除保 オブジェクトロッ ロギング 実装やコンテキストに依存する範囲 データへのアクセスや 情報やデータの取り扱い アプリケーション側との コンテキスト アクセス制 Bucket全体のアクセス制 ACLを用いたオブジェクトの アクセス制 IAMを用いたアクセス制御 データの取り扱 PI マルウェアスキャン アップロード時の検 署名付きURLの生成とその前 段階でのアプリケーションの アクセス制 メタデータの設定
Amazon S3への ファイルアップロード
Amazon S3へのアップロード方法
Amazon S3へのアップロード方法
First thing Add a quick description of each thing, with enough context to understand what’s up. Simple list Second thing Keep ‘em short and sweet, so they’re easy to scan and remember. Third thing If you’ve got a bunch, add another row, or use multiple copies of this slide.
Server Side Upload for SDK
Server Side Upload for SDK
Pre signed URL (Client Side)
Quick description about the section. Section Title
Pre signed URL (Client Side)
Pre signed URL (Client Side)
Pre signed URL (Client Side)
Amazon S3 Objectの特性と 気にすべきMetadata
First thing Add a quick description of each thing, with enough context to understand what’s up. Simple list Second thing Keep ‘em short and sweet, so they’re easy to scan and remember. Third thing If you’ve got a bunch, add another row, or use multiple copies of this slide.
出典: https://upload.wikimedia.org/wikipedia/commons/4/4b/Object_Storage_Icon.png
Metadataに付与可能な情報 https://docs.aws.amazon.com/ja_jp/AmazonS3/latest/userguide/UsingMetadata.html
Metadataに付与可能な情報 https://docs.aws.amazon.com/ja_jp/AmazonS3/latest/userguide/UsingMetadata.html
Content-Type 格納されるオブジェクトのメディアタイプで、オブジェクトを HTTP responseとして返す際のContent-Type Headerの値とし ても用いられる。 APIから変更可能な Metadataで 気にすべきもの Content-Disposition 格納されたオブジェクトの配信時の情報を格納しており、 HTTP Responseとして返す際のContent-Disposition Header の値としても用いられる。 x-amz-storage-class オブジェクトを保存する際のストレージクラスを保存してお り、何も設定していない場合は、標準クラスのストレージが指 定される。このストレージクラスはオブジェクト単位で指定が 可能。 x-amz-website-redirect-location(条件あり) Web HostingモードのS3には、Webページリダイレクト機能が存在して おり、特定の制限下でリダイレクト先の指定を行うことができる。
Content-Type 格納されるオブジェクトのメディアタイプで、オブジェクトを HTTP responseとして返す際のContent-Type Headerの値とし ても用いられる。 APIから変更可能な Metadataで 気にすべきもの Content-Disposition 格納されたオブジェクトの配信時の情報を格納しており、 HTTP Responseとして返す際のContent-Disposition Header の値としても用いられる。 x-amz-storage-class オブジェクトを保存する際のストレージクラスを保存してお り、何も設定していない場合は、標準クラスのストレージが指 定される。このストレージクラスはオブジェクト単位で指定が 可能。 x-amz-website-redirect-location(条件あり) Web HostingモードのS3には、Webページリダイレクト機能が存在して おり、特定の制限下でリダイレクト先の指定を行うことができる。
Use this slide to highlight a single, Highlight important thing. To keep it short and sweet, you might link away to relevant doc or file.
APIから変更可能な Metadataで 気にすべきもの Content-Type = XSS Content-Type は、ファイルの MIME タイプを指定するためのメタデータ です。この値は、ファイルの取得時にレスポンスヘッダーとして返却さ れ、ブラウザやクライアントアプリケーションにおいて、そのファイルの 種類を判別するために利用されます。すなわち、レンダリングを行う際の 処理に影響を与えます。 例えば、text/html という Content-Type を指定した場合、ブラウザは、 そのファイルを HTML として解釈し、レンダリングを行います。 この Content-Type を任意の値に設定することが可能な場合、アップロー ドの際に、例えば text/html という Content-Type を指定することができ ます。するとブラウザに対して、そのファイルを HTML として解釈さ せ、XSS を引き起こすことができます。
APIから変更可能な Metadataで 気にすべきもの Content-Disposition = Reflected File Download https://www.blackhat.com/docs/eu-14/materials/eu-14-Hafif-Reflected-File-Download-A-New-Web-Attack-Vector.pdf https://codeblue.jp/2023/result/pdf/cb23%EF%BD%B0filename-in-content-disposition-is-a-landmine-vulnerability-caused-by-ambiguous-requirements-by-motoyasu-saburi.pdf
APIから変更可能な Metadataで 気にすべきもの x-amz-storage-class = Storage Classに起因するEDoS https://blog.flatt.tech/entry/edos_aws
APIから変更可能な Metadataで 気にすべきもの x-amz-storage-class = Storage Classに起因するEDoS https://blog.flatt.tech/entry/edos_aws
アップロード時の実装における 実装ミス
Case 1 File Upload時の署名漏れ
① getSignedURLの設定について ❶ JavaScriptなどでは署名付きURLを発行する際に、署名を行う ヘッダーの指定を行います。その際に、指定対象のヘッダーか ら対象のヘッダーが漏れてしまうことによって署名がなされ ず、悪意のあるメタデータが設定されてしまう恐れがありま す。
Case 2 File Upload時の検証漏れ
① PutObjectCommandで利用される 値が検証されていない ❶ PutObjectCommandで用いられる値などが検証されず、そのま ま設定されることで悪意のある値が入力されてしまう。
Case 3 File Upload時の検証回避
検証において、特定の方法で検証を行なっている場合は、検証を突破できてしまう！というものです。 詳しくは Blog か、ワークショップで体験してみてください！
対策
署名付きURLを用いる場合、Metadataをで きる限り指定して生成する ユーザーにいじられてしまい困るMetadataについては、署名時に 設定、未設定問わずに署名対象のHeaderとして指定しましょう。 Validation 時の検証における対策 Content-type をはじめとする Validation を部分一致や、正規表現 などで行う場合、その検証の厳密さによって、攻撃を受けるリスク が変わります。そのため、検証の際には、完全一致もしくは、 RFC9110 などに準拠した検証を行うことが望ましいです。 また、Validation 後の処理においても、無害化されたContent-Type の値を用いることが望ましいです。例えば、Marcel::MimeType.for を用いることで、ユーザーの入力、もしくは機械的に生成された Content-Typeの値を安全な形に変換することができます。 X-Content-Type-Options による対策 現代においても、ブラウザのMime Sniffによる攻撃が現実的であることは、先 に述べている通りであり、そのリスクを低減するためには、X-Content-TypeOptions ヘッダーを用いることが望ましいです。 X-Content-Type-Options ヘッダーは、ブラウザのMime Sniffに関する動作を 指示するヘッダーでであり、nosniffを指定することで、ブラウザはMime Sniff を行わず、指定されたmime type、または解釈できなかった際はtext/plainと して解釈をします。 の を を する ファイル 配信 行うドメインやオリジン 分離 も望ましい対策として、親のドメインを含め完全に分離がなされたファイル 用のサンドボックスドメインを用意することが挙げられます。このような 形で、ファイルの配信を行うドメインやオリジンを分離することで、XSS など が発生した場合でも、攻撃者が悪用することが難しくなります。 S3の場合、S3のオリジンから直接配信することも一つの手となります。 最 配信
まとめ
マネージドサービスにおける 開発者が気にすべきセキュリティ観点 まとめ S3において、マネージドサービスとしての設定値や設定ミスに 注目してきたが、オブジェクトのアップロードにおいても設定 のミスによって攻撃者に悪用されてしまう可能性が存在する。 気にすべきMetadataと脆弱性について Amazon S3において、APIからオブジェクトのメタデータを変 更できる特性があるため、インターネットを経由し悪意のある 値に変更されてしまう可能性があります。 特にContent-Typeやx-amz-storage-classにおいては、利用者 やプロダクトの機能として利用するサービスの利用者に甚大な 被害をもたらす可能性がある。