OWASP: padrão de verificação de segurança de aplicações V9 a V14

Communications Requirements - Introdução

Bem-vindo a mais um curso de OWASP, onde nós vamos falar de padrão de verificação de segurança de aplicações de acordo com o relatório da OWASP.

Então, nesse curso nós vamos abordar da parte de verificação de comunicações, de verificação de código malicioso, malvado e que não quer causar o bem a nenhum de nós; verificação de lógicas de negócio, de arquivos e recursos; de APIs e de web services. Apesar que, durante todo esse tempo eu estarei discutindo de APIs e web services.

E aqui mesmo ele cita, olhe, não vou ficar repetindo tudo o que nós já falamos, apesar de repetir uma coisinha ou outra, eu também discuti algumas dessas outras já em cursos anteriores e também discuto nas outras seções.

E de verificação de configuração em geral, em que parece ter um agrupamento de configurações de bulids, de dependências, de configurações de cabeçalhos e de diversas coisas que não são necessariamente o termo “configuração”, o que é muito genérico.

Então tudo isso nós vamos ver nesse curso. Lembrando que nós estamos atacando aqui o level 1, que o foco é OWASP top 10, as 10 principais vulnerabilidades de aplicações web. Nós vamos estar sempre discutindo no contexto de o que que um atacante pode fazer e o que nós devemos fazer para nos prevenirmos.

Não necessariamente só uma das técnicas é necessária o suficiente para prevenir os ataques, mas é por isso que nós passamos por diversas delas, para que nós estejamos protegendo em todos os pontos e dificultando o ataque de alguém aos nossos sistemas.

Então, com isso, nós vamos completar esse documento. Vai ver muita coisa legal para nós nos protegermos e espero que você aproveite e estude bastante! Vamos lá?

Communications Requirements - Communications Verification Requirements

Então, vamos começar! Nessa seção de requerimento de verificação, nós vamos falar de comunicação, isto é, menos de armazenamento em um local específico, e mais sobre a comunicação entre dois ou mais pontos.

Nós já tocamos esse assunto a medida que ele foi aparecendo em outros tópicos, como é normal que os tópicos de segurança estão de alguma forma correlacionados ou existe alguma conexão entre eles.

E os objetivos desse controle, claro, estão muito ligados com a segurança dos dados em comunicação. O básico seria usar um algoritmo de criptografia forte, como por exemplo, TLS. Então, usar isso sempre, em toda comunicação entre pontos, não importando o quão sensível são os dados transmitidos.

Então se você está fazendo um requisição para uma imagem pública que é o logotipo da sua empresa, não importa, essa conexão que busca essa imagem também é feita através de uma conexão criptografada, como por exemplo: utilizando TLS, então HTTPS em vez de HTTP.

Nós discutimos até esse caso. Por que uma conexão para imagem também deveria ser feita via HTTPS? Por causa das questões dos cookies e de outras quebras e vulnerabilidades de segurança que nós encontramos por aí. Então, usar TLS sempre, em qualquer protocolo. No caso do HTTP, usar HTTPS.

Utilizar as dicas de segurança - não são dicas, mas o guidelines, e o que tiver que ser utilizado de segurança é para os algoritmos e para as cifras utilizadas para comunicação ou para criptografia.

Não utilizar algoritmos fracos ou que vão ser depreciados em breve, ou cifras que são ordenadas como último. Somente utilizar elas como última alternativa, isso é, de preferência não as utilizar. Se o algoritmo, se a cifra é fraca, se ela vai ser deprecada, se o algoritmo vai ser depreciado em breve; isto é, não é mais para ser utilizado em breve.

Algoritmos e cifras que são fracas ou que vão ser depreciados, isto é, não deverão ser mais utilizados em breve. Devem estar ordenados como um último recurso, isto é, devemos utilizar algoritmos fortes e que não estão depreciados, de preferência.

Depois, algoritmos com falhas de segurança conhecidas, inseguros ou depreciados e cifras do gênero. Não devem ser utilizados, então os que vão ser depreciados em breve ou que são fracos devem ser a última alternativa. Mas se já depreciou ou se tem falhas de segurança conhecidas, o que que nós temos que fazer? Desabilitarmos!

E tem um conceito importante: algumas bibliotecas de cifras, se você não especificar qual você vai utilizar, ela escolhe por alguma decisão própria, e essa decisão pode acabar utilizando algum algoritmo específico que você não queria mais estar utilizando.

Se você não mantém a atualização da biblioteca, não dá a manutenção adequada, ela vai estar utilizando um algoritmo cada vez mais antigo, porque o tempo vai passando. Então o algoritmo é cada vez mais antigo e ele pode ser nas versões atuais depreciados, mas na versão antiga que você está utilizando ainda não.

Então as recomendações de utilização de configuração de TLS segura mudam frequentemente, principalmente por quebras em algoritmos e quebras assim fenomenais. Eles colocam aqui, catastróficas, por quebras catastróficas em diversas configurações de algoritmos e cifras. As recomendações de TLS mudam frequentemente.

Então, utilizar as ferramentas que dão uma revisão da sua configuração de TLS, como TLS scanners ou SSLyse, utilizar alguns deles para configurar ou escolher o algoritmo adequado para configuração.

E a configuração tem que ser checada periodicamente, mas isso nós já discutimos lá em algoritmos, em vulnerabilidades de componentes desatualizados, por exemplo. Lá nós já discutimos essa questão de manter atualizado e não utilizar, então, algoritmos depreciados.

E por outro lado, nós já falamos de configuração malfeita e mantermos a configuração atualizada de acordo com as atualizações.

Então essas duas aqui, repare que elas são coisas que já apareceram anteriormente, mas agora já específicas para o TLS. Lembrando que então, esse guia de requerimentos acaba sendo genérico em algumas partes e específico em outras, para que nós não esqueçamos desses pontos específicos que são muito importantes.

Com isso, nós vamos entrar a fundo mais nesses itens, a medida que nós entramos nessa seção 9.

Communications Requirements - Communications Security Requirements

Então, a primeira subseção aqui vai falar de requerimentos de segurança da comunicação. Você fala: “poxa! Mas nos já estávamos falando de comunicação. Agora, no caso é de segurança, especificamente...” É um pouco do genérico. Toda comunicação deve ser através de caminhos criptografados. Ponto. É aquela história: em particular, o uso de TLS 1.2 ou posterior, é essencial e requerido na utilização de browsers modernos e sites de buscas.

Então nós vamos dar preferência para HTTPS e vamos tentar utilizar HTTPS em tudo. Quando digo tentar utilizar HTTPS em tudo, é utilizar HTTPS. Inclusive, a configuração deve ser feita e revisada utilizando ferramentas online que tentam garantir que nós tenhamos essas boas práticas de segurança no protocolo de comunicação.

Então existem ferramentas do Google, de não sei quem, diversas ferramentas que vão verificar como que está esse protocolo, como que está essa nossa configuração e dar sugestões do que alterarmos para trazermos mais segurança a comunicação. De novo, independentemente do dado que você esteja transitando de um lado para o outro.

Vamos lá! Primeira seção: verificar que TLS de forma segura e se está utilizada em toda a conexão com o cliente. Então, lembra? Às vezes ele está citando browser, às vezes ele está citando cliente.

Então, o cliente pode ser um browser, sim, pode ser o JavaScript do meu browser, pode ser o HTML, uma requisição que vai devolver um HTML. Então o browser em si, pode ser o JavaScript pedindo para o browser, pedindo para o seu site; pode ser um aplicativo ou pode ser uma aplicação sua. Toda comunicação de um cliente para um servidor, entre duas pontas deve ser feita através de uma conexão segura, com o TLS por trás ou algo do gênero.

Lembrando que TLS não é só para HTTP, então independentemente do protocolo, você vai querer ter um canal de comunicação seguro.

E um outro ponto importante aqui, que nós ainda não tínhamos discutido explicitamente, mas tínhamos discutido em outro cenário recentemente, era de que nós não devemos ir para um canal inseguro ou protocolos não criptografados como um “fallback”.

Isto é, imagine que o cliente tenta conectar com o servidor e eles tentam negociar qual a versão de um protocolo ou qual o tipo de protocolo de comunicação que eles vão utilizar, então eles fazem um “handshake”, onde eles vão negociar isso.

E quando o servidor percebe que o cliente não suporta, por exemplo, a versão 1.2 do TLS, ele de repente faz um “fallback” para uma versão mais antiga. Ou quando ele percebe que o cliente não suporta determinado protocolo, o TLS em si, ele vai para uma versão que não precisa do TLS, por exemplo.

Então eu só estou dando exemplos bem simples de como esse “fallback” pode ser feito de uma maneira insegura. Então, você indo para uma versão insegura do seu algoritmo porque no “handshake” você percebeu que o seu cliente não é capaz de utilizar uma versão segura, você abriu a porta de novo para a vulnerabilidade, para esse buraco de segurança que é utilizar uma versão depreciada, utilizar uma versão com falhas de seguranças conhecidas.

Então nós não queremos fazer “fallback” para protocolos não criptografados. Então, por exemplo: uma requisição HTTPS em que o cliente não suporta o HTTPS, você devolve o HTTP, você não quer fazer esse “fallback”, ou você não quer fazer o “fallback” para um canal inseguro ou não criptografado, ou mesmo a versão depreciada ou uma versão com falhas de segurança que você conhece. Então esse é o primeiro ponto.

Segundo ponto: utilizar ferramentas online ou ferramentas de teste de TLS que garantem que você está utilizando algoritmos fortes, cifras fortes, protocolos que estejam habilitados de comunicação que devem ser habilitados, com utilização de preferência dos algoritmos e cifras mais fortes possíveis.

Então se você tem disponibilidade de utilizar os algoritmos e cifras mais fortes possíveis e disponíveis hoje, não tem porquê utilizar os fortes que não são os mais fortes. Se você não tem um motivo para fazer isso, utilize os mais fortes que existem disponíveis hoje.

E as ferramentas de teste, como ele citou anteriormente de SSL e existem diversas outras, vão verificar esse tipo de configuração para nós e dizer o que nós podemos fazer.

Então isso daqui é razoavelmente automatizado. Esse outro aqui anterior de não fazer o “fallback” e etc., a configuração é mais manual. O teste aqui, é automatizável.

Verificar aqui versões antigas do SSL e do TLS, dos protocolos, algoritmos, cifras e configurações estão desabilitados, como SSL 2 e 3, o TLS 1 e 1.1. Como eu disse, você está em 1.2, você não quer fazer o “fallback” para o 1.1 ou para o 1.0.

A última versão do TLS deve ser um conjunto de cifras preferíveis para a comunicação. Então, de novo: eu tinha conectado isso um pouquinho aqui, mas na verdade já estava no 9.1.3, mas claro.

Então aqui ele está citando explicitamente SSL e TLS, mas independentemente disso, qualquer protocolo de comunicação e de criptografia na comunicação, ou qualquer algoritmo de segurança que você está utilizando, você não quer fazer “fallback” para versões depreciadas ou versões com conhecidas falhas de segurança.

Você mantém uma versão mais atualizada, ou na versão que você precisa que garante a segurança que você quer ter, então aqui é para garantir a segurança na comunicação. No final das contas, é utilizar algoritmos e cifras seguras, fortes, e não utilizar as fracas. Garantir que você está com ela dessa forma.

Então, utilizar ferramentas que testem isso e que toda comunicação seja feita através de protocolos seguros e criptografados. Então, garantir que nenhuma comunicação seja feita de outros canais, inclusive em um “handshake” que vai exigir um “downgrade”, um “fallback” para uma ferramenta insegura, você não deixa. Ou para uma versão insegura, você também não deixa isso acontecer.

Sobre o curso OWASP: padrão de verificação de segurança de aplicações V9 a V14

O curso OWASP: padrão de verificação de segurança de aplicações V9 a V14 possui 115 minutos de vídeos, em um total de 30 atividades. Gostou? Conheça nossos outros cursos de Segurança em DevOps, ou leia nossos artigos de DevOps.

Matricule-se e comece a estudar com a gente hoje! Conheça outros tópicos abordados durante o curso:

• Communications Requirements
• Malicious Code Verification Requirements
• Business Logic Requirements
• File and Resources Verification Requirements
• API and Web Service Verification Requirements
• Configuration Verification Requirements