Devo sanitizar um endereço de e-mail antes de passar para a function is_email ()?

Estou usando is_email() para verificar se um endereço de e-mail fornecido pelo usuário é válido. Por exemplo:

 $email = $_POST['email']; if ( is_email( $email ) ) // Do something. 

No meu melhor conhecimento, nada nesta function escreve informações para o database. Devo estar desinfetando $email antes de passar para a function?

Solutions Collecting From Web of "Devo sanitizar um endereço de e-mail antes de passar para a function is_email ()?"

Olhando para a funcionalidade is_email() no Trac, parece que você não precisa sanatizie, pois é apenas um teste de string. Eu chegaria mesmo a dizer que, se essa function retornar verdadeira, você não precisaria desinfetá-la antes de enviá-la para o database.

WordPress e PHP core

A function is_email() fonte é uma implementação típica do WordPress e não funciona completamente com o que o RFC 6531 permite. Uma razão pode ser, que a constante padrão PHP FILTER_VALIDATE_EMAIL para filter_var() não é muito melhor para validar algo de acordo com as diretrizes da Internet Engineering Task Force (IETF®) .

Padrões

O ponto é que o RFC 6531 permite “Caracteres Unicode além da faixa ASCII” . Ou seja, são (para a parte local – antes do @ ):

  • Letras maiúsculas e minúsculas em inglês (a-z, A-Z) (ASCII: 65-90, 97-122)
  • Dígitos 0 a 9 (ASCII: 48-57)
  • Esses caracteres especiais:! ! # $ % & ' * + - / = ? ^ _ ` { | } ~
  • Caráter . (ponto, período, parada completa) (ASCII: 46) desde que não seja o primeiro ou último caractere, e desde que não apareça consecutivamente (por exemplo, John..Doe@example.com não é permitido).
  • Caracteres especiais são permitidos com restrições. Eles são:
    • Espaço e "(),:;<>@[\] (ASCII: 32, 34, 40, 41, 44, 58, 59, 60, 62, 64, 91-93)
    • As restrições para caracteres especiais são que eles só devem ser usados ​​quando contidos entre aspas, e que 2 deles (a barra invertida \ e aspas “(ASCII: 92, 34)) também devem ser precedidas por uma barra invertida \ (ex: "\\" e "\"" ).
  • Os comentários são permitidos com parênteses em qualquer extremidade da parte local; por exemplo john.smith(comment)@example.com e (comment)john.smith@example.com são ambos equivalentes a "john.smith@example.com" , mas john.(comment)smith@example.com seria inválido .
  • Os caracteres internacionais acima de U+007F , codificados como UTF-8, são permitidos pelo RFC 6531, embora os sistemas de correio possam restringir os caracteres a serem usados ​​ao atribuir peças locais.

e para a parte global / domínio:

A parte de nome de domínio de um endereço de e-mail deve estar de acordo com diretrizes rígidas: ele deve corresponder aos requisitos para um nome de host, consistindo de letras, dígitos, guias e pontos. Além disso, a parte do domínio pode ser um endereço IP literal, cercado por aparelhos quadrados, como jsmith@[192.168.2.1] ou jsmith@[IPv6:2001:db8::1] […]

Fonte: Wikipedia

O que é válido?

Isso pode levar a estranhos, mas válidos endereços de e-mail, como o seguinte:

  • localpart.ending.with.dot.@example.com
  • (comment)localpart@example.com
  • "this is v@lid!"@example.com
  • "much.more unusual"@example.com
  • postbox@com
  • admin@mailserver1
  • "()<>[]:,;\\@\"\\\\!#$%&\'*+-/=?^_`{}| ~.a"@example.org
  • " "@example.org

Fonte: php.net / author gt@kani.hu – exemplo fixado pelo autor desta publicação

Limites

Existem também limites de comprimento local e de domínio:

O formato dos endereços de e-mail é local-part@domain onde a parte local pode ter até 64 caracteres e o nome do domínio pode ter no máximo 253 caracteres – mas o limite máximo de 256 caracteres de um caminho direto ou reverso restringe Todo o endereço de e-mail não tem mais de 254 caracteres . [2] As definições formais estão na RFC 5322 (seções 3.2.3 e 3.4.1) e RFC 5321 – com uma forma mais legível dada no RFC 3696 [3 ] e as erratas associadas.

Fonte: Wikipedia

Restrições do WordPress

E isso é o que o WordPress verifica:

  • Teste o comprimento mínimo que o e-mail pode ser: strlen( $email ) < 3
  • Teste para um caractere @ após a primeira posição: strpos( $email, '@', 1 ) === false
  • Teste os caracteres inválidos !preg_match( '/^[a-zA-Z0-9!#$%&\'*+\/=?^_`{|}~\.-]+$/', $local )
  • Teste de seqüências de períodos: preg_match( '/\.{2,}/', $domain )
  • Teste para períodos de liderança e arrastar e espaço em branco: trim( $domain, " \t\n\r\0\x0B." ) !== $domain
  • Suponha que o domínio tenha pelo menos dois subs: $subs = explode( '.', $domain ); e depois
    • 2 > count( $subs )
    • trim( $sub, " \t\n\r\0\x0B-" ) !== $sub
    • !preg_match('/^[a-z0-9-]+$/i', $sub )

Fonte: WP Core v4.0

Filtros e validação personalizada

Todos os casos acima mencionados is_email() para retornar falso. O resultado é capaz de filtragem (um retorno de chamada pode ser anexado) eo filtro terá três argumentos, onde o último argumento é o motivo. Exemplo:

 return apply_filters( 'is_email', false, $email, 'sub_hyphen_limits' ); 

o que significa que você pode anular os resultados retornados por cheques específicos.

Isso permite que você adicione verificações especiais, por exemplo, para permitir domínios Umlaut, somente partes de domínio TLD, etc.

Conclusão

O WordPress é seguro para a maioria dos casos, mas é mais restritivo, já que os servidores de correio precisam ser compatíveis com o RFC. Tenha em mente que nem todos os servidores de correio se alinharão com as diretrizes do RF 6531.

Editar

Costume engraçado: existem duas funções relacionadas dentro de ~/wp-includes/formatting : is_email() e sanitize_email() . Eles são praticamente a mesma function. Não tenho ideia por que alguém decidiu que seria uma boa idéia copiar o conteúdo da function de um para outro em vez de apenas adicionar o mesmo como retorno de chamada aos filtros que o outro fornece. Como is_email() desde que v0.71 e sanitize_email() desde v1.5 são iguais, eu pessoalmente usaria o mais tarde como você obteve uma seqüência de limpeza. Note-se que is_email() indica mesmo que não é compatível com RFC.

Desinfecte todas as coisas!

Uma das regras cardinais da segurança é nunca confiar na input do usuário. Em geral, não me importo com a implementação de is_email () ou qualquer outra function específica, ou se essa function faz algo perigoso com o que eu dou. Talvez a implementação mude algum dia. Quem sabe. Eu tenho que assumir que pode ser comprometida. O pressuposto deve ser sempre que a input do usuário seja ativamente hostil, duplamente para qualquer coisa eventualmente destinada a um database, e para sanitizar cada bit de input do usuário antes de liberá-lo para alguma function. Isso é bom, segurança geral de higiene.