APIs destinadas apenas para fins de depuração são usadas.

Por padrão, os fluxos de tarefas em um aplicativo Fusion não são diretamente acessíveis a partir de uma solicitação GET: sempre que um URL tenta invocar o fluxo de tarefas, ele recebe um código de status HTTP 403. No entanto, confiar em uma configuração implícita sempre carece de clareza e pode levar a um comportamento indesejado se a configuração padrão for alterada posteriormente.

Exemplo 1: O seguinte trecho de um arquivo de definição de fluxo de tarefas mostra o mesmo fluxo de tarefas definida com a configuração implícita url-invoke-disallowed por padrão.

...
    <task-flow-definition id="password">
        <default-activity>PasswordPrompt</default-activity>
        <view id="PasswordPrompt">
            <page>/PasswordPrompt.jsff</page>
        </view>
        <use-page-fragments/>
    </task-flow-definition>
...

O armazenamento de chaves de criptografia em campos de classe estática permite a recuperação fácil por uma entidade que pode acessar a memória de processo (por exemplo, dispositivo com raiz) ou despejos de memória de processo (por exemplo, despejos de memória).

Uma prática comum de desenvolvimento é adicionar código "back door" (porta dos fundos), projetado especificamente para fins de depuração ou teste, que não se destina a ser enviado ou implantado com o aplicativo. Quando esse tipo de código de depuração é acidentalmente deixado no aplicativo, o aplicativo fica aberto a modos não intencionais de interação. Esses pontos de entrada "back door" criam riscos de segurança, pois não são levados em consideração durante procedimentos de design ou teste e não se enquadram nas condições operacionais esperadas do aplicativo.

Por padrão, os volumes EBS não são criptografados.
Exemplo 1: O exemplo a seguir expõe os dados a um possível roubo e acesso não autorizado.

	Resources:
  	  EBSVOLExample:
    	Type: AWS::EC2::Volume
    	Properties:
      	  Encrypted: false
	

Por padrão, as instâncias do Amazon RDS não são criptografadas. Isso expõe os dados a um possível roubo e acesso não autorizado.

Por padrão, os clusters do Amazon Redshift não são criptografados. Isso expõe os dados a acesso não autorizado e possível roubo.

Um bucket do Amazon S3 é criado sem criptografia no lado do servidor. A criptografia atenua as violações de dados tornando os dados ilegíveis para qualquer pessoa sem as credenciais adequadas. A criptografia em repouso pode ajudar a atender alguns requisitos de conformidade industrial e governamental, como GDPR, HIPAA e PCI.

Os métodos de Gateway da API AWS que são publicamente acessíveis podem expor a organização a ataques.

Exemplo 1: O modelo de exemplo a seguir define os métodos de Gateway da API AWS acessíveis publicamente.

{
    "AWSTemplateFormatVersion": "2010-09-09",
    "Resources": {
        "MyMethod0": {
            "Type": "AWS::ApiGateway::Method",
            "Properties": {
                "RestApiId": "MyAPIID",
                "ResourceId": "MyResourceID",
                "HttpMethod": "GET",
                "AuthorizationType": "NONE"
            }
        },
        "MyMethod1": {
            "Type": "AWS::ApiGateway::Method",
            "Properties": {
                "RestApiId": "MyAPIID",
                "ResourceId": "MyResourceID",
                "HttpMethod": "POST",
                "AuthorizationType": "NONE",
                "ApiKeyRequired": false
            }
        }
    }
}

Uma configuração curinga para lambda principais viola o princípio de privilégios mínimos e permite que um invasor invoque o lambda de qualquer conta.

Exemplo 1: O modelo de exemplo a seguir define um lambda principal curinga.

{
    "Resources": {
        "LambdaPerm": {
            "Type": "AWS::Lambda::Permission",
            "Properties": {
            "SourceAccount": "AWS::AccountId",
            "SourceArn": "bucket.Arn",
            "FunctionName": "function.Arn",
            "Action": "lambda:InvokeFunction",
            "Principal": "*"
            }
        }
    },
    "AWSTemplateFormatVersion": "2010-09-09",
    "Description": "Lambda Permission"
}

Por padrão, as instâncias do Amazon DocumentDB não são criptografadas. Isso expõe os dados a acesso não autorizado e possível roubo.

Exemplo 1: O exemplo a seguir mostra um modelo que define um Amazon DocumentDB com criptografia desabilitada.

"Resources": {
    "DocDBDefault": {
        "Type": "AWS::DocDB::DBCluster",
        "Properties": {
            "MasterUsername": "name",
            "MasterUserPassword": "password"
        }
    }

Por padrão, os volumes EBS não são criptografados.
Exemplo 1: O exemplo a seguir expõe os dados a um possível roubo e acesso não autorizado.

"Resources": {
    "EBSVOLExample": {
        "Type": "AWS::EC2::Volume",
        "Properties": {
            "Encrypted": false,
        }
    }
}

Por padrão, os Grupos de Replicação do Amazon ElastiCache não são criptografados. Isso expõe os dados a acesso não autorizado e possível roubo.

Exemplo 1: O modelo de exemplo a seguir define um Grupo de Replicação do Amazon ElastiCache com criptografia desabilitada.

{
    "Description": "ElastiCache redis",
    "Resources": {
        "MyReplicationGroup": {
            "Type": "AWS::ElastiCache::ReplicationGroup",
            "Properties": {
                "AutomaticFailoverEnabled": true,
                "CacheNodeType": {
                    "Ref": "CacheNodeType"
                },
                Cache  "ParameterGroupName": {
                    "Ref": "CacheParameterGroup"
                },
                "CacheSubnetGroupName": {
                    "Ref": "CacheSubnetGroupName"
                },
                "Engine": "redis",
                "EngineVersion": {
                    "Ref": "EngineVersion"
                },
                "NumNodeGroups": {
                    "Ref": "NumShards"
                },
                "ReplicasPerNodeGroup": {
                    "Ref": "NumReplicas"
                },
                "PreferredMaintenanceWindow": "sat:10:00-sat:08:00",
                "SecurityGroupIds": [
                    {
                        "Ref": "SecurityGroup"
                    }
                ],
                "SnapshotRetentionLimit": {
                    "Ref": "SnapshotRetentionLimit"
                },
                "SnapshotWindow": "00:00-03:00"
            },
            "UpdatePolicy": {
                "UseOnlineResharding": true
            }
        }
    }
}

Por padrão, os clusters do Neptune DB não são criptografados. Isso expõe os dados a um possível roubo e acesso não autorizado por invasores.

Exemplo 1: O modelo de exemplo a seguir não permite a criptografia em repouso.

{
    "AWSTemplateFormatVersion": "2010-09-09",
    "Description": "My Neptune DB cluster",
    "Resources": {
        "NeptuneDBCluster": {
            "Type": "AWS::Neptune::DBCluster",
            "Properties": {
                "BackupRetentionPeriod": 10,
                "DBClusterIdentifier": "MyDBClusterIdentifier",
                "DBClusterParameterGroupName": "MyNeptuneDBClusterParameterGroup",
                "DBSubnetGroupName": "MyNeptuneDBSubnetGroup",
                "IamAuthEnabled": true,
                "Port": 8080,
                "PreferredBackupWindow": "NeptuneDBClusterPreferredBackupWindow",
                "PreferredMaintenanceWindow": "NeptuneDBClusterPreferredMaintenanceWindow"
            }
        }
    }
}

Por padrão, as instâncias do Amazon RDS não são criptografadas. Isso expõe os dados a um possível roubo e acesso não autorizado.

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

Por padrão, os clusters do Amazon Redshift não são criptografados. Isso expõe os dados a acesso não autorizado e possível roubo.

Exemplo 1: O modelo a seguir define um cluster Redshift sem criptografia habilitada.

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

Um bucket do Amazon S3 é criado sem criptografia no lado do servidor. A criptografia atenua as violações de dados tornando os dados ilegíveis para qualquer pessoa sem as credenciais adequadas. Como tal, a criptografia em repouso é uma medida para atender a alguns requisitos de conformidade industrial e governamental, como GDPR, HIPAA e PCI.

Por padrão, os tópicos SNS não são criptografados em repouso. Isso expõe, possivelmente, os dados a visualizadores não autorizados.

Exemplo 1: O modelo de exemplo a seguir falha ao criptografar o tópico SNS ao negligenciar a definição de um identificador de chave AWS KMS.

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

A autenticação baseada em ID de toque pode ser implementada usando os serviços de conjunto de chaves armazenando um item no conjunto de chaves e definindo um controle de acesso que requer que o usuário use sua impressão digital para recuperar o item posteriormente. As seguintes políticas podem ser usadas para definir como o usuário será autenticado usando sua impressão digital:

- kSecAccessControlUserPresence: Restrição para acessar usando a ID de toque ou a senha. A ID de toque não precisa estar disponível ou registrada. O item ainda estará acessível pela ID de toque, mesmo se as impressões digitais forem adicionadas ou removidas.
- kSecAccessControlTouchIDAny: Restrição para acessar usando a ID de toque para quaisquer impressões digitais registradas. O item não será invalidado se as impressões digitais forem adicionadas ou removidas.
- kSecAccessControlTouchIDCurrentSet: Restrição para acessar usando a ID de toque para as impressões digitais registradas no momento. O item será invalidado se as impressões digitais forem adicionadas ou removidas.

Ao usar a ID de toque, você deve usar o atributo kSecAccessControlTouchIDCurrentSet para proteger contra a adição ou remoção de impressões digitais no futuro.

Exemplo 1: O seguinte código usa a restrição kSecAccessControlTouchIDAny que permite que todas as impressões digitais cadastradas no futuro desbloqueiem o item de conjunto de chaves:

    ...
    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);
    });
    ...

É prática comum processar a saída dos valores de variáveis para fins depuração ou teste com um código que não se destina a ser distribuído ou permanecer ativo no aplicativo implantado. Quando esse tipo de código de depuração é acidentalmente deixado no aplicativo, este pode fornecer informações para um invasor de maneiras inesperadas. Nem todas as instruções de depuração deixam vazar informações confidenciais ou privadas. No entanto, a presença de uma instrução de depuração muitas vezes indica que o código circundante foi negligenciado e pode estar em mau estado de conservação.

O exemplo mais comum de código de depuração esquecido no ColdFusion é a tag <cfdump>. Embora o uso de <cfdump> seja aceitável durante o desenvolvimento do produto, os desenvolvedores responsáveis pelo código que faz parte de um aplicativo Web de produção deve considerar cuidadosamente se qualquer uso da tag <cfdump> deve ser permitido.