Ataques na Camada de Aplic Flashcards
LFI – Local Files Insert ou Inclusão de Arquivo local
A sua aplicação básica acontece na tentativa de burlar as técnicas de controle de acesso por intermédio de consultas a arquivos locais no servidor que armazenam informações.
Assim, caso o atacante obtenha informações dos arquivos e consiga acessá-los, é possível inserir arquivos ou dados em arquivos, permitindo assim o seu acesso posterior.
Essa técnica basicamente se utiliza da passagem de parâmetros em suas requisições para manipulação no lado do servidor, geralmente com o método GET do HTTP.
RFI – Remote File Insert ou Inclusão de Arquivo Remoto
Nesse caso, o RFI utiliza de um servidor comprometido para passar inserir arquivos em outro servidor alvo. Tal técnica se utiliza da passagem de URL do servidor comprometido para envio do arquivo em áreas da nova vítima que suportam inserção de arquivos.
Assim, em princípio, é mais tranquilo realizar esse ataque em áreas do site que simplesmente aceitem a entrada de arquivos e tenham códigos que permitam a inserção de URL’s como passagem de parâmetro.
Cross-Site-Scripting (XSS)
Esses ataques exploram uma vulnerabilidade no servidor de aplicação de determinado sistema e modificam o código inserindo código malicioso. A partir de então, todos que entrarem nesse link, que até um primeiro momento é legítimo, será afetado.
Os ataques de XSS são frequentemente utilizados para causar danos, seja através da obtenção de dados dos usuários, como o prejuízo de imagem da instituição que está “hospedando” o código malicioso.
Percebam que, apesar do código residir no servidor de aplicação, a atuação do XSS não é contra o servidor de aplicação, mas sim, aos usuários daquele serviço, onde de fato o script será executado.
Assim, pode-se sequestrar as sessões dos usuários através de cookies, alterar códigos HTML no lado do cliente, redirecionar usuários para sites maliciosos (phishing) e alterar os objetos para captura de entradas de usuários.
Para se evitar esse tipo de ataque podemos extrair do guia OWASP, o seguinte. “Deve-se separar os dados não confiáveis do ativo no navegador”.
Cross-site scripting armazenado (XSS Persistente ou armazenado)
Tem a característica de ser o mais danoso. Envolve uma entrada do usuário direto para o processamento em uma página web. Geralmente associada a fóruns de mensagens ou redes sociais, por meio dos comentários e interações. O atacante, conforme vimos, injeta o código malicioso no servidor, provedor do serviço. Essa carga está armazenada no servidor e será processada, tão logo seja acessado, pelo cliente no navegador da própria vítima.
Cross-site scripting Refletido (XSS Não persistente ou refletido)
Não sendo o mais danoso, porém, o mais comum. Nesse caso, a carga não é armazenada no servidor, e, portanto, deverá fazer parte da carga envolvida na requisição do usuário. Por isso é conhecido como refletido, pois parte do próprio usuário, para ele mesmo. Na prática, a resposta HTTP inclui a carga útil da solicitação HTTP.
Tal processo geralmente é deflagrado por uma interação anterior da vítima com algum site ou serviço malicioso. Por não ser um ataque persistente, o invasor precisa que a carga útil maliciosa seja repassada a cada vítima. Vejam a diferença do XSS persistente, onde basta que a carga útil maliciosa seja inserida no servidor, não tendo que ser propagada para cada potencial vítima.
Cross-site scripting baseado em DOM - Document Object Model
Neste caso, fica associado direto ao DOM e não ao HTML. Em ataques de cross-site scripting refletidos e armazenados, você pode ver a carga útil da vulnerabilidade na página de resposta, mas no cross-site scripting baseado em DOM, o código-fonte HTML do ataque e a resposta serão os mesmos, ou seja, a carga útil não pode ser encontrada na resposta. Ele só pode ser observado em tempo de execução ou investigando o DOM da página.
Geralmente o ataque é aplicado diretamente e exclusivamente no lado do cliente, não sendo enviada ao servidor.
Defesa (técnicas OWASP) para XSS
CSRF (Cross-Site Request Forgery) ou XSRF
Diferentemente do XSS, o CSRF não busca obter informações ou roubar dados, mas tão somente redirecionar ações legítimas do usuário, transformando-as, e aplicando no serviço em questão.
O atacante, apesar de não conhecer a senha da vítima, consegue se utilizar das identidades dela para gerar o ataque
etapa 1, há uma conexão legítima com um servidor correto. Já na etapa 2, em paralelo, o próprio usuário acessar um outro site/serviço malicioso. Na etapa 3, ele recebe o conteúdo malicioso, geralmente uma página, em que, ao acessar, passa a estar vulnerável. A partir daí, já na etapa 4, o atacante é capaz de forjar as requisições a partir da etapa 1, que foi o estabelecimento de uma conexão/sessão.
Defesa para CSRF (Cross-Site Request Forgery) ou XSRF
Uma delas é o recurso HSTS - HTTP Strict Transport Security.
Basicamente, sua implementação reside no estabelecimento da obrigatoriedade por parte de um site ou serviço WEB de que suas requisições sejam realizadas por meio DO HTTPS apenas. Muitos sites e serviços recepcionam as requisições tanto em HTTP e HTTPS. Muitas, simplesmente implementam um redirecionamento das chamadas HTTP para a página HTTPS. E aí está um primeiro problema. Nessa transição, o usuário está vulnerável e poder ser atacado.
Desse movo, essa técnica de segurança do HSTS simplesmente envia no cabeçalho de resposta HTTP. Essa técnica também foi implementada para combater uma forma de ataque conhecida como SSL STRIP ATTACK ou SSL DOWNGRADE, onde basicamente o usuário malicioso aplica uma ataque man-in-the-middle, e, antes do estabelecimento da conexão HTTPS entre o usuário e o servidor, ele consegue antecipar. A imagem a seguir representa essa técnica:
outras defesas para CSRF (Cross-Site Request Forgery) ou XSRF
Avançando um pouco mais na nossa discussão, sem dúvida a principal técnica atualmente utilizada reside na criação/utilização de tokens anti-csrf. Basicamente esse token busca garantir que o usuário autenticado é, de fato, quem deve realizar as requisições. A segurança reside na geração desse token para cada sessão aberta a partir do nó do usuário e somente é alterado no ato da renovação da sessão do próprio usuário.
Exigindo um segredo, específico do token do usuário em todas os formulários de submissões e o efeito colateral das URLs impedem o CSRF; o site do invasor não pode colocar o token direto nas suas alegações
* Exigir que o cliente forneça dados de autenticação na solicitação HTTP mesmo se utilizado para realizar qualquer operação com implicações de segurança (transferência de dinheiro, etc)
* Limitar o tempo de vida de cookies da sessão
* Verificando o cabeçalho HTTP
Referer
* Assegurando que não há nenhum arquivo clientaccesspolicy.xml para a concessão de acesso não intencional aos controles Silverlight
* Assegurando que não há nenhum arquivo crossdomain.xml concedendo acesso não intencional de vídeos em Flash
SSRF - Server-side-request forgery
diagrama SSRF
clickjacking
para evitar, usar X-frame-Options
clickjacking código html
Injeção SQL (SQL Injection)
Ataque bastante conhecido e difundido, porém, com grande nível de sucesso atualmente. Esse tipo de ataque também explora uma vulnerabilidade da aplicação (página web, por exemplo).
Esse tipo de ataque permite que determinado usuário malicioso manipule as entradas de banco de dados nos envios de requisições ou consultas à base de dados de alguma aplicação.
Assim, caso não haja o devido bloqueio de operações, pode-se, por exemplo, complementar um comando de consulta a uma tabela que visa retornar uma lista, com um “DROP TABLE”, podendo gerar perda de todos os dados ali armazenados.
