O acesso descontrolado a recursos críticos ou confidenciais pode afetar significativamente uma organização de várias maneiras, incluindo a divulgação ou adulteração de dados críticos.

O acesso descontrolado a recursos críticos ou confidenciais pode afetar significativamente uma organização de várias maneiras, incluindo a divulgação ou adulteração de dados críticos.

Configurações de acesso livre podem expor sistemas e ampliar a superfície de ataque de uma organização. Os serviços abertos à interação com o público são normalmente submetidos a varreduras e investigações quase contínuas por entidades mal-intencionadas.

Isso é especialmente problemático quando uma exploração de dia zero para um serviço exposto é descoberta e publicada, como Heartbleed. Os invasores podem perseguir e pesquisar ativamente sistemas não corrigidos e expostos para explorá-los.

O acesso descontrolado a recursos críticos ou confidenciais pode afetar significativamente uma organização de várias maneiras, incluindo a divulgação ou adulteração de dados críticos.

O acesso descontrolado a recursos críticos ou confidenciais pode afetar significativamente uma organização de várias maneiras, incluindo a divulgação ou adulteração de dados críticos.

O acesso descontrolado a recursos críticos ou confidenciais pode afetar significativamente uma organização de várias maneiras, incluindo a divulgação ou adulteração de dados críticos.

Canais de comunicação de dados protegidos de forma insuficiente podem colocar dados organizacionais críticos em risco de roubo, adulteração ou divulgação.

Codificar uma senha permite que todos os desenvolvedores do projeto exibam a senha. Também dificulta a correção do problema. Depois que o código estiver em produção, ninguém poderá alterar a senha sem aplicar um patch no software. Se a conta protegida pela senha for comprometida, os proprietários do sistema deverão escolher entre segurança e disponibilidade.

O Mule Database Connector deve forçar o transporte criptografado e verificar os certificados do servidor de banco de dados. Se as propriedades de conexão de banco de dados relevantes não forem especificadas ou forem configuradas incorretamente, as conexões resultantes exporão os dados a possível acesso não autorizado, adulteração e roubo.

O HTTPS usa TLS (Transport Layer Security) para criptografar solicitações e respostas HTTP regulares. Garante a integridade e a confidencialidade de qualquer troca de dados.

Um HTTP Listener Connector não criptografará sua comunicação se seu protocolo não for especificado ou estiver definido como HTTP. Isso expõe os dados a acesso não autorizado, adulteração e possível roubo.

Exemplo 1: A configuração do Mule a seguir define o protocol de um HTTP Listener Connector (listener-connection) como HTTP. Como resultado, as conexões ao HTTP Listener são inseguras.

    <http:listener-config name="http_listener_config">
        <http:listener-connection host="example.com" port="8080" protocol="HTTP">
...
        </http:listener-connection>
    </http:listener-config>

A verificação da certificação é essencial para confirmar a identidade da contraparte para uma comunicação segura. Um elemento tls:context define um conjunto de configurações de conexão TLS. Entre as configurações, o elemento tls:trust-store especifica um arquivo que contém certificados de Autoridades de Certificação confiáveis que um cliente usa para verificar um certificado apresentado por um servidor. Por padrão, o mecanismo de tempo de execução do Mule verifica o certificado do servidor para cada conexão TLS.

No entanto, se o valor do atributo insecure do elemento tls:trust-store for true, os certificados do servidor serão aceitos sem verificação.

Exemplo 1: A configuração do Mule a seguir define o atributo insecure como true. Como resultado, o mecanismo de tempo de execução do Mule não verifica o certificado do servidor de nenhuma conexão com o contexto de TLS chamado demoTlsContext. Essa conexão é vulnerável a um ataque man-in-the-middle.

...
<tls:context name="demoTlsContext">
...
    <tls:trust-store ... insecure="true" ... />
...
<tls:context/>
...

Foi detectada uma operação da API que permite que as credenciais trafeguem por um canal não criptografado. Os requisitos de security do OpenAPI e as definições servers de destino para uma operação da API sempre substituirá as respectivas configurações globais.

No entanto, quando essas configurações não são definidas para uma operação, elas assumem como padrão os valores especificados globalmente.

Os requisitos de segurança globais informam os consumidores da API sobre os parâmetros de autenticação e autorização necessários para interagir com sucesso com a API.

Uma definição security global vazia pode permitir que invasores interajam com endpoints de API confidenciais e executem operações que devem ser restritas a contas de usuário específicas com privilégios específicos.

Exemplo 1: A especificação do OpenAPI a seguir declara uma definição security global vazia. As APIs que implementam essa especificação podem ser vulneráveis a acesso não autorizado ou não autenticado às operações confidenciais.

{
    "openapi" : "3.0.3",
    "info" : {
        "title" : "My API",
        "version" : "1.0.0"
    },
    "servers" : [ {
        "url" : "/"
    } ],
    "security" : [],
    ...
}

As operações da API definem os requisitos de segurança para informar os consumidores da API sobre os parâmetros de autenticação e autorização necessários para invocá-los com sucesso.

As operações que incluem uma definição security vazia podem permitir que invasores interajam com endpoints de API confidenciais e executem ações que devem ser restritas a contas de usuário específicas com privilégios explícitos.

Exemplo 1: A especificação do OpenAPI a seguir configura uma definição security vazia para uma operação confidencial. Isso substitui os requisitos de segurança definidos globalmente e torna a operação createUsers vulnerável a acesso não autorizado e não autenticado.

{
    "openapi": "3.0.0",
    "info": {
     ...
    },    
    "paths": {
      "/users": {
        "post": {
          "security": [],
          "summary": "Create a user",
          "operationId": "createUsers",
         ...
        }
    ...
    }
}

Canais de comunicação não criptografados estão propensos a serem interceptados e adulterados. O atendimento de solicitações de clientes em um canal de comunicação inseguro permite que os invasores executem ataques man-in-the-middle e lhes dá acesso para ler ou modificar os dados em trânsito.

Sempre configure as APIs para usar respostas de erro personalizadas em vez de confiar nas respostas padrão da estrutura subjacente. As respostas padrão podem fornecer informações detalhadas sobre o erro ocorrido e vazar inadvertidamente informações confidenciais.

Os invasores podem aproveitar as informações adicionais fornecidas por uma resposta de erro padrão para montar ataques direcionados à estrutura, ao banco de dados ou a outros recursos usados pela API.

Os requisitos de segurança globais informam os consumidores da API sobre os parâmetros de autenticação e autorização necessários para interagir com sucesso com a API.

Uma definição security global ausente pode permitir que invasores interajam com endpoints de API confidenciais e executem operações que devem ser restritas a contas de usuário específicas com privilégios específicos.

Exemplo 1: A especificação do OpenAPI a seguir deixa de declarar uma definição security global. As APIs que implementam essa especificação podem ser vulneráveis a acesso não autorizado ou não autenticado às operações confidenciais.

{
    "openapi" : "3.0.3",
    "info" : {
        "title" : "My API",
        "version" : "1.0.0"
    },
    "servers" : [ {
        "url" : "https://example.org"
    } ],    
    ...
}

As operações da API definem os requisitos de segurança para informar os consumidores da API sobre os parâmetros de autenticação e autorização necessários para invocá-los com sucesso.

As operações que não incluem uma definição security vazia podem permitir que invasores interajam com endpoints de API confidenciais e executem ações que devem ser restritas a contas de usuário específicas com privilégios explícitos.

Exemplo 1: A especificação do OpenAPI a seguir falha ao definir uma definição security para uma operação confidencial. Além disso, sem uma definição security global, a operação createUsers é vulnerável ao acesso não autorizado e não autenticado.

{
    "openapi": "3.0.0",
    "info": {
     ...
    },    
    "paths": {
      "/users": {
        "post": {
          "summary": "Create a user",
          "operationId": "createUsers",
         ...
        }
    ...
    }
}

A definição securitySchemes especifica os mecanismos de segurança que podem ser usados globalmente ou por operações da API específicas.

A definição securitySchemes é normalmente especificada no objeto components reutilizável e é referenciada globalmente ou por operações específicas para ditar os requisitos de segurança para interação.

Exemplo 1: A especificação do OpenAPI a seguir falha ao definir a definição securitySchemes.

{
    "openapi" : "3.0.3",
    "info" : {
        "title" : "My API",
        "version" : "1.0.0"
    },   
    "components": {
        "schemas": {
        "GeneralError": {
            "type": "object",
            "properties": {            
            ...
            }
        }
}

Os requisitos de segurança globais informam os consumidores da API sobre os parâmetros de autenticação e autorização necessários para interagir com sucesso com a API.

As entradas de requisitos de segurança opcionais definidas na definição security global podem permitir que invasores interajam com endpoints de API confidenciais e executem operações que devem ser restritas a contas de usuário específicas com privilégios específicos.

Exemplo 1: A especificação do OpenAPI a seguir declara uma definição security global com segurança opcional por meio do item {} vazio. As APIs que implementam essa especificação podem ser vulneráveis a acesso não autorizado ou não autenticado às operações confidenciais.

{
    "openapi" : "3.0.3",
    "info" : {
        "title" : "My API",
        "version" : "1.0.0"
    },
    "servers" : [ {
        "url" : "/"
    } ],
     "security" : [ {}, { "oauth_auth" : ["write","read" ]} ],
    ...
}