デフォルトでは、Amazon RDS インスタンスは暗号化されません。そのため、データが盗難や不正アクセスの危険にさらされます。

"Resources": {
    "RDSDBExample": {
        "Type": "AWS::RDS::DBInstance",
        "Properties": {
            "StorageEncrypted": false,
            "DBName": "Test DB",
            "DBInstanceClass": "db.m4.large"
        }
    }
}

デフォルトでは、Amazon Redshift クラスターは暗号化されません。そのため、データが不正アクセスや盗難の危険にさらされます。

例 1: 次のテンプレートは、暗号化が有効になっていない Redshift クラスターを定義します。

"Resources": {
    "RedshiftClusterTest": {
        "Type": "AWS::Redshift::Cluster",
        "Properties": {
            "DBName": "mydb",
            "MasterUsername": "master",
            "MasterUserPassword": "masterPass",
            "NodeType": "ds2.xlarge",
            "ClusterType": "single-node",
        }
    }

Amazon S3 バケットは、サーバー側の暗号化なしで作成されます。暗号化は、適切な資格情報を持たない人がデータを読み取れないようにすることで、データ侵害を軽減します。そのため、保存時の暗号化は、GDPR、HIPAA、PCI など、一部の業界および政府のコンプライアンス要件を満たすための手段です。

デフォルトでは、SNS トピックは保存時に暗号化されません。そのため、許可されていない閲覧者にデータが公開される可能性があります。

例 1: 次のテンプレートの例では、AWS KMS キー識別子の定義を怠ったため、SNS トピックの暗号化に失敗します。

{
    "AWSTemplateFormatVersion": "2010-09-09",
    "Description": "My SNS topic",
    "Resources": {
        "MySNSTopic": {
            "Type": "AWS::SNS::Topic",
            "Properties": {
                "Subscription": [
                    {
                        "Endpoint": "MySNSEndpoint",
                        "Protocol": "sqs"
                    }
                ],
                "TopicName": "MyTopic"
            }
        }
    }
}

キーチェーン サービスを使用して、タッチ ID ベースの認証を実装できます。それには、キーチェーンにアイテムを格納して、後からアイテムを取得するにはフィンガープリントを使用することをユーザーに要求するアクセス制御を設定します。次のポリシーを使用して、フィンガープリントを使用してユーザーを認証する方法を定義できます。

- kSecAccessControlUserPresence: タッチ ID またはパスコードでのアクセスへの制約。タッチ ID が使用可能である、または登録されている必要はありません。フィンガープリントが追加または削除された場合でも、引き続きタッチ ID でアイテムにアクセスできます。
- kSecAccessControlTouchIDAny: 登録されている任意のフィンガープリントのタッチ ID でのアクセスへの制約。フィンガープリントが追加または削除された場合、アイテムは無効化されません。
- kSecAccessControlTouchIDCurrentSet: 現在登録されているフィンガープリントのタッチ ID でのアクセスへの制約。フィンガープリントが追加または削除された場合、アイテムは無効化されます。

タッチ ID を使用する場合、kSecAccessControlTouchIDCurrentSet 属性を使用して、フィンガープリントが今後追加または削除されるのを防ぐ必要があります。

例 1: 次のコードは、今後登録されるフィンガープリントでキーチェーンのアイテムをロック解除できる kSecAccessControlTouchIDAny 制約を使用しています。

    ...
    SecAccessControlRef sacRef = SecAccessControlCreateWithFlags(kCFAllocatorDefault,
                 kSecAttrAccessibleWhenPasscodeSetThisDeviceOnly,
                 kSecAccessControlTouchIDCurrentSet, 
                 nil);
    NSMutableDictionary *dict = [NSMutableDictionary dictionary];
    [dict setObject:(__bridge id)kSecClassGenericPassword forKey:(__bridge id) kSecClass];
    [dict setObject:account forKey:(__bridge id)kSecAttrAccount];
    [dict setObject:service forKey:(__bridge id) kSecAttrService];
    [dict setObject:token forKey:(__bridge id)kSecValueData];
    ...
    [dict setObject:sacRef forKey:(__bridge id)kSecAttrAccessControl];
    [dict setObject:@"Please authenticate using the Touch ID sensor." forKey:(__bridge id)kSecUseOperationPrompt];

    dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{
        OSStatus status = SecItemAdd((__bridge CFDictionaryRef)dict, nil);
    });
    ...

配布されるアプリケーションで実際に使用したり有効にしたりする予定のないコードを使用し、デバッグやテストの目的のために変数の値を出力するのは一般的な方法です。この種のデバッグコードが誤ってアプリケーションに残された場合、アプリケーションは意図しない方法で攻撃者に情報を提供してしまう場合があります。デバッグステートメントすべてが機密情報や個人情報の漏洩につながるわけでありませんが、デバッグステートメントが存在していることは、多くの場合、その周辺のコードが無視されており、メンテナンスされていない状態である可能性を示します。

ColdFusion において忘れられているデバッグコードで最も一般的な例が、<cfdump> タグです。製品開発段階においては <cfdump> の使用は許可されますが、製品版の Web アプリケーションに含まれているコードに責任を負う開発者は <cfdump> タグの使用を許可する必要があるかどうか細心の注意を払って検討する必要があります。

アプリケーションが次の場合に Cross-Frame Scripting に対して脆弱になります。

1. iframe 内への追加をアプリケーション自体に許可する場合。
2. X-Frame-Options ヘッダーを介してフレーミング ポリシーを指定できない場合。
3. JavaScript ベースのフレーム バースティング ロジックなど、低品質の防御機能を使用する場合。

クロスフレーム スクリプトに対する脆弱性は、多くの場合、クリックジャッキング攻撃の土台となり、攻撃者はこれを利用し、クロスサイト リクエスト フォージェリ攻撃やフィッシング攻撃を実行できます。