Preto, Branco e as Sombras de Cinza

Preto, Branco e
as Sombras de Cinza:
Filtrando e Validando Strings

CC Attribution-ShareAlike 3.0 Unported License by Er Galvão Abbott – 2010-11-23 – 1 / 16

Objetivo

Esta apresentação tem por objetivo apresentar conceitos e soluções para a
questão de tratamento de strings, o tipo de dado mais complexo que podemos
encontrar ao receber dados em uma aplicação.

Serão apresentados os seguintes tópicos:

● O que é Filtragem
● O que é Validação
● Dados de tipos específicos
● Dados com máscaras pré-definidas
● Opções de abordagens de Validação e Filtragem
● Vantagens e desvantagens de cada abordagem
● Exemplos práticos

Embora teoricamente esta apresentação sirva para linguagens em geral, os exemplos
serão apresentados em PHP.


O que é Filtragem

Filtragem é a transformação de um dado, substituindo, removendo e/ou adicionando
um ou mais caracteres, de forma que:

● O Dado assuma o tipo esperado
● O formato do Dado se torne compatível com a máscara de dados esperada
● O valor do Dado possua apenas caracteres legítimos


O que é Validação

Validação é o processo pelo qual ocorre uma decisão baseada em uma condição. É
o teste feito em cima de um dado recebido, decidindo se o dado é ou não válido, através
de uma ou mais comparações:

● O tipo do Dado é o tipo esperado
● O valor do Dado está entre os valores esperados
● O formato do Dado é compatível com a máscara de dados esperada
● O valor do Dado é coerente


Como proceder

Ambos os processos (Validação e Filtragem) se completam ao tratarmos de um dado
externo à nossa aplicação. O primeiro processo a ser aplicado deve ser o de Filtragem.
Após a transformação do dado devemos então realizar a Validação final.


Abordagens

Existem duas abordagens para seguir no momento de realizar qualquer um dos dois
processos:

● Black List, ou “Lista Negra” : É o processo pelo qual definimos caracteres, substrings
e/ou formatos inválidos para o dado.

Exemplos:

“A aspa simples é um caractere inválido”
“O sinal de maior e o sinal de menor são caracteres inválidos”

● White List, ou “Lista Branca”: É o processo pelo qual definimos caracteres, substrings
e/ou formatos válidos para o dado.

Exemplos:

“Somente letras são considerados caracteres válidos”
“Somente números são considerados caracteres válidos


Black List

A abordagem de Black List é extremamente comum, mas traz problemas que nem
sempre são óbvios. Num primeiro olhar usar Black List parece, sem sombra de dúvida,
a coisa certa a fazer:

+ É aparentemente lógico;
+ Os casos especificados são seguramente tratados;
+ Nível de dificuldade “fácil”

Quando se reflete melhor as coisas começam a se tornar mais claras:

– É comum ignorarmos casos, por engano ou esquecimento;
– É extremamente complexo prevermos todas as formas de representar um caractere;
– Em casos de aplicações que implementem i18n e l10n a complexidade aumenta


Black List

Exemplos clássicos de uso equivocado de Black List:
● htmlentities:
● Não considera caracteres como: / - ! |
● Em certo ponto é preciso fazer o processo inverso, tornando a aplicação igualmente

vulnerável

● addslashes/addcslashes:
● Não considera representações como URL encoded, por exemplo

● preg_replace('/select|insert|update|delete/', '', $str):
● Não considera dezenas de outros comandos como: grant, create, revoke, drop, etc...
● Em textos na língua inglesa impede o uso legítimo dos termos


White List

A abordagem de White List é, via de regra, a coisa certa a se fazer. Ela parece possuir
um grau maior de dificuldade (e às vezes isso até é verdade), mas em contrapartida é em
geral muito mais segura e precisa do que o uso da Black List.

+ É mais fácil definir o que é válido, reduzindo ou eliminando a possibilidade de erros;
+ Apenas os casos especificados são tratados;
+ Independente de representação;
+ Independente de i18n e l10n

A “dificuldade” em se implementar uma abordagem White List é ilusória. Na verdade
o que acontece é que precisamos realizar processos com os quais não estamos
acostumados:

● Conceitualizar o dado
● Definir seu tipo, valor, formato e regra de coerência
● Dedicar tempo ao planejamento


White List

Exemplos comentados de uso de White List

Exemplo #1 – Aceitar apenas números

if (!preg_match('/^d+$/'), $str) {
die('Dado inválido!');
}

Exemplo #2 – Dados numéricos

if (!(int)$str) {
}


White List

Exemplo #3 – Data, no formato dd/mm/aaaa

if (!preg_match('/d{1,2}/d{1,2}/d{4}$/'), $str) {
}

Exemplo #4 – Números de telefone

if (!preg_match('/^(d{2})s*d+-*d+$/'), $str) {
}


Coerência

Alguns dados necessitam ser coerentes, como o exemplo das datas. A coerência é
parte importantíssima do processo de validação. Embora muitas vezes dados incoerentes
não comprometam a segurança da aplicação diretamente não há sentido em armazenar
informações inúteis.

Não esqueça: a aplicação, além de segura, deve ser eficiente!

Alguns exemplos:

Datas de Nascimento:
- Obrigatoriamente no passado
- Obrigatoriamente com um limite máximo
- Opcionalmente com um limite mínimo

Datas de Agendamento:
- Obrigatoriamente no futuro
- Obrigatoriamente com um limite máximo
- Obrigatoriamente com um limite mínimo
- Obrigatoriamente dependentes de disponibilidade


Coerência

Validação coerente de datas? Pura matemática! Com a Unix Timestamp fica simples
de fazer a maioria das verificações do slide anterior. Veja o exemplo:

Exemplo #5 – Data no passado e dentro do limite

$limite = 18 * 3600 * 24 * 365;

$data = mktime(0, 0, 0, $mes, $dia, $ano);

if ((time() - $data) < $limite) {
die('Apenas para maiores!');
}


Nem Black List, “nem White List”

E se não pudermos aplicar nenhum dos dois conceitos? Se eu quiser, por exemplo,
permitir algumas tags HTML em um texto enviado pelo usuário?

Tecnicamente usaremos quase uma abordagem White List para isso, mas é um
exemplo bem mais complexo do que vimos até o momento. Além disso precisamos
identificar, dentro do dado recebido, o que é tag HTML e o que não é.

É justamente nesse ponto que reside a complexidade da situação. Se usarmos uma
rotina flexível demais corremos o risco de “censurar” conteúdo legítimo – por processar
texto comum na informação – ou de deixarmos a aplicação vulnerável.

O método que explicarei aqui é uma sugestão simplificada. Ele está longe, bem longe
da perfeição, inclusive possuindo falhas graves que comentarei aqui.

Se você achar uma solução melhor compartilhe!


Nem Black List, “nem White List”

Exemplo #6 (simplificado e falho) – Encontrando e limitando tags XHTML

$validTags = array('table', 'thead', 'tbody', 'tfoot', 'tr', 'th', td');

preg_match_all('/<[a-z]+/', $str, $foundTags);

foreach ($foundTags[0] as $tag) {
if (!in_array(substr($tag, 1), $validTags)) {
die("Tag invalida: $tag");
}
}

Uma forma mais complexa e mais segura seria a análise caractere-a-caractere. Cada
código numérico de cada caractere seria então comparado ao código numérico do sinal de
menor, seguido de letras e outros caracteres típicos de tags XHTML, seguido por uma
forma de fechamento (barra seguida do nome da tag ou barra seguida do sinal de maior).

O que é realmente importante neste exemplo é a definição da White List (o array
do início).


OBRIGADO!

Sobre o Autor:

Er Galvão Abbott trabalha há mais de 15 anos
desenvolvendo sistemas e aplicações com interface web.
Palestra em eventos, dá cursos em diversas instituições e
faz parte da organização da PHP Conference Brasil e do
Fórum de Software Livre de Curitiba.

Especializou-se em segurança de aplicações web,
abordando o tema em uma época quando isso ainda era raro no
Brasil. Trabalhou com diversas empresas de grande parte, tanto
nacionais como internacionais.

Site: http://www.galvao.eti.br/
Twitter: @galvao
Slides e Documentos: http://slideshare.net/ergalvao


Preto, Branco e as Sombras de Cinza

Recommended

Recommended

More Related Content

Viewers also liked

Viewers also liked (20)

Similar to Preto, Branco e as Sombras de Cinza

Similar to Preto, Branco e as Sombras de Cinza (20)

More from Er Galvão Abbott

More from Er Galvão Abbott (20)

Preto, Branco e as Sombras de Cinza