Boas práticas em Cyber Security para aplicações Web

Autores: Luiz Casagrande e Luan Uchoa

Ataques cibernéticos sempre foram o pesadelo de grande parte da sociedade, e com o aumento da digitalização dos meios de trabalho remoto, advindos da pandemia de COVID-19, o número de ataques cresce em curva exponencial. Isso provoca grandes prejuízos financeiros e à imagem dos que sofreram ou sofrem estes ataques. Baseado nos 10 principais tipos de ataques cibernéticos dos últimos anos e pensando nos próximos anos, a entidade internacional OWASP elaborou alguns guias e materiais para conscientização da comunidade quanto aos riscos e oferecendo sugestões de como mitigar tais falhas, aliado ao desenvolvimento seguro de aplicações desde o princípio, termo popularmente conhecido como Security By Design. Para contribuir com a comunidade, baseando-se nos guias de boas práticas providos pela OWASP, e outras entidades mencionadas abaixo, elaboramos este artigo com as cinco principais falhas que afligem os sistemas web atuais.

OWASP Top 1 – Broken Access Control (Quebra do Controle de Acesso)

IDOR, Insecure Direct Object Reference (Referências Inseguras Diretas ao Objeto) 

A referência direta a objetos é um método de design em aplicações web em que nomes de entidades são passados via URLs ou parâmetros da requisição. Eles são então usados para identificar e acessar recursos controlados pela aplicação. 

  A vulnerabilidade de referência insegura direta a objetos (deste ponto em diante, IDOR) permite que um invasor obtenha dados de outros usuários ao substituir o valor da entidade por um diferente do original. Por exemplo, uma vulnerabilidade IDOR ocorre se a URL de uma transação pode ser alterada pelo lado do cliente para mostrar dados restritos da transação de outro cliente. Para que seja explorada, ela deve ser combinada com uma falha de controle de acesso, pois é esta que permite que o atacante acesse outros objetos além dos pretendidos.

Uma aplicação web está especialmente vulnerável a IDOR quando:

• Uma referência direta (tal como o ID de uma entrada do banco de dados, ou um nome de arquivo) é exposta aos usuários como parte do parâmetro da URL;
• A aplicação falha em verificar se o usuário está autorizado a acessar o objeto requisitado pela referência na URL.

Geralmente, ataques envolvendo IDOR acontecem com (i) a manipulação do corpo da página, em que invasores alteram valores de checkboxes, radio buttons e campos dos formulários, o que lhes permitirá acessar dados de outros usuários; ou (ii) a manipulação da URL, sendo esta alterada pelo lado do cliente para ajustar os parâmetros da requisição, em que as requisições GET e POST são tipicamente vulneráveis a esse tipo de ataque.

Exemplos de vulnerabilidades

1. Recuperação indevida de registros 

Considere um website que utilize a URL abaixo para acessar a página do usuário contendo informações pessoais, recuperando informações de uma base de dados no servidor [Acunetix , 2020]:

example.com/profile.php?id=132355

O invasor pode tentar substituir o parâmetro id por outros valores similares, digamos:

example.com/profile.php?id=73682

O ID do cliente é usado diretamente para consultas executadas na base de dados do servidor. Se não houver outros controles implementados, o invasor pode simplesmente modificar o campo de ID, ignorando controles de acesso relacionados à visualização de dados de outros clientes. O invasor pode executar escalonamento horizontal e vertical ao alterar para o ID de um usuário que possua privilégios adicionais. 

Quando uma aplicação web expõe uma referência a um objeto interno da implementação, é possível inferir o formato/padrão usado para armazenar os objetos do lado do servidor. Assim, uma vulnerabilidade de IDOR pode fornecer ao invasor a capacidade de executar um ataque de enumeração para tentar acesso aos objetos associados. Considerando o exemplo acima, o invasor poderia construir uma coleção de IDs abrangendo entre 1 e 999999 para disparar um ataque paralelo com a intenção de obter esses dados [Acunetix , 2020].

2. Execução de operação no sistema

Vulnerabilidades IDOR podem acontecer em formulários de mudança de senha. Um formulário mal projetado pode ter a URL da seguinte forma [Acunetix , 2020]:

example.com/change_password.php?userid=1701

Essa URL pode ser enviada via e-mail ao fornecer um endereço de e-mail usando outro formulário. Se não houver verificações adicionais, o invasor poderia tentar a URL acima com userid=1, e assim provavelmente teria acesso a uma conta de administrador. 

3. Recuperação de recursos do servidor

Vulnerabilidades IDOR também podem envolver nomes de arquivo. Uma das variantes mais típicas de IDOR envolve caminhar pelos diretórios. Neste caso, o usuário pode visualizar arquivos não autorizados. Digamos que um website armazene em disco o registro de mensagens entre dois usuários com nomes de arquivos incrementais, e que permita acesso através da seguinte URL [Acunetix , 2020]:

example.com/static/12144.txt

Nesta situação, é possível modificar o nome do arquivo para recuperar os registros de outro usuário.

Outra possibilidade seria através de uma página web construída para prover acesso a um recurso do sistema:

example.com/display.php?file.txt

Se houver uma vulnerabilidade associada ao display.php, é possível obter acesso a arquivos do sistema, como o /etc/passwd:

example.com/display.php?../../../etc/passwd

Prevenção contra IDOR

Algumas fontes recomendam a prevenção usando identificadores longos e difíceis de adivinhar (como os usados para IDs de sessão). Outra solução proposta é usar referências indiretas com IDs externos difíceis de mapear. No entanto, note que esses métodos podem dar uma falsa sensação de segurança porque tornam o ataque mais difícil, mas não impossível. O único meio real de se proteger contra IDOR é implementar controles estritos de acesso. A maioria dos frameworks web modernos (Rails, Django, etc) não possuem problemas com IDOR, exceto se o desenvolvedor decidir usar seus próprios métodos no lugar dos fornecidos. Controle de acesso é eficaz somente em código confiável do lado do servidor ou em API serverless, onde o invasor não pode modificar os metadados ou as verificações de acesso.

1. Verificar as permissões de usuário no nível do objeto de dados

Este mecanismo resolve o problema primário causador da vulnerabilidade: verificação de acesso ausente ou insuficiente. Não se deve confiar somente nas validações do lado do cliente, pois elas podem facilmente ser contornadas. 

Ao implementar controles de acesso do lado do servidor, é relativamente óbvio adicionar verificações de autorização no nível de funcionalidade ou de rota. Um problema comum que causa essa vulnerabilidade são verificações de acesso ausentes para proteger contra IDs manipulados em URLs. É necessário aplicar controles de acesso aos dados verificando se o usuário requisitante é proprietário ou tem permissões para acessar os dados solicitados.

A aplicação deve também executar validação sintática para verificar entradas suspeitas – estabelecer critérios para os dados de entrada e rejeitá-los se os critérios não são atendidos. Exemplos: tamanho mínimo ou máximo, intervalo (para valores numéricos), tipos de dados, caracteres aceitáveis, etc. [Oreilly, 2022].

2. Evite expor referências diretas aos objetos

No lugar de solicitar as referências na URL, use a informação já presente na sessão do usuário do lado do servidor para localizar os recursos a prover. No exemplo do perfil 132355, se os usuários são permitidos a ver apenas os próprios perfis, podemos utilizar o ID de sessão do usuário conectado para o localizar, eliminando assim a necessidade de passar o ID como parâmetro [Oreilly, 2022].

3. Usar mapeamento de referências indiretas

Se não é possível evitar a exposição das referências na URL, a técnica do mapeamento de referências indiretas é útil. A ideia por trás desse método é substituir a referência direta na URL por um valor aleatório que seja difícil de prever (tal como um GUID) ou específico apenas para o usuário conectado.

O mapeamento de referências indiretas armazena as relações entre a referência interna de um objeto e a referência indireta correspondente que é exibida na URL. Voltando ao exemplo do perfil: ao invés de usar uma referência direta, como example.com/profile.php?id=132355, pode ser usada uma referência indireta como example.com/p/kjbEEc24jkLUvAKJhv0p. Esse mapeamento deve ser mantido em um local seguro no servidor [Oreilly, 2022].

4. Protegendo contra travessia de diretório

Para se prevenir contra esse ataque, é necessário tomar providências no nível de configuração do sistema e também no nível de aplicação [Oreilly, 2022]:

• No nível de sistema, configure o diretório raiz e a lista de controle de acesso para confinar o acesso do usuário e restringir acesso a arquivos fora da raiz da página web;
• No código, faça validação de entrada do usuário para prevenir caracteres correspondentes à travessia de diretório. 

OWASP Top 2 – Cryptographic Failures (Falhas de criptografia)

Para o pleno funcionamento de comunicações seguras através da internet é necessário que as aplicações possuam criptografia.  Para que não haja comprometimento em dinâmicas envolvendo privacidade ou sigilo de dados, são utilizados algoritmos de criptografia e algumas funções utilizam bibliotecas de criptografia. Hoje existem muitas bibliotecas de criptografia e também muitos algoritmos, contudo, muitos deles ainda podem apresentar falhas e podem possuir vulnerabilidades, sendo assim uma porta de entrada para exploração de invasores. 

Possíveis vulnerabilidades

É necessário se atentar com algumas situações:

• Não transmitir dados em texto claro, e preferencialmente não utilizar para transmitir dados sensíveis os protocolos inseguros como FTP, HTTP, SMTP e algumas atualizações do TLS, como no caso do STARTTLS. No tráfego interno verificar os sistemas de back-end e servidores web [OWASP A02, 2021];
• Substituir algoritmos ou protocolos de criptografia antigos por algoritmos ou protocolos mais modernos e seguros [OWASP A02, 2021];
• Não utilizar chaves de criptografia padrão e nem reutilizar chaves expiradas, verificar no código fonte se há alguma chave em comentário, em caso positivo remover o mais breve possível [OWASP A02, 2021];
• Não utilizar preenchimento criptográfico descontinuado como PKCS 1 v1.5, nem funções de hash descontinuadas como MD5 ou SHA1 [OWASP A02, 2021];
• Verificar e corrigir mensagens de erro de criptografia que possibilitem exploração por um invasor [OWASP A02, 2021];
• Assegurar que os dados sensíveis estão devidamente criptografados, não coletar dados desnecessários [OWASP A02, 2021];
• Utilização de algoritmos e protocolos atualizados com melhor criptografia, utilizar funções de hash com salt, as quais são fortemente adaptativas como PBKDF2, Argon2, bcrypt ou scrypt [OWASP A02, 2021];
• Criptografar com protocolos seguros, como TLS com FS, os dados que forem transportados, reforçar criptografia com por exemplo HSTS (HTTP Strict Transport Security) [OWASP A02, 2021];
• Chaves devem ser geradas criptografadas aleatoriamente e armazenadas na memória como bytes aleatórios, para o uso de senhas, essas devem ser convertidas para uma chave através de uma função específica [OWASP A02, 2021];
• Vetores de inicialização devem ser escolhidos apropriadamente conforme seu uso, podendo utilizar o CSPRNG (Cryptographically Secure Pseudo Random Number Generator – gerador de números pseudo aleatórios criptograficamente seguros) [OWASP A02, 2021].

Grandes falhas que ocasionaram grandes prejuízos 

Alguns exemplos de falhas que trouxeram problemas para grandes servidores e empresas:

Configurações padrões inseguras ou com falhas – quebra de conexão TLS via SSLv2.
A falha ocorre quando o servidor ainda permite conexão via SSLv2. Enquanto a maioria dos servidores podem estar atualizados para utilizar apenas TLS, alguns ainda permitem conexão via SSLv2. Um invasor pode explorar essa falha tentando se conectar via SSLv2, caso tenha sucesso, será possível quebrar a segurança provida pelo TLS e interceptar as chaves de segurança e demais informações sensíveis. De modo a prevenir este tipo de falha é necessário verificar sempre se o tipo de conexão é exclusivamente via TLS [FreeCodeCamp, 2017].
Falha está registrada em DROWN: Breaking TLS using SSLv2. 

Heartbleed – Falha em biblioteca de criptografia.
Esta falha se deve a uma implementação incorreta da extensão TLS heartbeat no OpenSSL. Esta extensão foi desenvolvida para manter ativa a conexão entre dois dispositivos finais, para isso um dispositivo final envia um payload de dados arbitrários e é esperado que o outro dispositivo envie a cópia exata desses dados para provar que a comunicação entre eles está ativa.
A falha ocorre devido à falta de verificação antes de enviar o pacote, com isso é possível que o invasor falsifique o tamanho do pacote, por exemplo declarando que o pacote tem tamanho 65535 bytes quando na realidade só será enviado 1 byte. Dessa forma, a vítima irá enviar um pacote contendo 65535 bytes de dados, podendo conter senha, cookie/chave de sessão, login, e outras informações secretas que possam estar armazenadas na memória do browser [Heartbleed, 2020] [FreeCodeCamp, 2017].
Falha está registrada como CVE – CVE-2014-0160 (mitre.org) . 

Apple’s “goto” – Falha no sistema operacional e aplicativos.
Esta falha se deve a um erro no código, especificamente a linha 12 que traz o método “goto”, isso fazia com que as linhas de código 13 a 16 não tivessem efeito. Esse método burlava todas as verificações de certificado de conexão SSL/TLS em dispositivos Mac e iOS. Assim é possível efetuar um ataque de tipo “Man in the Middle”, dado que será possível aceitar qualquer certificado, mesmo que inválido [FreeCodeCamp, 2017].
Falha está registrada como CVE – CVE-2014-1266 (mitre.org) . 

Owasp Top 3 – Injection (Injeções de códigos)

Injeção, no contexto de cyber security, é a exploração de uma falha computacional causada pelo processamento de dados inválidos. Essa falha é então utilizada por um invasor para introduzir (ou “injetar”) dados em um programa vulnerável e alterar o seu curso de execução. As consequências de uma injeção bem-sucedida podem ser desastrosas, como perda de dados, criação de um ambiente que possibilite a propagação de código malicioso como malwares, ou mesmo total inutilização do sistema. Os efeitos desses ataques incluem: 

• Permitir que um atacante execute chamadas do sistema operacional em uma máquina alvo; 
• Permitir que um atacante comprometa bases de dados;
• Permitir que um atacante comprometa ou ganhe controle sobre sessões de outros usuários; 
• Permitir que um atacante force ações em nome de outros usuários ou serviços. 

Possíveis vulnerabilidades que devemos verificar 

Algumas das injeções mais comuns são de SQL, NoSQL, comandos do SO, Mapeamento Objeto-Relacional (ORM), LDAP, e linguagem de expressão (EL) ou biblioteca de navegação em objetos grafos (OGNL).  O conceito é idêntico para todos os interpretadores.  

A aplicação é vulnerável a falhas de injeções de código quando [OWASP A03, 2021]:

• Dados fornecidos pelo usuário não são propriamente validados, filtrados ou sanitizados pela aplicação;
• Consultas dinâmicas ou chamadas não parametrizadas sem escape adequado de caracteres são executados diretamente no interpretador;
• Dados hostis são usados como parâmetros de busca para extrair registros adicionais e restritos;
• Dados hostis são diretamente usados ou concatenados na aplicação. O comando ou consulta carrega a estrutura de dados maliciosos em consultas dinâmicas, comandos, ou procedimentos armazenados. 

Injeções de Código

Injeção de código é o termo geral para ataques que consistem em injetar código que posteriormente é interpretado/executado pela aplicação. Este tipo de ataque explora o manuseio inadequado de dados não confiáveis. Estes tipos de ataques geralmente são possíveis devido à falta de validação adequada dos dados de entrada ou saída, como por exemplo [OWASP Code Injection, 2021]: 

• Caracteres permitidos (expressões regulares padrão ou customizadas);
• Formato dos dados;
• Quantidade de dados esperados.

Na injeção de código o atacante é limitado pela funcionalidade disponível na linguagem injetada. Por exemplo, se um atacante pode injetar código PHP em uma aplicação para ser executado, ele é limitado pelas capacidades do PHP. 

Execução de Código Remoto

Execução de código remoto é o termo para ataques em que o objetivo é a execução de comandos arbitrários no sistema operacional hospedeiro através de uma aplicação vulnerável. Estes ataques são possíveis quando uma aplicação repassa dados de entrada não sanitizados (formulários, cookies, cabeçalhos HTTP, etc.) para um terminal (shell) do sistema. Neste ataque, os comandos do sistema fornecidos pelo atacante são geralmente executados com as permissões da aplicação vulnerável. Estes ataques são possíveis, geralmente, por causa da validação insuficiente das entradas de dados. 

Na execução remota de códigos o atacante estende a funcionalidade padrão da aplicação, que executa comandos do sistema, sem a necessidade de injetar código. A limitação do atacante nesse cenário é dependente do SO hospedeiro (comandos disponíveis no SO) e das permissões de que a aplicação dispõe para executar comandos  [OWASP Command Injection, 2021].

Injeções de SQL

Injeção de SQL é o termo para ataques que consistem em inserir uma consulta SQL através da entrada de dados do cliente para a aplicação. Um ataque bem-sucedido pode ler dados restritos da base de dados, modificar a base de dados (inserir/modificar/apagar), executar operações administrativas na base de dados, recuperar o conteúdo de arquivos que estejam presentes no sistema de arquivos do SGBD e, em alguns casos, enviar comandos para o sistema operacional.  Esses ataques são particularmente comuns com aplicações em PHP e/ou ASP por conta da existência de interfaces funcionais antigas [OWASP SQL Injection, 2021]. 

Existe também o ataque cego de injeção SQL (Blind SQL), onde o atacante faz perguntas de verdadeiro/falso e determina a resposta com base no retorno da aplicação. Este ataque é geralmente usado quando a aplicação web está configurada para exibir mensagens genéricas de erro, mas não teve mitigado o código vulnerável à injeção SQL. Isso faz com que a exploração dessa falha seja mais difícil, porém não impossível. A diferença deste ataque para a injeção de SQL normal, é o método pelo qual os dados são obtidos [OWASP Blind SQL Injection, 2021].

Cross-Site Scripting (XSS)

Um tipo de injeção onde scripts maliciosos são injetados em sites benignos e confiáveis. Ataques XSS ocorrem quando um invasor utiliza uma aplicação web para enviar código malicioso para um usuário diferente. Falhas que permitem esse tipo de ataque são relativamente comuns e ocorrem em qualquer lugar onde uma aplicação web utilize entrada de dados do usuário para a saída que é gerada, mas sem que haja validação desta entrada. Como o navegador do usuário alvo vai considerar que o script veio de uma fonte confiável, o script malicioso pode acessar cookies e tokens de sessão, registrar entrada do teclado, ou até mesmo executar ações maliciosas em nome das vítimas [OWASP XSS, 2021].

Possíveis vulnerabilidades que devemos verificar 

O melhor método para determinar se as suas aplicações estão vulneráveis a ataques de injeção é com revisão do código fonte, buscando no código todas as chamadas direcionadas para recursos externos: system, exec, fork, Runtime.exec, consultas SQL, interpretadores de XML e JSON, ou a sintaxe específica do seu ambiente para chamar interpretadores. Adicionalmente, certificar que todos os dados fornecidos por usuários sejam sanitizados e que os dados fornecidos que sejam utilizados na saída sejam adequadamente codificados quando aplicável. 

É fortemente encorajado o teste automatizado de todos os parâmetros, cabeçalhos, URLs, cookies, JSON, SOAP e dados XML. As organizações podem incluir ferramentas de teste de segurança estáticas (SAST), dinâmicas (DAST) e interativas (IAST) no fluxo de CI/CD para identificar falhas introduzidas antes que estas cheguem ao ambiente de produção [OWASP A03, 2021].

Como prevenir possíveis falhas?

Validação de entrada 

A validação de entrada é executada para garantir que apenas dados bem formados entrem no fluxo de trabalho de um sistema de informação, prevenindo dados mal formados de persistirem na base de dados, o que pode ocasionar funcionamento incorreto de vários componentes posteriores na cadeia de processamento. Validação de entrada deve ocorrer tão cedo quanto possível no fluxo de dados, preferivelmente assim que os dados são recebidos da fonte externa. 

Dados de todas as fontes potencialmente não confiáveis devem estar sujeitos à validação, o que inclui não apenas clientes web na internet, mas também fontes de dados de redes de parceiros, fornecedores, vendedores, reguladores, entre outros, já que estes também estão sujeitos a comprometimento e podem começar a enviar dados maliciosos. 

Validação de entrada não deve ser usada como o método primário para prevenção de XSS e injeção SQL, mas reduz significativamente o impacto se implementada de forma adequada [OWASP Injection Flaws, 2021].

Regra do privilégio mínimo 

Outro bom método de proteção contra ataques de injeção é garantir que a aplicação web execute com o privilégio mínimo necessário para executar a própria função. De modo que o servidor web não deve executar como o usuário root ou acessar uma base de dados como o DBADMIN, caso contrário um atacante pode abusar desses privilégios administrativos que foram concedidos. Alguns ambientes J2EE permitem o uso da máquina virtual Java, o que pode prevenir a execução de comandos do sistema  [OWASP Injection Flaws, 2021].

Tratar exceções e códigos de retorno 

Se um comando externo deve ser utilizado, qualquer informação do usuário que esteja sendo inserida no comando deve ser rigorosamente checada. Devem ser implementados mecanismos para lidar com quaisquer erros possíveis, tempo expirado, ou bloqueios. Toda a saída, códigos de retorno e códigos de erro do comando devem ser checados para certificar que o processamento esperado ocorreu de fato. Esta estratégia vai permitir, no mínimo, detectar que algo errado aconteceu. Do contrário, o ataque pode acontecer e passar despercebido [OWASP Injection Flaws, 2021];

Evitar acesso a interpretadores externos 

Outro método para se proteger contra a injeção é evitar o uso de interpretadores externos sempre que possível. Para muitos comandos do terminal e/ou do sistema, existem bibliotecas específicas que executam as mesmas funções. Usar essas bibliotecas não envolve acesso ao terminal do sistema, e por isso evita muitos problemas que surgem do uso dessa classe de comandos [OWASP Injection Flaws, 2021].

Investigue técnicas de mitigação específicas para as tecnologias que a sua aplicação usa 

Tipos diferentes de ataques de injeção requerem estratégias diferentes de mitigação (e.g. XSS contra injeção de templates do lado do servidor). Revise quais tecnologias a sua aplicação usa e busque informação sobre como prevenir ataques que abusem dessas tecnologias [OWASP Injection Flaws, 2021].

OWASP Top 4 – Insecure Design (Design Inseguro)

Há diferenças entre implementação insegura e design inseguro, dado que sua origem e forma de mitigar são diferentes. É possível que aplicações com design seguro apresentem implementações com falhas, e isso pode ocasionar em vulnerabilidades que podem ser exploradas. Não é possível corrigir um design inseguro com implementação 100% correta, dado que os controles de segurança necessários não foram concebidos para proteger contra alguns ataques específicos. É possível considerar que a falta de mapeamento de perfis de risco ao negócio contribua para um design inseguro, não sendo possível mapear corretamente o nível de segurança do sistema ou da aplicação em desenvolvimento. 

A concepção de design seguro pode ser considerada uma metodologia que consiste em realizar testes para avaliar possíveis vulnerabilidades e assegurar que os sistemas/aplicações estejam configurados de modo a prevenir/garantir que ataques conhecidos não aconteçam, e que não haja vulnerabilidades conhecidas. É necessário levantar hipóteses e criar condições para cumprir exatamente como definido os requisitos de segurança mapeados. Um modelo de gestão e inteligência de ameaças se faz preciso, para refinar o projeto e manter os controles de segurança. 

Todo histórico deve ser documentado com as falhas e ameaças identificadas, de modo que seja possível apoiar na identificação das mesmas em projetos futuros, e contribuir com o aprendizado dos colaboradores/desenvolvedores para melhoria na segurança de futuros projetos [OWASP A04, 2021].

Protocolos operacionais inseguros

No campo industrial muitos protocolos de controle não foram desenvolvidos levando em consideração sua segurança na rede, sendo passíveis de ampla gama de ataques, pois diferentemente do setor de TI, não é possível ficar atualizando sempre os equipamentos com patchs de correção atualizados, sendo estes instalados apenas em janelas de manutenção. Alguns protocolos serão apresentados a seguir:

• Modbus: utilizado em vários setores, foi concebido inicialmente na década de 1970 nos primeiros PLCs (controlador lógico programável). Não possui autenticação de comunicação entre endpoints como padrão, dado que o destinatário poderia receber comandos impróprios de fonte inadequada. Podendo citar como exemplo o envio de uma mensagem, a qual necessita apenas do endereço Modbus adequado e da chamada de função no código, não há validação do conteúdo desta mensagem. Versões antigas e baseadas em série tem sua comunicação via transmissão, não existindo possibilidade de limite da função de transmissão em algumas versões. Isso possibilita que um destinatário atue conforme um comando indesejado, um ataque poderia impactar os dispositivos de destinatários indesejados, o que reduz a compreensão da topologia de rede [Cisco Press, 2017].

 

• ICCP (Inter-Control Center Communications Protocol): protocolo muito utilizado no setor de serviços públicos e na comunicação entre concessionárias. Como atua em redes diferentes, oferece grande exposição, o que possibilita maiores riscos de ataques cibernéticos. Desde sua concepção o ICCP foi concebido para operar em redes WAN. Apresenta duas grandes vulnerabilidades em suas versões iniciais, sendo a não exigência de autenticação e ausência de criptografia nas conexões como padrão, permitindo assim ataques conhecidos como Man In the Middle (MITM) [Cisco Press, 2017].

 

• OPC (OLE for Process Control): protocolo aproveitado de domínio de TI, baseado no Microsoft Object Linking and Embedding (OLE). Este protocolo limita sua operação aos níveis superiores e depende de plataformas Windows. Isso provoca uma preocupação, pois a maioria roda em sistemas Windows antigos, o que possibilita série de ataques em vulnerabilidades conhecidas. Outro ponto de atenção é sua dependência do protocolo RPC (Remote Procedure Call), que permite a execução de uma série de ataques e possui vulnerabilidades conhecidas.

Vale mencionar que no setor de indústrias de energia elétrica alguns protocolos são semelhantes aos mencionados anteriormente, são eles MMS (61850-8.1), GOOSE (61850-8.1), SV (61850-9-2). Os protocolos GOOSE e SV não possuem mecanismo que assegure confiabilidade, não garantindo recebimento dos dados. Maiores detalhes sobre estes protocolos [Cisco Press, 2017]:

• MMS (61850-8.1): protocolo semelhante aos protocolos SCADA Modbus e IEC 60870, é um protocolo cliente/servidor que opera na camada de rede 3.
• GOOSE (61850-8.1): protocolo que opera via multicast sobre Ethernet na camada de rede 2, possibilita que Intelligent Electronic Devices (IEDs) compartilhem dados entre subestações e compartimentos para sinais de disparo, medição e intertravamento. 
• SV (61850-9-2): protocolo que opera via multicast sobre Ethernet na camada de rede 2, atua carregando amostras de corrente e tensão no barramento de processo, também podendo ser no barramento da estação. 

Exemplos de cenários de ataque

Recuperação de credenciais utilizando perguntas e respostas: Essa prática era muito comum há alguns anos atrás atualmente, entretanto, é uma prática proibida conforme NIST 800-63b, OWASP ASVS e OWASP Top 10. Perguntas e respostas podem facilmente ser descobertas utilizando técnicas de engenharia social e/ou força bruta e não servem como evidência de identificação, pois muitas pessoas podem utilizar as mesmas respostas. É necessário um tipo de design mais seguro para recuperação de credenciais, como utilização de Biometria, SMS, entre outros [OWASP A04, 2021].

Modificação de promoção: Supondo alguns cupons de desconto de uma rede de lojas, restaurantes, ou demais estabelecimentos comerciais é possível alterar o limite de cupons para número ilimitado, ou o valor, ocasionando em grandes perdas financeiras. Podendo corrigir fazendo validação prévia do sistema de emissão de cupons, bem como utilizar blockchain [OWASP A04, 2021].

Utilização de bots: Plataforma de varejo em e-commerce não possui proteção contra bots, é possível que em dada promoção bots programados comprem todo o estoque de um produto e revendam em sites de leilões, ou façam transações suspeitas. Para corrigir este problema é necessário utilizar design anti-bot e regras de lógica de domínio, pois assim evitaria que compras e transações suspeitas sejam feitas em tão pouco tempo [OWASP A04, 2021].

Formas de prevenir design inseguro

Algumas formas de prevenir essa falha são [OWASP A04, 2021]:

• Utilizar bibliotecas padrões para projetos seguros;
• Estabelecer ciclo de vida de desenvolvimento seguro com profissionais de AppSec para avaliar/validar a segurança do projeto e prestar consultoria sobre controles de segurança e privacidade;
• Efetuar verificações de segurança em todas as camadas do projeto, partindo do front-end e indo ao back-end, verificando também os bancos de dados;
• Estabelecer e utilizar modelagem de ameaça para controles de acesso, autenticações críticas, lógica de negócio;
• Validar se todos os fluxos críticos são resilientes aos modelos de ameaça estabelecidos;
• Limite os recursos por usuário ou serviço, seguindo a lógica Zero Trust. 

OWASP Top 5 – Security Misconfiguration (Configuração Insegura)

Podemos considerar as falhas por configuração insegura como fáceis de explorar, visto que em muitos casos as configurações padrões são mantidas. Isso se deve ao fato de administradores de sistemas e/ou banco de dados e/ou desenvolvedores não se adequarem corretamente ao framework de segurança de aplicativos, cloud, servidores, e sites web. Aproximadamente 75% a 85% das vulnerabilidades comuns encontradas são devido a configurações inseguras. 

Se tratando de ambientes em cloud, os principais riscos e ameaças são decorrentes de configurações inseguras, correspondendo de 65% a 70% de vulnerabilidades identificadas nos principais serviços. Estão também entre as principais causas de vazamento massivo de informações sigilosas em entidades governamentais [Trend Micro, 2021].

Podemos identificar como principais falhas de configuração [OWASP A05, 2021]:

• Uso de software vulnerável ou descontinuado;
• Credenciais padrões ativas;
• Não seguir framework e políticas de segurança no desenvolvimento de serviços e/ou aplicações e/ou configurações indevidas de permissões em serviços que utilizam cloud;
• Ferramentas desnecessárias instaladas e/ou ativas, como serviços/aplicações/páginas rodando em portas desnecessárias;
• Ferramentas de segurança desativadas ou não configuradas corretamente; 
• Tratamento inadequado a mensagens de erro, podendo trazer informações como versão de algum software ou informações sensíveis, possibilitando reconhecimento por parte de invasores;
• Servidor não envia headers seguros, ou não há configuração adequada para isto;
• As configurações de segurança em servidores e frameworks de aplicações, banco de dados, bibliotecas não estão com parâmetros adequados. 

Exemplos de cenários de ataques

Um exemplo que possibilita esse tipo de ataque é quando as configurações do servidor permitem apresentação de mensagens detalhadas de erro, como número da versão do sistema ou outras informações que possam indicar os sistemas rodando em back-end, permitindo que o invasor encontre formas de invadir o sistema [OWASP A05, 2021].

Em provedores de serviços em nuvem (CSP) frequentemente ocorre essa vulnerabilidade devido às permissões de compartilhamento padrão, as quais são abertas para a internet, possibilitando assim que os dados armazenados sejam acessados por invasores. Para evitar isso, é necessário alterar essas permissões e manter uma política rígida para proteção dos dados e configuração de regras/permissões em serviços de cloud [OWASP A05, 2021].

No caso de servidores de aplicações, estes normalmente vêm com algumas ferramentas de exemplo instaladas no servidor de produção, as quais possuem vulnerabilidades conhecidas e com credenciais padrão, facilitando para o invasor. Sempre é indicado ter instalado apenas ferramentas que são realmente utilizadas, removendo totalmente todas as outras, bem como alterando as credenciais de acesso.  Outra vulnerabilidade comum em servidores está relacionada com a permissão para listagem de diretórios. Se esta não foi removida do servidor, um invasor pode listar diretórios e baixar arquivos e códigos fonte da página, levando a descoberta de outras vulnerabilidades [OWASP A05, 2021].

Formas de prevenir falhas por configuração insegura

Algumas políticas e ações para evitar falhas por configuração insegura e prevenir ataques [OWASP A05, 2021]:

• Arquitetura de aplicação segmentada entrega separação segura e eficaz entre componentes, com conteinerização, grupos de segurança em nuvem (ACL) e segmentação;
• Processo automatizado para verificação da eficiência das configurações e as configurações de todos os ambientes;
• Desinstale ou não faça instalação de ferramentas/recursos ou frameworks que não serão utilizados. Simplificação da plataforma, com uso do mínimo de recursos, ferramentas, componentes, amostras e documentações desnecessárias;
• Adotar processos de proteção repetitivos e automatizados. Utilizar credenciais diferentes, mas mesmo processo de criação de ambientes para ambiente de produção, desenvolvimento e controle de qualidade;
• Enviar diretivas de segurança a clientes, como headers de segurança;
• Revisar as regras/permissões de armazenamento e trabalho em nuvem, e gerenciar a atualização de configurações e instalação de novos patches.  

Referências

[Acunetix , 2020] The Acunetix Blog, por Tomasz Andrzej Nidecki. What Are Insecure Direct Object References. Março, 2020. URL: https://www.acunetix.com/blog/web-security-zone/what-are-insecure-direct-object-references/. Acessado em: 12/01/2022. 

[Oreilly, 2022] Oreilly. Insecure Direct Object References. 2022. URL: https://www.oreilly.com/library/view/securing-node-applications/9781491982426/ch04.html . Acessado em: 12/01/2022.  

[OWASP A01, 2022] OWASP Foundation, Inc. A01:2021 – Broken Access Control. 2021. URL: https://owasp.org/Top10/A01_2021-Broken_Access_Control/. Acessado em: 12/01/2022.

[Spanning, 2020] Spanning blog, por Shyam Oza. Insecure Direct Object Reference (IDOR) — Web-based Application Security, Part 6. Fevereiro, 2020. URL: https://spanning.com/blog/insecure-direct-object-reference-web-based-application-security-part-6/. Acessado em: 12/01/2022.

[PortSwigger , 2022] PortSwigger Web Security Academy. Insecure direct object references (IDOR). 2022. URL: https://portswigger.net/web-security/access-control/idor. Acessado em: 12/01/2022.

[OWASP A02, 2021] OWASP Foundation, Inc. A02:2021 – Cryptographic Failures. 2021. URL: https://owasp.org/Top10/A02_2021-Cryptographic_Failures/. Acessado em: 12/01/2022.

[FreeCodeCamp, 2017] FreeCodeCamp, por Nabeel Yoosuf. The many, many ways that cryptographic software can fail. Janeiro de 2017. URL: https://www.freecodecamp.org/news/why-does-cryptographic-software-fail-often-d660d3cdfdc5/. Acessado em: 12/01/2022.

[Heartbleed, 2020] Heartbleed. The Heartbleed Bug. Junho de 2020. URL: https://heartbleed.com/. Acessado em: 12/01/2022.

[OWASP A03, 2021] OWASP Foundation, Inc. A03:2021 – Injection. 2021. URL: https://owasp.org/Top10/A03_2021-Injection/ . Acessado em 12/01/2022.

[OWASP Code Injection, 2021] OWASP Foundation, Inc. Code Injection. 2021. URL:  . Acessado em 12/01/2021https://owasp.org/www-community/attacks/Code_Injection . Acessado em 12/01/2022.

[OWASP Command Injection, 2021] OWASP Foundation, Inc. Command Injection. 2021. URL: https://owasp.org/www-community/attacks/Command_Injection . Acessado em 12/01/2022.

[OWASP SQL Injection, 2021] OWASP Foundation, Inc. SQL Injection. 2021. URL:  . Acessado em 12/01/2021https://owasp.org/www-community/attacks/SQL_Injection . Acessado em 12/01/2022.

[OWASP Blind SQL Injection, 2021] OWASP Foundation, Inc. Blind SQL Injection. 2020. URL:  . Acessado em 12/01/2021https://owasp.org/www-community/attacks/Blind_SQL_Injection . Acessado em 12/01/2022

[OWASP XSS, 2021] OWASP Foundation Inc. Cross Site Scripting (XSS). 2021. URL:  . Acessado em 12/01/2021 https://owasp.org/www-community/attacks/xss/ . Acessado em 12/01/2022

[OWASP Injection Flaws, 2021] OWASP Foundation, Inc. Injection Flaws. 2021. URL: https://owasp.org/www-community/Injection_Flaws . Acessado em 12/01/2022

[OWASP Web Security, 2021] OWASP Foundation, Inc. Web Security Testing Guide. 2021. URL: https://owasp.org/www-project-web-security-testing-guide/ . Acessado em: 12/01/2022

[OWASP A04, 2021] OWASP Foundation, Inc. A04:2021 – Insecure Design. 2021. URL: https://owasp.org/Top10/A04_2021-Insecure_Design/. Acessado em: 12/01/2022.

[Cisco Press, 2017] Pearson Education, Cisco Press. Securing IoT – Common Challenges in OT Security. 2017. URL: https://www.ciscopress.com/articles/article.asp?p=2803867&seqNum=2 . Acessado em: 12/01/2022.

[NetworkComputing, 2021] NetworkComputing, por Sam Bocetta. Misconfigurations: Still the Biggest Threat to Cloud Security. Agosto, 2021. URL: https://www.networkcomputing.com/cloud-infrastructure/misconfigurations-still-biggest-threat-cloud-security. Acessado em: 12/01/2022.

[The Internet of Things on AWS, 2021] Ten security golden rules for industrial IoT Solutions. 2021. URL: https://aws.amazon.com/blogs/iot/ten-security-golden-rules-for-industrial-iot-solutions/ . Acessado em: 12/01/2022.

[Thales Group, 2022] IoT Security by Design (Step by Step). 2022. URL: https://www.thalesgroup.com/en/markets/digital-identity-and-security/iot/iot-security/key-principles . Acessado em: 12/01/2022.

[Outpost24, 2020] Outpost24, por Sergio Loureiro. What are Security Misconfigurations and how to prevent them?. Junho, 2020. URL: https://outpost24.com/blog/What-are-security-misconfigurations-and-how-to-prevent-them. Acessado em: 12/01/2022.

[OWASP A05, 2021] OWASP Foundation, Inc. A05:2021 – Security Misconfiguration. 2022. URL: https://owasp.org/Top10/A05_2021-Security_Misconfiguration/. Acessado em: 12/01/2022.

[Trend Micro, 2021] Trend Micro. The Most Common Cloud Misconfiguration That Could Lead to Security Breaches. 2021. URL: https://www.trendmicro.com/vinfo/us/security/news/virtualization-and-cloud/the-most-common-cloud-misconfigurations-that-could-lead-to-security-breaches . Acessado em: 12/01/2022.