Problemas de segurança com PHP e estruturas web

Vamos direto ao ponto? Tem tanta coisa pra dizer que estou cortando palavras.

1. Command Injection

O Command Injection acontece quando o nosso código recebe comandos no sistema. No PHP temos algumas funções para executar comandos de terminal. E o que você pode fazer no terminal? Tudo! Copiar, deletar, criar e sobrescrever arquivos, além de poder executar outros programas e desligar a maquina ou conectá-la com algum servidor. Continue lendo que você vai entender.

Vamos as funções, vou listar as mais famosas:

• system() é igual a versão C desta função no que executa o command indicado e mostra o resultado.
• exec() executa o command dado. Abre um programa externo.

Vamos a um exemplo super inseguro com o uso de system para você entender.

Aqui o hacker pode usar o servidor a vontade. O comando “dir C:” lista os diretórios de C do Windows, mas ele pode fazer outra coisa também.

E aqui está o resultado, uma lista com todos os diretórios do nosso C.

Ao utilizar essas funções você pode ser pego em um monitoramento via Web Scraping. Os harckers usam web scraping para descobrir quando alguém está usando um desses comandos em seu sistema. E a partir de então, este pode sofrer um ataque.

Mas o que é o Scraping e como ele detecta essas coisas?

Segundo o Wikipédia: O Scrapy é um framework de rastreamento da web de código aberto gratuito, escrito em Python. Originalmente projetado para web scraping, ele também pode ser usado para extrair dados usando APIs ou como um rastreador da web de propósito geral.

O problema é que ele filtra os protocolos trafegados na Web e detecta redes usando funções de sistema. Dessa forma que os harckers se aproximam para fazer a festa, principalmente se você estiver tentando usar isso de forma dinâmica. Não é que você não possa usar, mais é preciso se garantir.

Como se proteger?

Regra número 1: não use de forma dinâmica, com passagem via get ou post;

Regra número 2: se precisar usar em uma necessidade muito grande mesmo, use escapeshellcmd() e/ou escapeshellarg();

Um simples exemplo.

2. SQL Injection

Essa é com certeza a prática mais utilizada pelos hackers em detrimento do descuido ou desconhecimento por parte do desenvolvedor. SQL injection é quando alguém descobre que você está passando os dados diretamente com o SQL e resolve tirar vantagem disso passando argumentos que irão somar junto com os parâmetros utilizados para dentro do banco de dados e isso, comprometerá seus dados. Tentei usar minhas palavras para descrever.

Esse código por exemplo está vulnerável pois os dados estão sendo pegos pelo GET, que está filtrando o id 3. Repare que onde tem a clausula WHERE, o $id por ser número, não está entre aspas e isso só piora a situação, deixa mais fácil ainda. Se eu passar na URL após o 3, OR 1=1 — — , o resto do código ficará exposto e é encontrando essa vunerabilidades que saem notícias do tipo, site X vaza senha dos usuários.

Depois do PHP 7.0 é recomendados a utilização do pdo, ou classes baseadas no pdo, ou na classe MySQLi e fazer o Binding dos parâmetros.

É possível usar o SQL diretamente no código e ainda reter alguma segurança? A resposta é sim e não. Sim, usando verificações, para bloquear a execução dos comandos caso esteja fora de um padrão que você tenha estipulado, usar aspas simples nos dados recebido e o MySQL vai tratar como string, mas, como dito antes, não é recomendado.

3. Permissões de pasta no servidor

Nem toda pasta precisa ser pública. E se tratando de permissões, é bom temer o número 7. No computador as permições de pastas funcionam para 3 grupos de usuários: o dono, os administradores e o público, por isso são representadas por 3 números que variam de 0 a 7.

Vou deixar o link para uma matéria que desmistifica essas permissões: https://blog.sucuri.net/portugues/2015/09/desmistificando-permissoes-de-pastas-e-arquivos.html

O que eu quero passar aqui é que não devemos dar permissão total (777) ou desnecessária para o público geral, resguardando somente para gravação de arquivos em pastas.

A maioria dos arquivos tem a permissão 644 (o dono pode gravar, mas ninguém pode executar). A maioria das pastas deve ter permissões 755 (execução permite abrir as pastas). Alguns arquivos com informação de configuração secreta poderem se beneficiar de restrições adicionais, como 660.

O grande problema pelo qual o Wordpress é vítima de muitos ataques é justamente a instalação de algum plugin mal intensionado que dê permissões 777 em algumas pastas e arquivos. Um hacker mal intencionado vai escanear seu site lendo as permissões e então ele vai sobrescrever algum arquivo usando a função System() e vai ter controle total sobre os diretórios do servidor.

Um exemplo de como criar pastas no PHP com a permissão mais indicada.

4. Arquivos .htacess

O .htacess é um arquivo muito usado para redefinir as rotas de um site interpretadas pelo servidor, você pode remover a leitura da extensão dos arquivos, indicar a pasta defaut para a leitura dos arquivos.

Bem, na verdade ele pode fazer muito mais, pode bloquear acesso a pastas, permitir que um determinado caminho seja acessado somente por um ou mais ips, ocultar arquivos (embora ele esteja anunciando onde está ocultando), enfim, falar sobre .htacess uma tarefa muito árdua e extensa, teria que criar um novo post para falar somente sobre, prefiro compartilhar uma matéria que está muito completa, diga-se de passagem: https://scriptcerto.com.br/blogwordpress/um-guia-completo-para-editar-htaccess-para-seguranca-wordpress/

DICA ÚTIL: Veja se seu servidor aplica alguma regra na utilização de arquivos .htacess. Se eu não me engano a GoDaddy faz uma ressalva, quanto a isso.

5. Uso de captchas para dificultar que robores realizem cadastros em seu sistema

Os captchas são um tipo de teste que desafiam o cognitivo, utilizado como ferramenta anti-spam serve para diferenciar humanos de máquinas, pelo menos até o momento. Não tem muito o que falar sobre ele na verdade. Muitos usuários mal intencionados tentam usar mecanismos para preencher formulários e obter vantagens, realizando cadastros em massa ao seu favor, comprando ingressos como uma máquina para revender mais caro, ou fazendo qualquer outra estripulia.

6. Validações no front-end e no back-end

Se o site der erro na leitura e travar antes de carregar os scripts de validação (isso é comum quando ele está recebendo muito acesso e não tem o devido suporte), então não podemos permitir quem o usuário possa tirar vantagem disso não é mesmo? Por isso não pode ter preguiça, se quiser algo bem feito.

7. Controle do Robots.txt um perigo para sua segurança

Trata-se de um arquivo .txt que os SEOs utilizam para informar aos Crawlers (sites de pesquisas) as permissões de acesso a páginas e diretórios e é neste ponto que mora o perigo do Robots.txt.

Boa parte da internet é insegura por causa desses Robots. Veja algumas recomendações:

• NÃO USE: User-agent: *: qualquer programa pode ler;
• Especifique o agent que pode vasculhar seu site. Aqui temos uma lista dos agentes existentes na Web. Ex.: User-agent: Googlebot; especifico para o google;
• Use disallow, passando o caminho a ser desabilitado da busca: Disallow: /caminho
• Veja o exemplo abaixo:

User-agent: * : informados que qualquer Crawler pode acessar o Robots.txt;
Disallow: /privado : este diretório não deve ser scanneado;
Allow: /privado/excecao : apesar de privado ser proibido, o sub-diretorio “excecao” pode ser scanneado.
Allow: /publico : informa que este diretório pode ser scanneado.

Lembre-se os Spiders viajam através dos links quando descobrem um caminho, por isso é preciso especificar os links que não devem ser seguidos.

Segue exemplo da tag:

<meta Name=”robots” content=”noindex,nofollow”>

No parâmetro content, temos duas informações:

• noindex: opção que solicita para não indexar a página nas pesquisas;
• nofollow: opção que diz para o Crawler dos buscadores não seguir o link.

Também podemos informar em tags de link que o Crawler não deve indexar ele através da propriedade “rel”. Segue exemplo:

<a href="login " rel="nofollow">Efetuar Login</a>

Neste exemplo, informamos que o link “login” não deve seguido. Todas essas configurações podem tomar um tempo maior na hora que criamos nossas aplicações, mas com isso temos um site um pouco mais seguro.

Vale lembrar que essas configurações não irão proteger os nossos arquivos do site, apenas vamos dificultar o trabalho do Cracker. Jamais deixe um arquivo de banco de dados ou qualquer outro com informações confidenciais em um caminho que pode ser acessado através de uma URL.

Finalização

Existem outras técnicas de segurança para sistemas, além de senhas seguras com aplicação de hash, uma delas é a criptografia do código fonte, que evita entre outras coisas, que alguém copie o seu código. E lembre-se, quanto maior o nível de segurança, mais impenetrável seu código se torna. Acredito que tenha incomodado bastante o tamanho que este post ficou, mais foi escrito de coração aberto. Curta, compartilhe, comente o que você achou.