本リポジトリは AWS を用いて実装したアプリケーションに置いて発生するセキュリティ上の課題を見つけ出すためのハンズオンです。
主に取り扱う内容としては下記の内容を想定しています。
- Cognito User Pool における権限の昇格
- Cognito User Pool における意図しない Self-signup
- S3 における署名付き URL 生成時の不適切な Path の扱い
- AWS のサービスの値を無制限に信用することによって発生するアプリケーション上の脆弱性
また、今後も課題を追加、更新していく予定です。
利用には、ご自身の AWS アカウントが必要となります。環境の展開には、Docker を用いた環境構築用のコンテナを用意していますので、そちらを利用してください。
本リポジトリでは、シナリオベースにセキュリティ上の課題を確認することのできるハンズオンを用意しております。
ハンズオンを行う皆様は、サービスを展開する企業のセキュリティ担当のエンジニアです。その中で、あるインシデントを起因に開発者からセキュリティレビューの依頼を受けました。
皆様は、問題点を突き、CDK{[任意のアルファベット + 英数]}
という形式のフラグを取得してください。
- ミニアプリケーションのアンチパターンを突き止め、フラグを取得する
- ミニアプリケーションのアンチパターンを修正し、フラグが取得できないことを確認する
私たちの作ったファイル共有アプリは全てクラウド上の SaaS や FaaS を用いて提供しています。 認証には IDaaS を使っており、権限の管理も全て IDaaS で行っていて安全だと思っていました。
しかし、ここ数日の間に何者かによって管理者権限が取得され、お客様がアップロードをした大切な情報が盗まれてしまいました。 そこで、実際にどのような攻撃を受けたのが再現していただくために、本番で用いた設定をもとに、認証における再現環境を用意しましたので、どのようにして管理者権限を取得したのか調査してください。
背景(ネタバレ)
ハンズオン環境では AWS の Amazon Cognito User Pool のカスタム属性を用いて、ユーザーの Role を管理をしており、管理者権限を持つユーザーは`admin`という属性値を持つことで管理者権限を持つようになっています。Amazon Cognito User Pool のカスタム属性は、ユーザーが自由に設定できる属性値であり、サーバレスなアプリケーションにおいては、この属性値を用いることで多くの情報を管理することができます。
そのような機能を用いて、権限を管理していたのが今回のこのアプリケーションです。
確認すべきこと(ネタバレ)
**IDaaS に設定している値は、サーバーサイドで重要な操作に利用していますか?**権限の確認(Role 等)うあ User の確認(User Id 等)のためにこれらの値を用いている場合は、今一度 IDaaS に設定している値が、クライアントから操作されても良い値なのかを整理し、設定を見直すことをおすすめします。
先日の調査はありがとうございます! 調査いただいた情報をもとに、管理方法を変えて管理画面を分離してみました。 これなら管理画面に意図しないユーザーが入ってこれないはずです!
セキュリティ的懸念がないかもう一度調査していただけないでしょうか? よろしくお願いいたします。
背景(ネタバレ)
開発者は Challenge 1 での設定ミスを修正として、管理者画面の IDaaS をもう一つ用意し、管理者画面とユーザー画面を分離しました。ただ、過去の事例から似たような攻撃が起こるのではないかと心配した開発者は、管理者画面に対して再度セキュリティ診断をしてもらいたいと依頼してきました。確認すべきこと(ネタバレ)
**構築中/運用中のシステムやプロダクトは第三者からの新規登録を受け付けていますか?**IDaaS を用いたシステムやプロダクトの場合、従来の独自で構築された認証システムとは異なり、疎結合な形で認証や新規登録を行うことができる一方、そのシステムやプロダクトのユーザー登録のコンテキストと噛み合わない設定になっている場合があります。
例えば、管理者画面からユーザーの登録を行うために、Self Signup のエンドポイントを用いており、UI 上は管理者側のみから操作できるようになっているものの、直接リクエストを行うことで、ユーザーの登録が可能になっているケースなどがあります。
管理画面では散々な目に遭いました...、今では管理画面側は修正して意図しない人からのアクセスを防げるようになりました。 次は私たちの提供する File 共有サービス「File Box」のセキュリティ診断をしてほしいです。 このサービスは、ファイルを保管と共有をするサービスで、ユーザーは自分自身のファイル以外はダウンロードも閲覧もできないように署名付き URL を利用しています。
また、ユーザーの ID も UUIDv4 を使っているので推測や総当たりにも耐えられるはずです!
背景(ネタバレ)
開発者は Challenge2 の脆弱性を修正し、サービス本体のセキュリティ対策を行おうと、サービス側のセキュリティ診断を依頼してきました。その中で、S3 Bucket から Object を取得する際に、署名付き URL を作成している箇所で、ユーザーの入力を利用していることが発覚しました。
この実装のミスは、S3 にホストされているファイルに対して、ユーザーが意図しないファイルにアクセスできてしまうというものです。
確認すべきこと(ネタバレ)
**署名付き URL を生成する際に、ユーザーの入力を利用していませんか?**署名付き URL に限りませんが、ユーザーの入力を利用している箇所では、サービスが意図しない動作をする可能性があります。
まさか、署名付き URL だけではダメだったんですね... 次はアドバイスをもらったように、IDaaS の属性を使った ABAC を取り入れてみました! それに、今度こそは意図しないファイルにアクセスできないようにフィルタリングを入れたので安全です!
背景(ネタバレ)
開発者はChallenge 3 での脆弱性を修正し、ユーザーの入力を全て信用せずに、Cognitoのカスタム属性からそのユーザーのPrefixを取得し、S3 Bucket から Object を取得するようにしました。しかし、Cognito User Pool の設定では、カスタム属性の値をユーザーが自由に設定できるようになっており、結果的に意図しないファイルにアクセスできてしまうという問題が発覚しました。
確認すべきこと(ネタバレ)
**クラウドサービスから取得した値を、そのまま利用していませんか?**クラウドサービスから取得した値は、ユーザーが自由に設定できる場合があります。そのため、その値をそのまま利用すると、意図しない動作をする可能性があります。
対策として、その値も信用せずに、サービス側でフィルタリングを行う必要があります。
認証情報は、/deploy/
の配下にaws
ディレクトりを作成し、credentials
ファイルを作成してください。
既存の認証情報を利用する場合
mkdir -p ./deploy/aws
cp /path/to/your/credentials ./aws/credentials
推奨
.gitignore
を利用して、credentials
ファイルを Git の管理対象から外しておりますが、誤って Git の管理対象に含まれてしまう可能性は存在します。そのため、git-secretsなどのツールを利用して、認証情報が Git の管理対象に含まれないようにしてください。
make setup
make init
make bash-cdk
make destroy
make bash-react
- セキュリティミニキャンプ 東京 2023 (v1)
- AWS DevDay 2023 E-2 (v1)
- セキュリティミニキャンプ 東京 2023 (v1)