Todos os dias a gente se depara com inúmeras notícias de que grandes sites e portais, foram alvos de ataques de crackers, na qual informações foram roubadas, dados vazados e até mesmo, a empresa teve que interromper o acesso ao seu conteúdo.

Mesmo com um bom servidor de hospedagem, um time de infraestrutura e um departamento de desenvolvimento, eles não podem garantir a segurança completa, mesmo que sempre façam as análises nos logs e monitoramento de acessos aos seus usuários.

Ter uma aplicação segura é um trabalho árduo que requer bons desenvolvedores, entre outros times especializados. Para esse artigo, vamos nos ater apenas no profissional de desenvolvimento, que no caso são os programadores back-end.

Existem diversas formas de ataques a uma aplicação, como por exemplo, XSS, SQL Injection, Phishing, entre muitos outros.

Durante o desenvolvimento da aplicação, o programador tem que ter a maturidade e o treinamento adequado para tratar toda entrada de dados e nunca confiar no conteúdo que é fornecido pelo usuário. Uma boa prática durante o desenvolvimento, é pensar que toda a informação que o servidor está recebendo do cliente, são instruções de um cracker altamente qualificado, assim podemos pensar como um atacante e por outro lado, fornecer a aplicação das tratativas necessárias.

Ataques XSS

Para ilustrar um exemplo clássico de ataque de XSS, que nada mais é do que a injeção de scripts maliciosos por meio de formulários, vamos presumir que nossa aplicação tenha um campo de depoimento, onde o usuário/cliente que comprou nosso produto pode deixar a sua mensagem, através de um simples componente de Textarea, que deve conter apenas letras, números e poucos caracteres especiais. O usuário com total intenção de burlar a aplicação, insere um código Javascript que redireciona o usuário para um site aleatório.

Dado o problema acima, caso nossa aplicação não remova os caracteres indesejados, sempre que o depoimento for renderizado no HTML, o Javascript será interpretado e vai redirecionar o usuário para outro site. Agora vamos imaginar que nossa página de vendas esteja redirecionando qualquer usuário para um produto da concorrência, assim os demais usuários não vão saber que o site foi alvo de um ataque, mas sim que o proprietário do site está recomendando o produto da concorrência.

Com um simples tratamento nos inputs no back-end, podemos rodar uma instrução com uma expressão regular que remova todos e quaisquer caracteres especiais. Na linguagem de programação PHP, temos o método strip_tags, que ajuda removendo tags da string informada.

Para se prevenir desse tipo de ataque é muito simples, basta que todos os formulários do site sejam revisados e tratados, mas para isso é necessário que os programadores conheçam essa vulnerabilidade. Em alguns casos a gente quer receber tags e algumas marcações HTML, então devemos garantir que os formulários aceitem apenas um número determinado e conhecido de elementos, para que seja persistido na base de dados apenas as entidades HTML e não o código que veio direto do formulário já tratado.

Ataques de SQL Injection

Okay, todas as informações recebidas dos formulários estão tratadas, agora podemos resisti-las no banco de dados, certo? Talvez!

SQL Injection é mais um tipo de ataque na qual o cracker insere instruções de SQL por meio das URLS (que normalmente são a base para a consulta no banco) ou formulários, por exemplo, fazendo com que as consultas sejam alteradas e assim manipulando o que deve ser rodado.

Para a gente entender um pouco mais sobre esse tipo de problema, o cracker pode simplesmente fornecer por meio de uma url um comando de truncate, deletando assim uma tabela com todas as suas informações.

Aqui entra duas áreas que precisam trabalhar em conjunto para prevenir esse tipo de ataque, são elas:

• DBA – deve fornecer um usuário de conexão com o banco de dados com os mínimos privilégios, como inserção, consulta e atualização;

• Programador – deve remover caracteres como aspas, apóstrofos e utilizar bind params.

Na linguagem de programação PHP, temos um módulo chamado de PDO, ele é responsável por fornecer a comunicação com diversos drivers de banco de dados, como MariaDB, MySQL, SQL Server, entre outros. O PDO por sua vez possui um recurso para Param Bind, que trata os dados antes deles serem enviados como uma instrução de SQL.

Uma dica muito importante, é nunca fornecer o conteúdo diretamente na string de SQL, sempre que possível usar o Param Bind com dados já tratados anteriormente.

Um exemplo clássico de falha: “SELECT * FROM tabela WHERE id = {$id}”.

Na instrução acima, veja que estamos inserindo a variável diretamente na string, confiando que o conteúdo seja verdadeiro. É esse tipo de crença que deixa nossa aplicação vulnerável a grandes ataques.

Mensagens de erro não tratadas

Tenha em mente que apenas os profissionais responsáveis pela manutenção do servidor e os programadores, precisam e devem ver os códigos de erros. Muitos sites mostram em detalhes um erro que deveria ser evitado, assim o atacante consegue entender a estrutura do projeto, como qual arquivo foi executado, qual a linha problemática e o pior de tudo, qual é a falha.

Em servidores Apache, por exemplo, é possível desabilitar a exibição de erros, assim o programador poderá utilizar bibliotecas como Monolog para receber essas informações e persisti-las em um arquivo.

Arquivos de Logs não é museu, então devemos consultá-los durante o dia várias vezes. Ainda falando sobre o Monolog, é possível tratar os níveis de erros para que seja disparado e-mails e envio de mensagens para o Telegram, mantendo o time responsável sempre atualizando quando houver falhas críticas.

Permissionamento para usuários FTP

Muitas aplicações utilizam acesso via FTP para fornecer ou baixar conteúdos através da aplicação, até aí, não há problema algum, desde que o acesso seja bem feito.

É necessário sempre criar um usuário e senha para cada situação, permitindo assim um controle maior dos acessos e interrupção do usuário sem afetar os demais serviços. É importante sempre garantir que o usuário tenha acesso apenas ao diretório necessário e não a toda estrutura de diretórios.

Acessos padrão do servidor

Quando contratamos uma hospedagem de sites, por padrão temos um ou mais usuário com acessos globais a banco de dados, servidores FTP, acesso aos painéis administrativos e por aí vai. Devemos bloquear esse usuário ou garantir que apenas um administrador de alta confiança e com muita maturidade possa utilizá-lo.

Cada usuário precisa ter seu nível de acesso controlado bem como o recurso que será acessado.

Indexação de diretórios

Através de uma pesquisa rápida no Google pelo termo intitle “index of” ou “intitle index of .git”, você pode ter uma noção de quantos sites estão vulneráveis. Acontece que os servidores por algum motivo, seja propositalmente ou não, estão configurados para quando um arquivo de índice (index.html, default.htm…) não existir, eles exibam a estrutura dos diretórios e assim, qualquer usuário através do navegador de internet poderá navegar entre eles.

Nos servidores Apache, é possível incluir apenas uma única configuração no arquivo .htaccess para desabilitar essa opção e fornecer mais segurança a estrutura de pastas do servidor. A configuração em questão é: Options -Indexes.

.git com acesso público

.git é um diretório criado pelo sistema de versionamento Git, que na maioria das vezes se passa despercebido, visto que essa pasta é por padrão oculta. O problema é que ao acessar o diretório /.git, temos acesso ao arquivo config, que exibe em alguns casos o usuário e senha de acesso ao repositório remoto de versionamento, além de outras configurações.

Devemos garantir que essa pasta nunca fique acessível e, diretórios públicos, então, para saber se seu site corre esse risco, tente acessar o endereço e adicionar /.git no final da URL, dessa forma: https://meusite.com/.git.

Conclusão

Toda entrada de dados deve ser tratada a fim de enviar apenas informações verdadeiras e autênticas. Em alguns casos precisamos inclusive, saber quais os endereços de IPs que estão fornecendo dados inválidos e maliciosos, assim devemos incluí-los na lista de acesso negado.

Contudo, devemos ter um olhar cuidadoso para todas as informações que são consideradas sensíveis e frágeis. Não basta o programador fazer um bom trabalho quando a equipe de infraestrutura não cuida das informações e acesso aos servidores.