Guinguette Marais Poitevin

OWASP ou Open Web Security Project é uma organização de caridade sem fins lucrativos centrada na melhoria da segurança de software e aplicações Web.

A organização publica uma lista das principais vulnerabilidades de segurança na Web com base nos dados de várias organizações de segurança.

As vulnerabilidades de segurança Web são priorizadas em função da explorabilidade, detectabilidade e impacto no software.

• Explorabilidade –

  O que é necessário para explorar a vulnerabilidade de segurança? A maior capacidade de exploração quando o ataque necessita apenas de um navegador web e a mais baixa sendo programação e ferramentas avançadas.

• Detectabilidade –

  Quão fácil é detectar a ameaça? A mais alta sendo a informação apresentada no URL, Formulário ou mensagem de erro e a mais baixa sendo o código fonte.

• Impacto ou dano –

  Quantos danos serão causados se a vulnerabilidade de segurança for exposta ou atacada? O mais alto sendo a falha completa do sistema e o mais baixo sendo nada.

O principal objectivo do OWASP Top 10 é educar os programadores, designers, gestores, arquitectos e organizações sobre as vulnerabilidades de segurança mais importantes.

As 10 principais vulnerabilidades de segurança de acordo com o OWASP Top 10 são:

>li>Injeção doSQL
• Cross Site Scripting
• Autenticação Falida e Gestão de Sessão

li>Insecure Direct Object References

• Falsificação de Pedido de Sítio Cruzado
• Security Misconfiguration

Insecure Cryptographic Storage

• Failure to restrict URL Access
• Insuficiente Protecção da Camada de Transporte
• Reorientações e Avanços Não Validados

Injecção SQL

Descrição

Injecção é uma vulnerabilidade de segurança que permite a um atacante alterar as instruções SQL backend manipulando os dados fornecidos pelo utilizador.

Injecção ocorre quando a entrada do utilizador é enviada a um intérprete como parte de um comando ou consulta e engana o intérprete para executar comandos não intencionais e dá acesso a dados não autorizados.

O comando SQL que quando executado por aplicação web também pode expor a base de dados back-end.

Implicação

• Um atacante pode injectar conteúdo malicioso nos campos vulneráveis.
• Dados sensíveis como Nomes de Utilizador, Passwords, etc. podem ser lidos a partir da base de dados.
• Dados da base de dados podem ser modificados (Inserir/Actualizar/ Apagar).
• As operações de administração podem ser executadas na base de dados

Projectos vulneráveis

• Campos de entrada
• URLs interagindo com a base de dados.

Exemplos:

• injecção deSQL na Página de Login

Logging into an application without having valid credentials.

Nome de utilizador válido está disponível, e a palavra-passe não está disponível.

Teste URL: http://demo.testfire.net/default.aspx

Nome do utilizador: sjones

Senha de utilizador: 1=1′ ou pass123

SenhaSQL criada e enviada para Intérprete como abaixo

SELECT * DE Utilizadores ONDE Nome_de_utilizador = sjones E Senha = 1=1′ ou pass123;

Recomendas

1. Li>Li>Li>Li>Evite a exibição de mensagens de erro detalhadas que sejam úteis a um atacante.

Cross Site Scripting

Descrição

Cross Site Scripting é também brevemente conhecido como XSS.

Vulnerabilidades de XSS scripts alvo embutidos numa página que são executados do lado do cliente, ou seja, browser do utilizador e não do lado do servidor. Estas falhas podem ocorrer quando a aplicação toma dados não confiáveis e os envia para o web browser sem a devida validação.

Atackers podem usar XSS para executar scripts maliciosos nos navegadores das vítimas neste caso. Uma vez que o navegador não pode saber se o script é de confiança ou não, o script será executado, e o atacante pode sequestrar cookies de sessão, desfigurar websites, ou redireccionar o utilizador para um website indesejado e malicioso.

XSS é um ataque que permite ao atacante executar os scripts no navegador da vítima.

Implicação:

• Fazendo uso desta vulnerabilidade de segurança, um atacante pode injectar scripts na aplicação, pode roubar cookies de sessão, desfigurar websites, e pode executar malware nas máquinas da vítima.

Objectos vulneráveis

• Campos de entrada
• URLs

Exemplos

1. http://www.vulnerablesite.com/home?”<script>alert(“xss”)</script>

O script acima quando executado num browser, uma caixa de mensagem será exibida se o site for vulnerável ao XSS.

O ataque mais grave pode ser feito se o atacante quiser exibir ou armazenar o cookie de sessão.

2. http://demo.testfire.net/search.aspx?txtSearch<iframe><src = http://google.com width = 500 height 500></iframe>

O script acima quando executado, o navegador irá carregar uma moldura invisível apontando para http://google.com.

O ataque pode ser tornado sério executando um script malicioso no browser.

Recomendações

1. Campos de entrada da Listagem Branca
2. Input Output encoding

Autenticação Quebrada e Gestão de Sessão

Descrição

Os websites geralmente criam um cookie de sessão e um ID de sessão para cada sessão válida, e estes cookies contêm dados sensíveis como nome de utilizador, palavra-passe, etc. Quando a sessão termina, quer por logout quer por fecho brusco do navegador, estes cookies devem ser invalidados, ou seja, para cada sessão deve haver um novo cookie.

Se os cookies não forem invalidados, os dados sensíveis existirão no sistema. Por exemplo, um utilizador que utilize um computador público (Cyber Cafe), os cookies do sítio vulnerável ficam sobre o sistema e expostos a um atacante. Um atacante utiliza o mesmo computador público após algum tempo, os dados sensíveis são comprometidos.

Da mesma forma, um utilizador que utiliza um computador público, em vez de terminar a sessão, fecha abruptamente o navegador. Um agressor utiliza o mesmo sistema, quando navega no mesmo sítio vulnerável, a sessão anterior da vítima será aberta. O atacante pode fazer o que quiser a partir do roubo de informações de perfil, informações de cartão de crédito, etc.

Deve ser feita uma verificação para encontrar a força da autenticação e da gestão da sessão. As chaves, fichas de sessão, cookies devem ser implementadas correctamente sem comprometer as senhas.

Objectos vulneráveis

• IDs de sessão expostos na URL podem levar a um ataque de fixação da sessão.
• IDs de sessão iguais antes e depois do logout e login.
• Session Timeouts não são implementados correctamente.
• A aplicação está a atribuir o mesmo ID de sessão para cada nova sessão.
• As partes autenticadas da aplicação são protegidas usando SSL e as palavras-passe são armazenadas em formato hashed ou encriptadas.
• A sessão pode ser reutilizada por um utilizador pouco privilegiado.

Implicação

• Fazer uso desta vulnerabilidade, um atacante pode desviar uma sessão, obter acesso não autorizado ao sistema que permite a divulgação e modificação de informação não autorizada.
• As sessões podem ser elevadas usando cookies roubados ou sessões usando XSS.

Exemplos

1. A aplicação de reserva Airline suporta a reescrita do URL, colocando os IDs da sessão no URL:

   http://Examples.com/sale/saleitems;jsessionid=2P0OC2oJM0DPXSNQPLME34SERTBG/dest=Maldives (Venda de bilhetes para as Maldivas)

   Um utilizador autenticado do site quer informar os seus amigos sobre a venda e envia um e-mail através do mesmo. Os amigos recebem o ID da sessão e podem ser utilizados para fazer modificações não autorizadas ou utilizar indevidamente os detalhes do cartão de crédito guardado.

2. Uma aplicação é vulnerável a XSS, pela qual um atacante pode aceder ao ID da sessão e pode ser utilizada para desviar a sessão.
3. Os intervalos de tempo das aplicações não são definidos correctamente. O utilizador utiliza um computador público e fecha o navegador em vez de fazer o logout e afasta-se. O atacante usa o mesmo navegador algum tempo depois, e a sessão é autenticada.

Recomendas

1. Todos os requisitos de autenticação e gestão de sessão devem ser definidos de acordo com o Padrão de Verificação de Segurança de Aplicações OWASP.
2. Nunca exponha quaisquer credenciais em URLs ou Logs.
3. Deve também ser feito um grande esforço para evitar falhas XSS que podem ser usadas para roubar IDs de sessão.

Referências de Objectos Directos Inseguros

Descrição

Ocorre quando um programador expõe uma referência a um objecto de implementação interno, tal como um ficheiro, directório, ou chave de base de dados como em URL ou como um parâmetro FORM. O atacante pode utilizar esta informação para aceder a outros objectos e pode criar um ataque futuro para aceder aos dados não autorizados.

Implicação

• Utilizando esta vulnerabilidade, um atacante pode obter acesso a objectos internos não autorizados, pode modificar dados ou comprometer a aplicação.

Objectos vulneráveis

>

• No URL.

Exemplos:

Mudar “userid” no URL seguinte pode fazer um atacante para ver a informação de outros utilizadores.

http://www.vulnerablesite.com/userid=123 Modificado para http://www.vulnerablesite.com/userid=124

Um atacante pode ver outras informações alterando o valor de id do utilizador.

Recomendações:

1. Controlo de controlo de acesso de importação.
2. Anular referências de objectos expostos em URLs.
3. Verificar autorização para todos os objectos de referência.

Falsificação de Pedido de Local Cruzado

Descrição

Falsificação de Pedido de Local Cruzado é um pedido falsificado proveniente do local cruzado.

Ataque CSRF é um ataque que ocorre quando um website malicioso, e-mail, ou programa faz com que o navegador de um utilizador execute uma acção indesejada num site de confiança, para o qual o utilizador está actualmente autenticado.

Um ataque CSRF força um navegador da vítima ligado a enviar um pedido HTTP forjado, incluindo o cookie de sessão da vítima e qualquer outra informação de autenticação automaticamente incluída, para uma aplicação web vulnerável.

Uma ligação será enviada pelo atacante à vítima quando o utilizador clica no URL ao entrar no sítio web original, os dados serão roubados do sítio web.

Implicação

• Usar esta vulnerabilidade como atacante pode alterar a informação do perfil do utilizador, alterar o estado, criar um novo utilizador em nome da administração, etc.

Objectos vulneráveis

• Página de perfil de utilizador
• Formulários de conta de utilizador
• Página de transacções comerciais

Exemplos

A vítima é ligada a um sítio web de um banco usando credenciais válidas. Ele recebe correio de um agressor dizendo “Por favor, clique aqui para doar $1 para causar”.

Quando a vítima clica nele, será criado um pedido válido para doar $1 a uma determinada conta.

http://www.vulnerablebank.com/transfer.do?account=cause&amount=1

O atacante capta este pedido e cria abaixo do pedido e incorpora num botão que diz “Eu apoio a Causa”.

http://www.vulnerablebank.com/transfer.do?account=Attacker&amount=1000

P>Desde que a sessão seja autenticada e o pedido venha através do website do banco, o servidor transferiria $1000 dólares para o atacante.

Recomendation

1. Manda a presença do utilizador enquanto executa acções sensíveis.
2. Mecanismos de implementação como , Re-Autenticação, e Tokens de Pedido Único.

Má configuração de segurança

Descrição

p>p>Configuração de segurança deve ser definida e implementada para a aplicação, frameworks, servidor de aplicação, servidor web, servidor de base de dados, e plataforma. Se estas estiverem devidamente configuradas, um atacante pode ter acesso não autorizado a dados sensíveis ou funcionalidades.

Por vezes tais falhas resultam num comprometimento completo do sistema. Manter o software actualizado é também uma boa segurança.

Implicação

• Fazendo uso desta vulnerabilidade, o atacante pode enumerar a tecnologia subjacente e informação da versão do servidor de aplicação, informação da base de dados e obter informação sobre a aplicação para montar mais poucos ataques.

Objectos vulneráveis

• URL
• Campos de formulário
• Campos de entrada

Exemplos

1. A consola de administração do servidor de aplicação é automaticamente instalada e não removida. As contas predefinidas não são alteradas. O atacante pode entrar com senhas padrão e pode obter acesso não autorizado.
2. A listagem de directórios não é desactivada no seu servidor. O atacante descobre e pode simplesmente listar directórios para encontrar qualquer ficheiro.

Recomendas

1. Uma arquitectura de aplicação forte que proporciona uma boa separação e segurança entre os componentes.
2. Alterar nomes de utilizador e palavras-passe por defeito.
3. Li>Listuras de directórios desactiváveis e verificações de controlo de acesso implementadas.

Armazenamento Criptográfico Inseguro

Descrição

Armazenamento Criptográfico Inseguro é uma vulnerabilidade comum que existe quando os dados sensíveis não são armazenados de forma segura.

As credenciais do utilizador, informação de perfil, detalhes de saúde, informação de cartão de crédito, etc. estão sob a informação de dados sensíveis num website.

Estes dados serão armazenados na base de dados da aplicação. Quando estes dados forem armazenados de forma imprópria, não utilizando encriptação ou hashing*, ficarão vulneráveis aos atacantes.

(*Hashing é a transformação dos caracteres da cadeia em cadeias mais curtas de comprimento fixo ou uma chave. Para decifrar a string, o algoritmo utilizado para formar a chave deve estar disponível)

Implication

• Ao utilizar esta vulnerabilidade, um atacante pode roubar, modificar dados tão fracamente protegidos para conduzir roubo de identidade, fraude de cartão de crédito ou outros crimes.

Objectos vulneráveis

• Base de dados da aplicação.

Exemplos

Numa das aplicações bancárias, a base de dados de senhas usa hashes não salgados * para armazenar as senhas de todos. Uma falha de injecção SQL permite que o atacante recupere o ficheiro de palavras-passe. Todos os hashes não salgados podem ser forçados em pouco tempo, enquanto que as palavras-passe salgadas levariam milhares de anos.

(*Hashes não salgados – Sal é um dado aleatório anexado aos dados originais. O sal é anexado à senha antes do hashing)

Recomendações

1. Segurar algoritmos padrão fortes apropriados. Não criar algoritmos criptográficos próprios. Utilize apenas algoritmos públicos aprovados, tais como AES, criptografia de chave pública RSA, e SHA-256, etc.

li>Segure que as cópias de segurança fora do local são encriptadas, mas as chaves são geridas e apoiadas separadamente.

Falha em restringir o acesso à URL

Descrição

p>Aplicações Web verificam os direitos de acesso à URL antes de renderizar ligações e botões protegidos. As aplicações precisam de efectuar verificações de controlo de acesso semelhantes cada vez que estas páginas são acedidas.

Na maioria das aplicações, as páginas, locais e recursos privilegiados não são apresentados aos utilizadores privilegiados.

Por um palpite inteligente, um atacante pode aceder às páginas de privilégios. Um atacante pode aceder a páginas sensíveis, invocar funções e visualizar informações confidenciais.

Implicação

• A utilização deste atacante vulnerável pode obter acesso aos URLs não autorizados, sem iniciar sessão na aplicação e explorar a vulnerabilidade. Um atacante pode aceder a páginas sensíveis, invocar funções e visualizar informações confidenciais.

objecto vulnerável:

URLs

Exemplos

1. Attacker nota que o URL indica o papel como “/user/getaccounts”. Ele modifica como “/admin/getaccounts”.
2. Um atacante pode anexar o papel ao URL.

http://www.vulnerablsite.com pode ser modificado como http://www.vulnerablesite.com/admin

Recomendas

1. Implementar fortes verificações de controlo de acesso.
2. As políticas de autenticação e autorização devem ser baseadas em funções.
3. Restrição do acesso a URLs indesejadas.

Protecção insuficiente da camada de transporte

Descrição

p>p>Tratamentos com troca de informação entre o utilizador (cliente) e o servidor (aplicação). As aplicações transmitem frequentemente informação sensível como detalhes de autenticação, informação de cartão de crédito, e fichas de sessão através de uma rede.

Por meio de algoritmos fracos ou usando certificados expirados ou inválidos ou não usando SSL pode permitir que a comunicação seja exposta a utilizadores não confiáveis, o que pode comprometer uma aplicação web e ou roubar informação sensível.

Implicação

• Fazendo uso desta vulnerabilidade de segurança web, um atacante pode farejar as credenciais do utilizador legítimo e obter acesso à aplicação.
• Pode roubar informação de cartão de crédito.

Objectos vulneráveis

Dados enviados através da rede.

Recomendações

>li>Fixar HTTP seguro e impor a transferência de credenciais apenas sobre HTTPS.
1. Segurar que o seu certificado é válido e não expirou.

Exemplos:

1. Uma aplicação que não utilize SSL, um atacante irá simplesmente monitorizar o tráfego da rede e observar um cookie de sessão de vítima autenticado. Um atacante pode roubar esse cookie e executar o Man-in-the-Middle attack.

Redireccionamentos e Encaminhamentos não validados

Descrição

A aplicação web usa poucos métodos para redireccionar e reencaminhar utilizadores para outras páginas para um fim pretendido.

Se não houver validação adequada enquanto redirecciona para outras páginas, os atacantes podem fazer uso disto e podem redireccionar as vítimas para sites de phishing ou malware, ou utilizar o reencaminhamento para aceder a páginas não autorizadas.

Implicação

• Um atacante pode enviar um URL ao utilizador que contenha um URL genuíno anexado com um URL malicioso codificado. Um utilizador vendo apenas a parte genuína do URL enviado pelo atacante pode navegá-lo e pode tornar-se uma vítima.

Exemplos

1.http://www.vulnerablesite.com/login.aspx?redirectURL=ownsite.com

Modificado para

http://www.vulnerablesite.com/login.aspx?redirectURL=evilsite.com

Recomendas

1. Simplesmente evite utilizar redireccionamentos e reencaminhamentos na aplicação. Se usado, não envolver a utilização de parâmetros de utilizador no cálculo do destino.
2. Se os parâmetros de destino não puderem ser evitados, assegurar que o valor fornecido é válido, e autorizado para o utilizador.

Este artigo é contribuído por Prasanthi Eati