Estoy usando is_email()para verificar si una dirección de correo electrónico proporcionada por el usuario es válida. Por ejemplo:
$email = $_POST['email'];
if ( is_email( $email ) )
// Do something.Que yo sepa, nada en esta función escribe información en la base de datos. ¿Debería desinfectar $emailantes de pasarlo a la función?
sanitization
henrywright
fuente
fuente
Respuestas:
Mirando la
is_email()funcionalidad en trac, parece que no necesita sanatizar, ya que solo se trata de pruebas de cadena. Incluso iría tan lejos como para decir que si esta función devuelve verdadero, no necesitaría desinfectarla antes de enviarla a la base de datos.fuente
WordPress y núcleo de PHP
La
is_email()función Fuente es una implementación típica de WordPress y no funciona completamente con lo que permite el RFC 6531 . Una razón podría ser que laFILTER_VALIDATE_EMAILconstante de PHP predeterminadafilter_var()no es mucho mejor para validar algo de acuerdo con las pautas del Grupo de trabajo de ingeniería de Internet (IETF®) .Normas
El punto es que el RFC 6531 permite "caracteres Unicode más allá del rango ASCII" . Es decir, esos son (para la parte local, antes de
@):y para la parte global / dominio:
Fuente: Wikipedia
¿Qué es válido?
Esto puede conducir a direcciones de correo electrónico extrañas pero válidas como las siguientes:
Fuente: php.net / author [email protected] - ejemplo arreglado por el autor de esta publicación
Límites
También hay límites de longitud locales y de dominio:
Fuente: Wikipedia
Restricciones de WordPress
Y esto es lo que WordPress busca:
strlen( $email ) < 3strpos( $email, '@', 1 ) === false!preg_match( '/^[a-zA-Z0-9!#$%&\'*+\/=?^_`{|}~\.-]+$/', $local )preg_match( '/\.{2,}/', $domain )trim( $domain, " \t\n\r\0\x0B." ) !== $domain$subs = explode( '.', $domain );y luego2 > count( $subs )trim( $sub, " \t\n\r\0\x0B-" ) !== $sub!preg_match('/^[a-z0-9-]+$/i', $sub )Fuente: WP Core v4.0
Filtros y validación personalizada
Todos los casos mencionados anteriormente se activarán
is_email()para devolver falso. El resultado es filtrable (se puede adjuntar una devolución de llamada) y el filtro tendrá tres argumentos, donde el último argumento es el motivo. Ejemplo:lo que significa que puede anular los resultados devueltos por verificaciones específicas.
Esto le permite agregar controles especiales, por ejemplo, para permitir dominios Umlaut, partes de dominio solo para TLD, etc.
Conclusión
WordPress es seguro para la mayoría de los casos, pero más restrictivo ya que los servidores de correo deben ser compatibles con RFC. Tenga en cuenta que no todos los servidores de correo se alinearán con las pautas de RF 6531.
Editar
Dato curioso: dentro hay dos funciones relacionadas
~/wp-includes/formatting:is_email()ysanitize_email(). Son prácticamente la misma función. No tengo idea de por qué alguien decidió que sería una buena idea copiar los contenidos de la función de uno a otro en lugar de simplemente agregar uno como devolución de llamada a los filtros que proporciona el otro. Como desde la v0.71 y desde la v1.5 son iguales, personalmente usaría la última cuando obtenga una cadena limpia. Tenga en cuenta que incluso afirma que no es compatible con RFC.is_email()sanitize_email()is_email()fuente
¡Desinfecta todas las cosas!
Una de las reglas cardinales de seguridad es no confiar nunca en la información del usuario. En general, no me importa la implementación de is_email () o cualquier otra función específica, o si esa función hace algo peligroso con lo que le doy. Quizás la implementación cambie algún día. Quién sabe. Tengo que asumir que puede verse comprometido. La suposición siempre debe ser que la entrada del usuario es activamente hostil, doblemente para cualquier cosa destinada eventualmente a una base de datos, y para desinfectar cada bit de entrada del usuario antes de pasarlo a alguna función. Esto es simplemente bueno, higiene de seguridad general.
fuente