Há um tempo atrás uma aplicação a qual eu era um dos mantedores estava hospedada em um servidor estrangeiro, que por conta de situações desconhecidas veio ter alguns problemas em seu hardware, de modo que a empresa que nos prestava o serviço configurou um novo servidor e colocou o os arquivos do sistema, retirado de seu backup, nesse novo servidor, e com isso surgiram diversos problemas de compatibilidade com funções, devido ao versionamento do PHP e inclusive de bibliotecas e codificação, de modo que fui obrigado a encarar o problema e buscar uma solução. A coisa mais rápida e errada (eu não sabia disso) para solucionar o problema era alterar a codificação dos dados exibidos – que estavam aparecendo com vários “�” no lugar dos acentos – usando funções como utf8_encode(), utf8_decode(), e mb_convert_encoding(). Desse modo o problema foi solucionado em um primeiro momento, mas no decorrer dos tempos a empresa continuava a fazer alterações no servidor e o problema tornava a aparecer, isso aconteceu umas três vezes dentro de um ano, de modo que me motivei à buscar uma solução definitiva para o problema.

Comecei a buscar problemas parecidos em fóruns como stackoverflow e afins, comecei à vasculhar as configurações dos servidores, os php.ini, e arquivos do apache, bem como as configurações de charset dos bancos de dados vinculados à aplicação e achei o meu grande vilão que se ocultou por extenso, para alguns, período de tempo. O que deveria ser alterado e fixado era o arquivo de configuração do PHP que dizia respeito à aplicação que eu era responsável pela manutenção, algo totalmente pífio, mas por alguma razão – que alguns chamam de burrice – eu não havia pensado nisso antes, durante todo o decorrer de um ano.

Existem algumas propriedades de configuração do PHP que são responsáveis por ditar como o sistema irá tratar a codificação dos textos, e se a codificação errada for escolhida – diferente do padrão compatível com o seu país -, os textos irão sair todos problemáticos, retardados. No meu caso, o servidor estava configurado para o padrão japonês, e isso veio de brinde nos próprios pacotes de instalação do VPS em questão que acompanhavam o cPanel. A solução foi alterar as seguintes propriedades do arquivo de configuração do php: default_charset (utf-8), mbstring.http_output (utf-8), mbstring.internal_encoding (utf-8) e mbstring.language (Neutral). Feitas as alterações, basta remover os “ajustes técnicos” feitos sob a codificação e ser feliz para sempre.

Dentre um dos meus conceitos preferidos do submundo da segurança da informação está o de que toda entrada de dados é mal-intencionada até que se prove o contrário. Seguindo esse conceito, em nossas aplicações não iremos estipular quais tipos de dados não podem ser inseridos, mas pelo contrário, deve-se definir uma regra que busca definir que apenas determinados tipos de dados passarão, e tudo que for diferente disso deverá ser barrado por um filtro. E para evitar ataques de Denial Of Service, estando em um ambiente web, devemos ser muito rigorosos ao definir regras para entradas de dado.

Como o ataque do tipo denial of service busca tornar sua aplicação indisponível para os usuários o tipo de erro mais cometido pelos desenvolvedores é não definir um tamanho máximo de caracteres que um usuário pode passar para a aplicação processar, e isso fica pior ainda quando esses dados forem executados no banco de dados através de uma query. Como os bancos de dados naturalmente estipulam um número máximo de conexões, quando inserimos um valor muito grande para o banco de dados processar uma conexão irá ficar aberta por mais tempo, devido à demora de processamento, e se fizermos várias conexões simultâneas do mesmo tipo, podemos atingir o número máximo de conexões ativas do banco de dados e tornar todas as informações armazenadas neste indisponíveis para o usuário.

Portanto, além analisar os tipos de dados, e formatos de informações que podem ser inseridas, devemos também limitar a quantidade de dados que estamos dispostos à permitir aos nossos servidores processarem. Esse é um erro muito recorrente, que encontrei muitas vezes ao longo das minhas experiências com análises de impactos de vulnerabilidades. E geralmente o impacto tem potencial financeiro.

Suco de cevadiss, é um leite divinis, qui tem lupuliz, matis, aguis e fermentis. Interagi no mé, cursus quis, vehicula ac nisi. Aenean vel dui dui. Nullam leo erat, aliquet quis tempus a, posuere ut mi. Ut scelerisque neque et turpis posuere pulvinar pellentesque nibh ullamcorper. Pharetra in mattis molestie, volutpat elementum justo. Aenean ut ante turpis. Pellentesque laoreet mé vel lectus scelerisque interdum cursus velit auctor.

$mussum = new Pessoa();
$mussum->mandaPraDentris(new Dosis());

Lorem ipsum dolor sit amet, consectetur adipiscing elit. Etiam ac mauris lectus, non scelerisque augue. Aenean justo massa.

Casamentiss faiz malandris se pirulitá, Nam liber tempor cum soluta nobis eleifend option congue nihil imperdiet doming id quod mazim placerat facer possim assum. Lorem ipsum dolor sit amet, consectetuer Ispecialista im mé intende tudis nuam golada, vinho, uiski, carirí, rum da jamaikis, só num pode ser mijis. Adipiscing elit, sed diam nonummy nibh euismod tincidunt ut laoreet dolore magna aliquam erat volutpat. Ut wisi enim ad minim veniam, quis nostrud exerci tation ullamcorper suscipit lobortis nisl ut aliquip ex ea commodo consequat.