Artigos Canal Mais Implementando segurança na programação Web
Por que eu devo ler este artigo:Este artigo é útil por abordar as principais e mais recentes formas de ataque que os hackers fazem uso para atingir as aplicações web, tais como XSS, injeção de código, envio de código malicioso via uploads, entre outros. Além disso, entenda quais erros você está cometendo na implementação dos seus códigos front-end, assim como quais técnicas podem nos auxiliar a implantar linhas de defesa na aplicação, de modo a evitar futuras dores de cabeça com roubo de dados, quebra de segurança, falhas na autenticação e muito mais.

Os dados são o recurso mais importante que qualquer empresa possui. É literalmente possível substituir qualquer parte de um negócio, exceto dados. Quando os dados são modificados, corrompidos, roubados ou excluídos, uma empresa pode sofrer graves perdas. O foco da segurança não se refere somente à prevenção contra hackers, aplicações, redes ou qualquer outra coisa que você tenha aprendido na faculdade, mas sim dados. E quando falamos sobre as ameaças que existem no universo de programação, o front-end define a ponte de acesso que as mesmas fazem uso para burlar a segurança da sua aplicação como um todo. Por essa e muitas outras razões é que esse artigo se fará útil para a sua vida como desenvolvedor além de abranger uma ampla gama de outros temas sobre segurança da informação.

Não importa o quão seguro seja o seu o servidor, o quão capaz o seu banco de dados é para guardar os dados, esses não são valiosos até que você faça algo com eles. No entanto, antes de prosseguir, é importante decidirmos exatamente como as aplicações e dados devem interagir, já que é a definição desse fluxo que implica diretamente nas decisões de segurança que devem ser tomadas daqui em diante. Um aplicativo executa apenas quatro operações possíveis sobre os dados, não importa o quão incrivelmente complexa a aplicação possa se tornar. Você pode definir essas operações tomando como base o acrônimo CRUD (Create, Read, Update, Delete). As operações de leitura, escrita, atualização e remoção de dados devem ser feitas sempre pensando em como os dados dos usuários devem ser expostos e que níveis de segurança estamos aptos a implantar para cada uma. Não existe nível mínimo de segurança para cada operação e aquela velha história de que operações de consulta à base precisam de menos requisitos de segurança, pois não alteram os mesmos, está completamente equivocada. É só pensar na situação em que um hacker tenha acesso facilitado às operações de SELECT da base e, mesmo as demais constando de maior segurança, ele pode usar dessa abertura para consultar dados confidenciais das tabelas, ou até mesmo entender como a estrutura de relacionamentos interna foi feita para o seu sistema como um todo. Em vista disso, precisamos nos certificar de adequar o sistema por inteiro aos conceitos que aqui serão apresentados.

Especificando ameaças nas aplicações web

Você pode encontrar listas de ameaças de aplicações web em toda a internet. Algumas das listas são abrangentes e não necessariamente tem um foco só, alguns endereços que o autor cita são as ameaças mais importantes, alguns vão informá-lo sobre que tipos de ameaças ocorrem mais comumente, etc. O problema com todas essas listas é que o autor não conhece a sua aplicação. Um ataque do famoso SQL Injection (Injeção de SQL) só é bem-sucedido quando sua aplicação usa SQL de alguma forma.

Obviamente você precisa obter ideias sobre o que verificar de algum lugar, e essas listas são um bom ponto de partida. No entanto, você precisa considerar o conteúdo da lista tendo em conta sua aplicação. Além disso, não dependa de apenas uma lista, use múltiplas, para você obter uma melhor cobertura das ameaças que possam atacar a sua aplicação. Com essa necessidade em mente, aqui está uma lista das ameaças mais comuns que você vê nas aplicações web de hoje:

  • Buffer overflow - Um invasor consegue enviar dados suficientes em um input buffer (entrada de dados em buffer) para sobrecarregar uma aplicação ou em um output buffer (saída de dados em buffer).Como resultado a memória externa ao buffer fica corrompida. Alguns formatos de buffer permitem ao hacker executar tarefas aparentemente impossíveis de fora da aplicação, porque a memória afetada contém código fonte executável. A melhor maneira de prevenir esse problema é executar verificações de tamanho e de intervalo (range) em todos os dados de entrada e saída que a sua aplicação lida.
  • Code Injection (Injeção de código) - Uma entidade adiciona código para o fluxo de dados fluindo entre um servidor e um cliente (tal como um browser) em modo de man-in-the-middle-attack (modo em que a tal entidade intermedia o ataque se posicionando exatamente entre os dois principais envolvidos no processo de envio/recuperação dos dados: cliente e servidor). O alvo frequentemente visualiza o código adicionado como parte da página original e, naturalmente, o alvo não pode mesmo ver o código injetado. Ele pode estar escondido no plano de fundo pronto para causar todos os tipos de problemas em sua aplicação. Uma boa maneira para prevenir esse ataque é garantir o uso de dados criptografados: o HTTPS, por exemplo, é um protocolo que faz uso de códigos de verificação (quando possível) e exige autenticação de quem solicita os recursos na página web. Fornecer um mecanismo de feedback do cliente também é uma boa ideia, já que ele será sempre o seu maior testador e poderá te dar informações rápidas de falhas na segurança da sua aplicação. A injeção de código ocorre com mais frequência do que você imagina. Em alguns casos, ela nem faz parte de um ataque, mas poderia muito bem fazer. Certifique-se de tomar bastante cuidado com os Internet Service Providers (ISPs) (vide BOX 1), que frequentemente estão injetando código JavaScript ao transmitir dados, a fim de sobrepor anúncios no topo de uma página. Para determinar que tipos de anúncio deve fornecer, o ISP também monitora o tráfico de dados como um todo em páginas que os usam.
  • Cross-site scripting (XSS) - Esse é de longe um dos mais famosos e usados. Um hacker injeta JavaScript ou código executável no fluxo de saída da sua aplicação. O destinatário vê seu aplic ...
    Quer ler esse conteúdo completo? Tenha acesso completo