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>
...

Os valores de atributos para componentes do Oracle ADF Faces podem ser definidos normalmente apenas no servidor. No entanto, vários componentes permitem que o desenvolvedor defina uma lista de atributos que podem ser definidos no cliente. O atributo unsecure desses componentes pode especificar uma lista como essa.

Atualmente, o único atributo que pode aparecer dentro do atributo unsecure é disabled e permite que o cliente defina quais componentes estão habilitados e quais não estão. Nunca é uma boa ideia deixar que o cliente controle os valores de atributos que só devem ser configuráveis no servidor.

Exemplo 1: O código a seguir demonstra um componente inputText que coleta informações de senha do usuário e usa o atributo unsecure.

...
    <af:inputText id="pwdBox"
                  label="#{resources.PWD}"
                  value=""#{userBean.password}
                  unsecure="disabled"
                  secret="true"
                  required="true"/>
...

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.

Os cookies são estritamente um mecanismo HTTP, de acordo com a RFC 2109. Não deve haver expectativa razoável de que eles trabalhem para protocolos que não sejam HTTP, incluindo file://. Não está claro qual deve ser seu comportamento e quais regras de compartimentalização de segurança devem ser aplicadas. Por exemplo, os arquivos HTML baixados para o disco local da Internet compartilham os mesmos cookies que qualquer código HTML instalado localmente?

O middleware ASP.NET Core que não é adicionado ao pipeline de middleware na ordem correta não funcionará conforme o esperado, deixando um aplicativo aberto a vários problemas de segurança.

Exemplo 1: O método UseCookiePolicy() adiciona o middleware de política de cookie ao pipeline de middleware, permitindo políticas de cookie personalizadas. Quando especificado na ordem errada, como mostrado, qualquer política de cookie indicada pelo programador será ignorada.

...
var builder = WebApplication.CreateBuilder(...);
var app = builder.Build(...);
app.UseStaticFiles();
app.UseRouting();
app.UseSession();
app.UseAuthentication();
app.UseAuthorization();
app.UseEndpoints(endpoints =>
{
    ...
}

app.UseCookiePolicy();
...

O middleware ASP.NET Core que não é adicionado ao pipeline de middleware na ordem correta não funcionará conforme o esperado, deixando um aplicativo aberto a vários problemas de segurança.

Exemplo 1: O método UseHttpsRedirection() adiciona o middleware de redirecionamento HTTPS ao pipeline de middleware, que permite o redirecionamento de solicitações HTTP não seguras para uma solicitação HTTPS segura. Quando especificado na ordem errada, conforme mostrado, nenhum redirecionamento HTTPS significativo ocorrerá antes de processar a solicitação por meio do middleware listado antes do redirecionamento. Isso permitirá que as solicitações HTTP sejam processadas pelo aplicativo antes de serem redirecionadas para a conexão HTTPS segura.

...
var builder = WebApplication.CreateBuilder(...);
var app = builder.Build(...);
app.UseStaticFiles();
app.UseRouting();
app.UseSession();
app.UseAuthentication();
app.UseAuthorization();
app.UseEndpoints(endpoints =>
{
    ...
}

app.UseHttpsRedirection();
...

O middleware ASP.NET Core que não é adicionado ao pipeline de middleware na ordem correta não funcionará conforme o esperado, deixando um aplicativo aberto a vários problemas de segurança.

Exemplo 1: O método UseHttpLogging() adiciona middleware de registro em log HTTP ao pipeline de middleware que permite que os componentes de middleware sejam registrados em log. Quando especificado na ordem errada, conforme mostrado, nenhum middleware adicionado ao pipeline antes da chamada para UseHttpLogging() será registrado em log.

...
var builder = WebApplication.CreateBuilder(...);
var app = builder.Build(...);
app.UseStaticFiles();
app.UseRouting();
app.UseSession();
app.UseAuthentication();
app.UseAuthorization();
app.UseEndpoints(endpoints =>
{
    ...
}

app.UseHttpLogging();
...

Exemplo 2: O método UseWC3Logging() adiciona o middleware de registro em log do W3C ao pipeline de middleware que permite que os componentes de middleware sejam registrados em log. Quando especificado na ordem errada, conforme mostrado, nenhum middleware adicionado ao pipeline antes da chamada para UseWC3Logging() será registrado em log.

...
var builder = WebApplication.CreateBuilder(...);
var app = builder.Build(...);
app.UseStaticFiles();
app.UseRouting();
app.UseSession();
app.UseAuthentication();
app.UseAuthorization();
app.UseEndpoints(endpoints =>
{
    ...
}

app.UseWC3Logging();
...

As ações do controlador ASP.NET MVC que modificam dados gravando, atualizando ou excluindo podem se beneficiar da restrição de aceitar um dos seguintes verbos HTTP: Post, Put, Patch ou Delete. Isso aumenta a dificuldade de falsificação de solicitação entre sites, pois o clique acidental de links não fará com que a ação seja executada.

A ação de controlador a seguir aceita qualquer verbo por padrão e pode ser suscetível a falsificação de solicitações entre sites:

public ActionResult UpdateWidget(Model model)
{
  // ... controller logic
}

Usar uma classe de modelo que possui propriedades obrigatórias (marcadas com o atributo [Required]) e propriedades opcionais (não marcadas com o atributo [Required]) pode provocar problemas quando um invasor comunica uma solicitação que contém mais dados que o esperado.

A estrutura MVC ASP.NET tentará associar parâmetros de solicitação a propriedades de modelo.

O fato de haver níveis combinados de exigência sem a comunicação explícita de quais parâmetros devem ser associados a modelos pode indicar que existem propriedades de modelo para uso interno, mas que essas propriedades podem ser controladas por um invasor.

O código a seguir define uma possível classe de modelo que tem propriedades com [Required] e propriedades sem [Required]:

public class MyModel
{
    [Required]
    public String UserName { get; set; }

    [Required]
    public String Password { get; set; }

    public Boolean IsAdmin { get; set; }
}

Se qualquer parâmetro opcional puder alterar o comportamento de um aplicativo, talvez um invasor seja capaz de realmente mudar esse comportamento comunicando um parâmetro opcional em uma solicitação.

Usar uma classe de modelo que possui propriedades obrigatórias não anuláveis (marcadas com o atributo [Required]) pode provocar problemas quando um invasor comunica uma solicitação que contém menos dados do que o esperado.

A estrutura MVC ASP.NET tentará associar parâmetros de solicitação a propriedades de modelo.

Se um modelo tiver um parâmetro obrigatório não anulável e um invasor não comunicar esse parâmetro em uma solicitação -- ou seja, se o invasor usar um ataque under-posting --, a propriedade terá o valor padrão (geralmente zero), que atenderá ao atributo de validação [Required]. Isso pode provocar o comportamento inesperado do aplicativo.

O código a seguir define uma classe de modelo possível que possui uma enumeração obrigatória não anulável:

public enum ArgumentOptions
{
    OptionA = 1,
    OptionB = 2
}

public class Model
{
    [Required]
    public String Argument { get; set; }

    [Required]
    public ArgumentOptions Rounding { get; set; }
}

Se uma classe de modelo tiver a propriedade obrigatória e for do tipo de um membro opcional de uma classe de modelo pai, ela poderá ser suscetível a ataques under-posting se um invasor comunicar uma solicitação contendo menos dados que o esperado.

A estrutura MVC ASP.NET tentará associar parâmetros de solicitação a propriedades de modelo, incluindo submodelos.

Se um submodelo for opcional -- ou seja, se o modelo pai tiver uma propriedade sem o atributo [Required] -- e se um invasor não comunicar esse submodelo, então a propriedade pai terá um valor null, e os campos obrigatórios do modelo filho não serão confirmados pela validação de modelo. Essa é uma das formas de ataque under-posting.

Considere as seguintes definições de classe de modelo:

public class ChildModel
{
    public ChildModel()
    {
    }

    [Required]
    public String RequiredProperty { get; set; }
}

public class ParentModel
{
    public ParentModel()
    {
    }

    public ChildModel Child { get; set; }
}

Se um invasor não comunicar um valor para a propriedade ParentModel.Child, a propriedade ChildModel.RequiredProperty terá um [Required] não confirmado. Isso pode produzir resultados inesperados e indesejáveis.

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"
        }
    }