Que explorações comuns da web devo saber?[fechado]

Question

Ainda sou bastante inexperiente quando se trata de programação web, passei a maior parte do tempo em aplicativos clientes.Portanto, estou curioso sobre as explorações comuns que devo temer/testar em meu site.

Answer 1

OWASP mantém uma lista dos 10 principais ataques na web a serem observados, além de uma tonelada de outras informações úteis de segurança para desenvolvimento web.

Answer 2

estou postando o Lista abreviada do OWASP Top 2007 aqui para que as pessoas não precisem procurar outro link e caso a fonte caia.

Scripting entre sites (XSS)

• As falhas de XSS ocorrem sempre que um aplicativo pega dados fornecidos pelo usuário e os envia para um navegador da Web sem primeiro validar ou codificar esse conteúdo.O XSS permite que invasores executem scripts no navegador da vítima que podem sequestrar sessões de usuários, desfigurar sites, possivelmente introduzir worms, etc.

Falhas de injeção

• Falhas de injeção, principalmente injeção de SQL, são comuns em aplicações web.A injeção ocorre quando os dados fornecidos pelo usuário são enviados a um interpretador como parte de um comando ou consulta.Os dados hostis do invasor induzem o intérprete a executar comandos não intencionais ou alterar dados.

Execução de arquivo malicioso

• O código vulnerável à inclusão remota de arquivos (RFI) permite que os invasores incluam códigos e dados hostis, resultando em ataques devastadores, como o comprometimento total do servidor.Ataques maliciosos de execução de arquivos afetam PHP, XML e qualquer estrutura que aceite nomes de arquivos ou arquivos de usuários.

Referência de objeto direto inseguro

• Uma referência direta a objeto ocorre quando um desenvolvedor expõe uma referência a um objeto de implementação interno, como um arquivo, diretório, registro de banco de dados ou chave, como uma URL ou parâmetro de formulário.Os invasores podem manipular essas referências para acessar outros objetos sem autorização.

Falsificação de solicitação entre sites (CSRF)

• Um ataque CSRF força o navegador da vítima conectada a enviar uma solicitação pré-autenticada a um aplicativo web vulnerável, o que força o navegador da vítima a executar uma ação hostil em benefício do invasor.O CSRF pode ser tão poderoso quanto o aplicativo da web que ele ataca.

Vazamento de informações e tratamento inadequado de erros

• Os aplicativos podem vazar involuntariamente informações sobre sua configuração, funcionamento interno ou violar a privacidade por meio de uma variedade de problemas de aplicativos.Os invasores usam essa fraqueza para roubar dados confidenciais ou realizar ataques mais sérios.

Autenticação quebrada e gerenciamento de sessão

• As credenciais da conta e os tokens de sessão muitas vezes não são devidamente protegidos.Os invasores comprometem senhas, chaves ou tokens de autenticação para assumir a identidade de outros usuários.

Armazenamento criptográfico inseguro

• Os aplicativos da Web raramente usam funções criptográficas de maneira adequada para proteger dados e credenciais.Os invasores usam dados pouco protegidos para realizar roubo de identidade e outros crimes, como fraude de cartão de crédito.

Comunicações inseguras

• Os aplicativos frequentemente falham ao criptografar o tráfego de rede quando é necessário proteger comunicações confidenciais.

Falha ao restringir o acesso ao URL

• Freqüentemente, um aplicativo protege apenas funcionalidades confidenciais, impedindo a exibição de links ou URLs para usuários não autorizados.Os invasores podem usar essa vulnerabilidade para acessar e realizar operações não autorizadas acessando diretamente esses URLs.

O Projeto de Segurança de Aplicações Web Abertas

-Adão

Answer 3

Estes três são os mais importantes:

• Falsificação de solicitação entre sites
• Script entre sites
• injeção SQL

Answer 4

Todo mundo vai dizer "SQL Injection", porque é a vulnerabilidade que parece mais assustadora e a mais fácil de entender.O Cross-Site Scripting (XSS) ficará em segundo lugar, porque também é fácil de entender."Validação de entrada ruim" não é uma vulnerabilidade, mas sim uma avaliação de uma prática recomendada de segurança.

Vamos tentar isso de uma perspectiva diferente.Aqui estão os recursos que, quando implementados em um aplicativo da web, provavelmente atrapalharão você:

• SQL dinâmico (por exemplo, construtores de consultas de UI).Até agora, você provavelmente já sabe que a única maneira confiável e segura de usar SQL em um aplicativo da web é usar consultas parametrizadas, nas quais você vincula explicitamente cada parâmetro da consulta a uma variável.Os locais onde vejo aplicativos da web violarem essa regra com mais frequência são quando a entrada mal-intencionada não é um parâmetro óbvio (como um nome), mas sim um atributo de consulta.Um exemplo óbvio são os construtores de consultas "Smart Playlist" semelhantes ao iTunes que você vê em sites de pesquisa, onde coisas como operadores de cláusula where são passados ​​​​diretamente para o back-end.Outra ótima opção são as classificações de colunas de tabelas, onde você verá coisas como DESC expostas em parâmetros HTTP.

• Carregamento de arquivo.O upload de arquivos confunde as pessoas porque os nomes dos caminhos dos arquivos parecem suspeitos como nomes dos caminhos da URL e porque os servidores da Web facilitam a implementação da parte de "download" apenas direcionando URLs para diretórios no sistema de arquivos.7 em cada 10 manipuladores de upload que testamos permitem que invasores acessem arquivos arbitrários no servidor, porque os desenvolvedores do aplicativo presumiram que as mesmas permissões foram aplicadas à chamada "open ()" do sistema de arquivos e aplicadas às consultas.

• Armazenamento de senha.Se o seu aplicativo puder me enviar de volta minha senha bruta quando eu a perder, você falhará.Existe uma única resposta segura e confiável para armazenamento de senhas, que é bcrypt;se você estiver usando PHP, provavelmente desejará o PHPpass.

• Geração de números aleatórios.Um ataque clássico a aplicativos da web:redefinir a senha de outro usuário e, como o aplicativo está usando a função "rand ()" do sistema, que não é criptografada, a senha é previsível.Isso também se aplica a qualquer lugar em que você esteja fazendo criptografia.O que, aliás, você não deveria fazer:se você depende de criptografia em qualquer lugar, provavelmente estará vulnerável.

• Saída dinâmica.As pessoas confiam demais na validação de entradas.Suas chances de eliminar todos os metacaracteres possíveis das entradas do usuário, especialmente no mundo real, onde os metacaracteres são partes necessárias da entrada do usuário, são baixas.Uma abordagem muito melhor é ter um regime consistente de filtragem das saídas do banco de dados e transformá-las em entidades HTML, como quot, gt e lt.Rails fará isso automaticamente para você.

• E-mail.Muitos aplicativos implementam algum tipo de recurso de e-mail de saída que permite a um invasor criar uma conta anônima ou não usar nenhuma conta para enviar e-mails controlados pelo invasor para endereços de e-mail arbitrários.

Além desses recursos, o erro número 1 que você provavelmente cometerá em seu aplicativo é expor um ID de linha do banco de dados em algum lugar, para que o usuário X possa ver os dados do usuário Y simplesmente alterando um número de "5" para "6".

Answer 5

bool UserCredentialsOK(User user)
{

    if (user.Name == "modesty")
        return false;
    else
        // perform other checks
}   

Answer 6

ATAQUES DE INJEÇÃO SQL.Eles são fáceis de evitar, mas muito comuns.

NUNCA, NUNCA (já mencionei "nunca"?) Confie nas informações do usuário passadas a você a partir de elementos do formulário.Se seus dados não forem verificados antes de serem passados ​​para outras camadas lógicas do seu aplicativo, você também pode dar as chaves do seu site a um estranho na rua.

Você não menciona em qual plataforma está, mas se estiver no ASP.NET, comece com o bom e velho Scott Guthrie e seu artigo "Dica/truque:Proteja-se contra ataques de injeção de SQL".

Depois disso, você precisa considerar que tipo de dados você permitirá que os usuários enviem para dentro e, eventualmente, para fora do seu banco de dados.Se você permitir que o HTML seja inserido e posteriormente apresentado, você estará totalmente aberto a ataques de Cross Site Scripting (conhecidos como XSS).

Esses são os dois que me vêm à mente, mas nosso Jeff Atwood tinha um bom artigo em Codificação de terror com uma resenha do livro "19 pecados capitais da segurança de software".

Answer 7

A maioria das pessoas aqui mencionou SQL Injection e XSS, que é tipo de correto, mas não se engane - as coisas mais importantes com as quais você precisa se preocupar como desenvolvedor web é a VALIDAÇÃO DE ENTRADA, que é de onde vêm o XSS e o SQL Injection.

Por exemplo, se você tiver um campo de formulário que só aceitará números inteiros, certifique-se de implementar algo tanto no lado do cliente quanto no lado do servidor para limpar os dados.

Verifique e verifique todos os dados de entrada, especialmente se eles terminarem em uma consulta SQL.Sugiro construir uma função de escape e envolvê-la em qualquer coisa que entre em uma consulta.Por exemplo:

$query = "SELECT field1, field2 FROM table1 WHERE field1 = '" . myescapefunc($userinput) . "'";

Da mesma forma, se você for exibir qualquer informação inserida pelo usuário em uma página da web, certifique-se de ter removido todas as tags <script> ou qualquer outra coisa que possa resultar na execução de Javascript (como onLoad= onMouseOver= etc.atributos em tags).

Answer 8

Esta também é uma breve apresentação sobre segurança feita por um dos principais desenvolvedores do wordpress.

Segurança no wordpress

cobre todos os problemas básicos de segurança em aplicativos da web.

Answer 9

Os mais comuns são provavelmente ataques de injeção de banco de dados e ataques de script entre sites;principalmente porque esses são os mais fáceis de realizar (provavelmente porque são os que os programadores têm mais preguiça).

Answer 10

Você pode ver até mesmo neste site que as coisas mais prejudiciais que você cuidará envolvem injeção de código em seu aplicativo, portanto, XSS (Cross Site Scripting) e injeção de SQL (@Patrick's Suggestions) são suas maiores preocupações.Basicamente, você vai querer ter certeza de que, se seu aplicativo permitir que um usuário injete qualquer código, ele será regulamentado e testado para ter certeza de que apenas as coisas que você tem certeza de que deseja permitir (um link HTML, imagem, etc.) ) são passados ​​e nada mais é executado.

Answer 11

Injeção SQL.Scripting entre sites.

Answer 12

O uso de procedimentos armazenados e/ou consultas parametrizadas ajudará bastante na proteção contra injeção de SQL.Faça também NÃO faça com que seu aplicativo da web acesse o banco de dados como sa ou dbo - configure uma conta de usuário padrão e defina as permissões.

AS para XSS (cross site scripting) ASP.NET possui algumas proteções integradas.A melhor coisa é filtrar a entrada usando controles de validação e Regex.

Answer 13

Não sou especialista, mas pelo que aprendi até agora a regra de ouro é não confiar em nenhum dado do usuário (GET, POST, COOKIE).Tipos de ataques comuns e como se salvar:

1. Ataque de injeção SQL:Use consultas preparadas
2. Script entre sites:Não envie dados do usuário ao navegador sem filtrar/escapar primeiro.Isso também inclui dados do usuário armazenados no banco de dados, que vieram originalmente dos usuários.