10 exemplos de segurança essenciais

Pode parecer óbvio, mas garantindo-lhe manter todos os softwares atualizados é vital para manter seu site seguro. Isso se aplica tanto sistema operacional do servidor ou a qualquer software que pode ser executado em seu site como um CMS ou fórum. Quando as falhas de segurança são encontradas em software, os hackers são rápidos para tentar abusar deles.

Se você estiver usando uma solução de hospedagem gerenciada, então você não precisa se preocupar muito sobre a aplicação de atualizações de segurança para o sistema operacional, pois a empresa de hospedagem deve tomar cuidado com isso.

Se você estiver usando software de terceiros em seu site como um CMS ou fórum, você deve garantir que você é rápido para aplicar os patches de segurança. A maioria dos fornecedores tem uma lista de discussão ou RSS feed detalhando os problemas de segurança. WordPress, Umbraco e muitos outros CMS notificá-lo sobre atualizações de sistema disponíveis quando você fizer login.

2. Injeção de SQL

Ataques de injeção de SQL são quando um invasor usa um campo de formulário web ou parâmetro URL para ter acesso ao seu banco de dados. Quando você usa Transact SQL padrão é fácil, sem saber, insira o código não autorizado em sua consulta que pode ser usado para alterar tabelas, obter informações e excluir dados. Você pode evitar isso facilmente sempre usando consultas parametrizadas, a maioria das linguagens web tem esse recurso e é fácil de programar.

Considere esta consulta:

• “SELECT * FROM table WHERE column = ‘” + parameter + “‘;”
Se um atacante mudou o parâmetro de URL para passar no ‘ou ‘1’ = ‘1’ isso fará com que a consulta fique como esta:

• “SELECT * FROM table WHERE column = ” OR ‘1’=’1′;”
Desde ‘1’ é igual a ‘1’ isto iria permitir que o invasor pudesse adicionar uma consulta adicional para o final da instrução SQL que também será executada.

3. XSS

Cross Site Scripting é quando um atacante tenta passar em Java Script ou código de script em um formulário web para tentar executar o código malicioso para os visitantes de seu site. Ao criar um formulário sempre garanta que você verificou os dados que estão sendo apresentados.

4. As mensagens de erro

Tenha cuidado com a quantidade de informação que você se transmite de suas mensagens de erro. Por exemplo, se você tem um formulário de login em seu site, você deve pensar sobre a linguagem que você usa para se comunicar, falha ao tentar logins. Você deve usar mensagens genéricas como “nome de usuário ou senha incorreta”, como não especificar quando um usuário tem metade do direito de consulta. Se um atacante tenta um ataque de força bruta para obter um nome de usuário e senha e dá a mensagem de erro de distância quando uns dos campos estão corretos, então o atacante sabe que tem um dos campos e pode concentrar-se em outro campo.

5. Servidor formulário de validação

A validação deve sempre ser feita tanto no browser quanto no servidor. O navegador pode pegar falhas simples, como campos obrigatórios que estão vazios e quando você coloca em um texto apenas números de campo. Estes podem, contudo, ser ignorados, e você deve ter certeza de verificar essas validações de um lado mais profundo do servidor de validação como não fazê-lo pode levar a um código malicioso ou código de script a ser inserido no banco de dados ou poderão levar a resultados indesejáveis em seu site.

6. Senhas

Todo mundo sabe que devem usar senhas complexas, mas isso não significa que sempre fazem. É fundamental usar senhas fortes para o servidor e área administrativa do site, mas também igualmente importante insistir sobre as práticas de boa senha para seus usuários para proteger a segurança de suas contas.

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

Passwords devem sempre ser armazenadas como valores codificados, utilizando de preferência um algoritmo de hashing maneira como SHA. Usando este método significa que quando você estiver autenticando usuários você está apenas comparando valores criptografados. Para maior segurança, é uma boa ideia para salgar as senhas, usando um novo sal por senha.

No caso de alguém invadir e roubar suas senhas, usando senhas hash poderia ajudar a limitar os danos, como descriptografar as senhas não é possível. O melhor que alguém pode fazer é um ataque de dicionário ou força bruta de ataque, essencialmente adivinhando cada combinação até encontrar uma partida. Ao usar senhas salgadas o processo de craqueamento ou um grande número de senhas é ainda mais lento a cada palpite, tem que ser hash separadamente para cada sal + senha que é computacionalmente muito caro.

Felizmente, muitos CMSes fornecem gerenciamento de usuários fora da caixa com um monte desses recursos de segurança integrada, embora alguns módulos extras de configuração ou podem ser obrigado a usar senhas salgados (pré Drupal 7) ou para definir a força mínima da senha. Se você está usando .NET, então vale a pena usar provedores de associação, como eles são muito configurável, proporcionam segurança embutida e incluem controles prontos para login e redefinição de senha.

7. Upload de arquivos

Permitindo aos usuários fazer upload de arquivos para o seu site pode ser um grande risco de segurança, mesmo que seja simplesmente para mudar o seu avatar. O risco é que qualquer arquivo enviado por mais inocente que possa parecer, pode conter um script que, quando executado em seu servidor abre seu site completamente.

Se você tem um arquivo de formulário de upload, então você precisa tratar todos os arquivos com grande suspeita. Se você está permitindo que usuários façam upload de imagens, você não pode confiar na extensão do arquivo ou o tipo MIME (Multipurpose Internet Mail Extensions) para verificar se o arquivo é uma imagem como estes podem ser facilmente falsificado. Mesmo abrindo o arquivo e ler o cabeçalho, ou utilizar funções para verificar o tamanho da imagem não são a prova completa. A maioria dos formatos de imagens permite armazenar uma secção de comentários que podem conter um código PHP que pode ser executado pelo servidor.

Então, o que você pode fazer para evitar isso? Finalmente você quer impedir que os usuários sejam capazes de executar qualquer arquivo que carregar. Por servidores web padrão não tentaram executar arquivos com extensões de imagem, mas não é recomendado para confiar unicamente em verificar a extensão do arquivo como um arquivo com o nome image.jpg.php tem sido conhecida a passar.

Algumas opções são para renomear o arquivo no upload para garantir a extensão de arquivo correta, ou para alterar as permissões do arquivo, por exemplo, chmod 0666 de modo que não pode ser executado. Se usar *nix você pode criar uma. Htaccess. (veja abaixo) que só vai permitir o acesso para definir arquivos que impedem o ataque de extensão dupla mencionado anteriormente.

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

Em última análise, a solução recomendada é para impedir o acesso direto aos arquivos enviados todos juntos. Desta forma, todos os arquivos enviados para o seu site são armazenadas em uma pasta fora do webroot ou no banco de dados como uma bolha. Se os seus arquivos não são acessíveis diretamente você terá que criar um script para buscar os arquivos da pasta particular (ou um manipulador HTTP no .NET) e entregá-los para o navegador. Tags de imagem apoiar um atributo src que não é um URL direto para uma imagem, para que o seu atributo src pode apontar para o roteiro de entrega de arquivo contanto que defina o tipo correto de conteúdo 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);
•
• ?>

8. Segurança do servidor

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

Verifique se você tem uma configuração de firewall, e estão a bloquear todas as portas não essenciais. Se possível criar uma DMZ (zona desmilitarizada), apenas permitindo o acesso à porta 80 e 443 do mundo exterior. Embora isto possa não ser possível se você não tem acesso ao seu servidor a partir de uma rede interna, como seria necessário para abrir portas para permitir o upload de arquivos e acessar remotamente no servidor através de SSH ou RDP.

Se você está permitindo que arquivos sejam enviados a partir da Internet só usando métodos de transporte seguras para o seu servidor, tais como SFTP ou SSH.

Se possível ter seu banco de dados rodando em um servidor diferente do seu servidor web. Fazer isso significa que o servidor de banco de dados não podem ser acessados diretamente do mundo exterior, apenas o seu servidor web pode acessá-lo, minimizando o risco de os seus dados serem expostos.

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

9. SSL

SSL é um protocolo utilizado para garantir a segurança através da Internet. É uma boa ideia usar um certificado de segurança sempre que você está passando informações pessoais entre o site e o servidor web ou banco de dados. Os atacantes poderiam farejar por esta informação e se o meio de comunicação não é seguro poderia capturá-lo e usar esta informação para obter acesso a contas de usuários e dados pessoais.

10. Ferramentas de segurança

Uma vez que você acha que tem feito todo o possível para proteger o seu site, então é hora de testar a sua segurança. A maneira mais eficaz de fazer isso é através do uso de algumas ferramentas de segurança, muitas vezes referida como teste de penetração ou de teste da caneta para breve.

Há muitos produtos comerciais e livres para ajudá-lo com isso. Eles funcionam de forma semelhante aos scripts hackers usará em que eles testam todos sabemos façanhas e tentativa de comprometer o seu site usando alguns dos métodos anteriores mencionados, tais como injeção de SQL.

Algumas ferramentas gratuitas que valem a pena olhar:

• Nets Parker (Community Edition gratuita e versão de teste disponível). Bom para testar injeção de SQL e XSS
• 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. Mas pode ser difícil de configurar e requer um servidor OpenVAS para ser instalado, que só funciona em *nix. OpenVAS é forquilha de um Nessus antes de se tornar um produto de código fechado comercial.

Os resultados de testes automatizados pode ser assustador, uma vez que apresentam uma riqueza de problemas potenciais. O importante é se concentrar nas questões críticas em primeiro lugar. Cada problema relatado normalmente vem com uma boa explicação da vulnerabilidade potencial. Você provavelmente vai achar que algumas das questões de médio / baixo não são umas preocupações para o seu site.

Se você deseja levar as coisas um passo adiante, então há mais alguns passos que você pode tomar para tentar comprometer manualmente seu site, alterando POST / GET valores. 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. A aplicação freeware popular chamada Fiddler é um bom ponto de partida.

Então, o que você deve estar tentando alterar a pedido? Se você tem páginas que só deve ser visível para um usuário conectado. Então gostaria de tentar mudar parâmetros de URL, como a identificação do usuário, ou valores de cookie na tentativa de ver os detalhes de outro usuário. Outra área que vale a pena testar são formas, mudando os valores POST para tentar enviar o código para executar XSS ou fazer upload de um script do lado do servidor.

Esperamos que estas dicas possam ajudar a manter o site e informações de segurança. Felizmente a maioria dos CMS tem um monte de recursos de segurança embutido, mas é ainda uma boa ideia de ter conhecimento das falhas de segurança mais comuns que você pode garantir que você está coberto.

Há também alguns módulos úteis disponíveis para CMS para verificar sua instalação para falhas de segurança comuns, tais como Security Review para Drupal e WP Security Scan para WordPress.