Segurança da Informação – 9 dicas de segurança para proteger seu site contra hackers

Segurança da Informação – A Internet é um lugar assustador. Notícias sobre violações de dados se tornaram que cotidianas em uma escala sem precedentes. Diariamente milhões de Reais são perdidos por problemas com perda de dados.

Você pode achar que seu site não tem nada que valha a pena ser invadido, mas os sites ficam comprometidos o tempo todo. A maioria das violações de segurança em um site não é para roubar seus dados ou mexer com o layout do site, mas tenta usar seu servidor como retransmissão de spam por e-mail ou para configurar um servidor web temporário, normalmente para servir arquivos de natureza ilegal.

Outras maneiras muito comuns de abusar de máquinas comprometidas incluem usar seus servidores como parte de uma botnet ou minerar para Bitcoins. Você pode até ser atingido por um ransomware.

O hacking é realizado regularmente por scripts automatizados escritos para vasculhar a Internet em uma tentativa de explorar problemas de segurança de sites conhecidos no software. Estas são as nove principais dicas para ajudar a manter você e seu site on-line e seguros.

1 – Mantenha o seu site atualizado

Pode parecer óbvio, mas garantir que você mantenha todos os softwares atualizados é vital para manter seu site seguro. Isso se aplica tanto ao sistema operacional do servidor quanto a qualquer software que você esteja executando em seu site, como um CMS ou fórum. Quando as falhas de segurança do site são encontradas no software, os hackers são rápidos em tentar abusar delas.

Se você estiver usando uma solução de hospedagem gerenciada, não precisará se preocupar tanto com a aplicação de atualizações de segurança para o sistema operacional, pois a empresa de hospedagem deve cuidar disso.

Se você estiver usando software de terceiros em seu site, como um CMS (ex: WordPress) ou um fórum (ex: PHPBB), verifique se é rápido para aplicar quaisquer patches de segurança. A maioria dos fornecedores tem uma lista de discussão ou um feed RSS detalhando todos os problemas de segurança do site. O WordPress , o Umbraco e muitos outros CMSs o notificam sobre as atualizações do sistema disponíveis quando você efetua o login.

Muitos desenvolvedores usam ferramentas como Composer, npm ou RubyGems para gerenciar suas dependências de software, e as vulnerabilidades de segurança que aparecem em um pacote do qual você depende, mas não presta atenção, são uma das maneiras mais fáceis de ser pego. Certifique-se de manter suas dependências atualizadas e use ferramentas como o Gemnasium para receber notificações automáticas quando uma vulnerabilidade for anunciada em um dos seus componentes.

2 – Cuidado com a injeção SQL

Os ataques de injeção de SQL ocorrem quando um invasor usa um campo de formulário da Web ou um parâmetro de URL para obter acesso ou manipular seu banco de dados.

Quando você usa o Transact SQL padrão, é fácil inserir código não autorizado na sua consulta, que pode ser usado para alterar tabelas, obter informações e excluir dados. Você pode facilmente evitar isso usando sempre consultas parametrizadas, a maioria dos idiomas da Web tem esse recurso e é fácil de implementar.

Considere esta consulta:

"SELECT * FROM table WHERE column = '" + parameter + "';"

Se um invasor alterou o parâmetro de URL para passar em ‘ou’ 1 ‘=’ 1, isso fará com que a consulta fique assim:

"SELECT * FROM table WHERE column = '' OR '1'='1';"

Como ‘1’ é igual a ‘1’, isso permitirá que o invasor adicione uma consulta adicional ao final da instrução SQL, a qual também será executada. Você poderia corrigir essa consulta, parametrizando-a explicitamente.

Por exemplo, se você estiver usando o My-SQLi no PHP, isso deve ser:

$stmt = $pdo->prepare('SELECT * FROM table WHERE column = :value');
$stmt->execute(array('value' => $parameter));

3 – Proteja contra ataques XSS

Os ataques de script entre sites (XSS) injetam JavaScript mal-intencionado em suas páginas, que são executadas nos navegadores de seus usuários e podem alterar o conteúdo da página ou roubar informações para serem enviadas de volta ao invasor.

Por exemplo, se você mostrar comentários em uma página sem validação, um invasor poderá enviar comentários contendo tags de script e JavaScript, que poderão ser executados no navegador de todos os outros usuários e roubar seu cookie de login, permitindo que o ataque assuma o controle da conta de cada usuário que visualizou o comentário. Você precisa garantir que os usuários não possam injetar conteúdo JavaScript ativo em suas páginas.

Essa é uma preocupação particular em aplicativos da Web modernos, em que as páginas agora são construídas principalmente a partir do conteúdo do usuário e, em muitos casos, geram HTML, que também é interpretado por estruturas front-end, como Angular e Ember. Essas estruturas fornecem muitas proteções XSS, mas misturar a renderização de servidor e cliente cria novos e mais complicados caminhos de ataque: não apenas injetar JavaScript no HTML efetivo, mas você também pode injetar conteúdo que executará código inserindo diretivas Angulares ou usando Ember ajudantes.

A chave aqui é focar em como o conteúdo gerado pelo usuário pode escapar dos limites esperados e ser interpretado pelo navegador como algo diferente do que você pretendia.

Isso é semelhante à defesa contra injeção de SQL. Ao gerar dinamicamente HTML, use funções que explicitamente façam as alterações que você está procurando (por exemplo, use element.setAttribute e element.textContent, que será automaticamente ignorado pelo navegador, em vez de configurar element.innerHTML manualmente) ou usar funções na sua ferramenta de modelagem que automaticamente faz o escape apropriado, em vez de concatenar strings ou configurar conteúdo HTML bruto.

Outra ferramenta poderosa na caixa de ferramentas do defensor XSS é a Política de Segurança de Conteúdo (CSP). O CSP é um cabeçalho que seu servidor pode retornar, que informa ao navegador para limitar como e qual JavaScript é executado na página, por exemplo, para impedir a execução de quaisquer scripts não hospedados em seu domínio, proibir JavaScript in-line ou desativar eval (). A Mozilla tem um excelente guia com algumas configurações de exemplo. Isso dificulta o trabalho dos scripts de um invasor, mesmo que eles possam colocá-los na sua página.

4 – Cuidado com as mensagens de erro

Tenha cuidado com a quantidade de informação que você der em suas mensagens de erro.

Forneça apenas erros mínimos aos seus usuários, para garantir que eles não vazem segredos presentes em seu servidor (por exemplo, chaves de API ou senhas de banco de dados). Não forneça detalhes completos de exceção, pois eles podem tornar os ataques complexos, como a injeção de SQL, muito mais fáceis. Mantenha erros detalhados nos registros do servidor e mostre aos usuários apenas as informações de que precisam.

5 – Valide dos dois lados

A validação deve ser sempre feita tanto no navegador quanto no lado do servidor. O navegador pode detectar falhas simples, como campos obrigatórios que estão vazios e quando você insere texto em um campo somente de números. No entanto, elas podem ser ignoradas, e você deve verificar essa validação e o servidor de validação mais profundo, pois se isso não for feito, o código malicioso ou o código de script poderão ser inseridos no banco de dados ou causar resultados indesejados em seu site.

6 – Verifique suas senhas

Todos sabem que devem usar senhas complexas, mas isso não significa que sempre façam isso. É crucial usar senhas fortes para o servidor e a área de administração do site, mas também é importante insistir em boas práticas de senha para que os usuários protejam a segurança de suas contas.

Por mais que os usuários não gostem, impor requisitos de senha como um mínimo de cerca de oito caracteres, incluindo uma letra maiúscula e um número, ajudará a proteger suas informações em longo prazo.

As senhas devem sempre ser armazenadas como valores criptografados, de preferência usando um algoritmo de hashing unidirecional como o SHA. Usar esse método significa que, ao autenticar usuários, você está sempre comparando valores criptografados.

No caso de alguém invadir e roubar suas senhas, o uso de senhas com hash pode ajudar a limitar os danos, pois não é possível descriptografá-las. O melhor que alguém pode fazer é um ataque de dicionário ou ataque de força bruta, essencialmente adivinhando todas as combinações até encontrar uma correspondência.

Felizmente, muitos CMSs fornecem gerenciamento de usuário de fábrica com muitos desses recursos de segurança incorporados. Se você estiver usando o .NET, vale a pena usar os provedores de associação, pois eles são muito configuráveis, fornecem segurança de site embutida e incluem controles prontos para login e redefinição de senha.

7 – Evite uploads de arquivos

Permitir que os usuários façam upload de arquivos para o seu site pode representar um grande risco à segurança do site, mesmo que seja simplesmente para alterar o avatar. O risco é que qualquer arquivo enviado, por mais inocente que possa parecer, possa conter um script que, quando executado em seu servidor, abra completamente o seu site.

Se você tiver um formulário de upload de arquivo, precisará tratar todos os arquivos com grande desconfiança. Se você estiver permitindo que os usuários façam upload de imagens, você não poderá confiar na extensão do arquivo ou no tipo MIME para verificar se o arquivo é uma imagem, pois eles podem ser falsificados facilmente. Mesmo abrir o arquivo e ler o cabeçalho, ou usar funções para verificar o tamanho da imagem, não é infalível. A maioria dos formatos de imagens permite armazenar uma seção de comentários que pode conter código PHP que pode ser executado pelo servidor.

Então, o que você pode fazer para evitar isso? Por fim, você deseja impedir que os usuários executem qualquer arquivo que eles enviem. Por padrão, os servidores da Web não tentam executar arquivos com extensões de imagem, mas não dependem apenas da verificação da extensão do arquivo, pois um arquivo com o nome image.jpg.php é conhecido por passar.

Algumas opções são renomear o arquivo no upload para garantir a extensão correta do arquivo ou alterar as permissões do arquivo, por exemplo, chmod 0666, para que ele não possa ser executado. Se estiver usando * nix, você pode criar um arquivo .htaccess (veja abaixo) que permitirá apenas o acesso a arquivos definidos, evitando o ataque de extensão dupla mencionado anteriormente.

deny from all
    <Files ~ "^\w+\.(gif|jpe?g|png)$">
    order deny,allow
    allow from all
    </Files>

Por fim, a solução recomendada é impedir o acesso direto aos arquivos enviados por completo. Dessa forma, todos os arquivos enviados para o seu site são armazenados em uma pasta fora do webroot ou no banco de dados como um blob.

Se os seus arquivos não estiverem diretamente acessíveis, você precisará criar um script para buscar os arquivos da pasta privada (ou um manipulador HTTP no .NET) e entregá-los ao navegador. As tags de imagem suportam um atributo src que não é uma URL direta para uma imagem, portanto, seu atributo src pode apontar para o script de entrega de arquivo, fornecendo o tipo de conteúdo correto no cabeçalho HTTP. Por exemplo:

<img src="/imageDelivery.php?id=1234" />
<?php
      // imageDelivery.php
      // Fetch image filename from database based on $_GET["id"]
      // Deliver image to browser
       Header('Content-Type: image/gif');
      readfile('images/'.$fileName);  
?>

A maioria dos provedores de hospedagem lida com a configuração do servidor para você, mas se você estiver hospedando seu site em seu próprio servidor, então há poucas coisas que você vai querer verificar.

Verifique se você tem uma configuração de firewall e se está bloqueando todas as portas não essenciais. Se possível, configurar uma DMZ (zona desmilitarizada) apenas permitindo o acesso às portas 80 e 443 do mundo exterior. Embora isso possa não ser possível se você não tiver acesso ao seu servidor a partir de uma rede interna, será necessário abrir portas para permitir o upload de arquivos e efetuar login remotamente em seu servidor por meio de SSH ou RDP.

Se você estiver permitindo que os arquivos sejam carregados da Internet, use apenas métodos de transporte seguros para o servidor, como SFTP ou SSH.

Se possível, seu banco de dados está sendo executado em um servidor diferente daquele do seu servidor web. Isso significa que o servidor de banco de dados não pode ser acessado diretamente do mundo externo, apenas o seu servidor da Web pode acessá-lo, minimizando o risco de seus dados serem expostos.

Por fim, não se esqueça de restringir o acesso físico ao seu servidor.

8 – Use HTTPS

O HTTPS é um protocolo usado para fornecer segurança pela Internet. O HTTPS garante que os usuários estão conversando com o servidor que eles esperam e que ninguém mais pode interceptar ou alterar o conteúdo que está vendo em trânsito.

Se você tiver algo que seus usuários possam querer ser privado, é altamente recomendável usar somente HTTPS para entregá-lo. Isso, claro, significa cartão de crédito e páginas de login (e os URLs que eles enviam), mas normalmente muito mais do seu site também.

Um formulário de login geralmente define um cookie, por exemplo, que é enviado com todas as outras solicitações para o site que um usuário conectado faz e é usado para autenticar essas solicitações. Um atacante roubando isso seria capaz de imitar perfeitamente um usuário e assumir sua sessão de login. Para derrotar esse tipo de ataque, você quase sempre quer usar HTTPS para todo o site.

Isso não é mais tão complicado ou caro como já foi. Vamos criptografar fornece certificados totalmente gratuitos e automatizados, que você precisa para ativar o HTTPS, e existem ferramentas comunitárias disponíveis para uma ampla gama de plataformas e estruturas comuns para configurar isso automaticamente para você.

Notavelmente, o Google anunciou que eles irão impulsioná-lo nos rankings de busca, se você usar HTTPS, o que também traz benefícios SEO. HTTP inseguro está a caminho, e agora é a hora de atualizar.

Já usa HTTPS em todos os lugares? Vá além e veja a configuração do HSTS (HTTP Strict Transport Security), um cabeçalho fácil que você pode adicionar às respostas do seu servidor para não permitir HTTP inseguro em todo o seu domínio.

9 – Obtenha ferramentas de segurança para sites

Depois de pensar que você fez tudo o que pode, é hora de testar a segurança do seu site. A maneira mais eficaz de fazer isso é através do uso de algumas ferramentas de segurança do site, muitas vezes referidas como teste de penetração ou teste de caneta para breve.

Existem muitos produtos comerciais e gratuitos para ajudá-lo com isso. Eles trabalham de maneira semelhante aos scripts hackers, pois testam todos os exploits e tentam comprometer seu site usando alguns dos métodos mencionados anteriormente, como SQL Injection.

Algumas ferramentas gratuitas que valem a pena serem vistas:

• Netsparker (edição comunitária gratuita e versão de teste disponível) é uma boa ferramenta para testar injeção de SQL e XSS.
• O OpenVAS afirma ser o mais avançado scanner de segurança de código aberto. Bom para testar vulnerabilidades conhecidas, atualmente verifica mais de 25.000 vulnerabilidades. Mas pode ser difícil configurar e requer que um servidor OpenVAS seja instalado, o qual só roda em *.nix. O OpenVAS é um fork do Nessus antes de se tornar um produto comercial de código fechado.
• SecurityHeaders.io é uma ferramenta para informar rapidamente quais cabeçalhos de segurança mencionados acima (como CSP e HSTS) um domínio habilitou e configurou corretamente.
• Xenotix XSS Exploit Framework é uma ferramenta do OWASP (Open Web Application Security Project) que inclui uma grande variedade de exemplos de ataques XSS, que você pode executar para confirmar rapidamente se as entradas do seu site são vulneráveis no Chrome, Firefox e IE.

Os resultados de testes automatizados podem ser assustadores, pois apresentam uma série de possíveis problemas. O importante é se concentrar nas questões críticas primeiro. Cada questão relatada normalmente vem com uma boa explicação da vulnerabilidade potencial.

Você provavelmente descobrirá que alguns dos problemas médios / baixos não são uma preocupação para o seu site.

Existem algumas outras etapas que você pode seguir para tentar comprometer manualmente seu site alterando os valores POST / GET. Um proxy de depuração pode ajudá-lo aqui, pois permite interceptar os valores de uma solicitação HTTP entre o navegador e o servidor. Um popular aplicativo freeware chamado Fiddler é um bom ponto de partida.

Então, o que você deve estar tentando alterar no pedido? Se você tiver páginas que só devem estar visíveis para um usuário conectado, tente alterar os parâmetros de URL, como ID de usuário ou valores de cookie, na tentativa de visualizar detalhes de outro usuário. Outra área que vale a pena testar são formulários, alterando os valores POST para tentar enviar o código para executar o XSS ou fazer o upload de um script do lado do servidor.

Tem algo a dizer sobre este artigo? Comente abaixo ou compartilhe conosco no Facebook, Twitter ou no nosso LinkedIn.

Leia também:

• Segurança da Informação – Como manter um site WordPress seguro.
• Segurança da Informação – Fiquem atentos as recomendações de segurança para hospedagem de sites.
• Segurança da Informação – Proteja o seu site WordPress de ataques virtuais.
• Segurança da Informação – O que é phishing?
• Proteção de E-mails: um guia para manter sua caixa de e-mails segura.