Tengo un formulario de contacto HTML manejado por PHP en mi sitio. Actualmente uso la función PHP mail(). Por eso tengo que hacer muchas validaciones de entrada de usuario para evitar email header injection attacks. Creo que estoy seguro, pero probablemente olvidé algo y quiero pasar a una sólida biblioteca de correo electrónico PHP. La biblioteca que seleccioné es Swiftmailer.¿Qué tan seguro puede ser un formulario de contacto HTML impulsado por PHP usando Swiftmailer?
Ahora quiero comprobar si SwiftMailer aborda los siguientes:
- Elimina o escapar
<
y>
caracteres en los nombres de remitentes. - Elimina las nuevas líneas (
\n
,\r\n
...) de los nombres del remitente. - Elimina o escapa de nuevas líneas del asunto del correo electrónico.
- Normaliza las nuevas líneas en el cuerpo del mensaje (el contenido del correo electrónico). Según los documentos PHP,
\n
se debe utilizar en el contenido y\r\n
como separador de encabezados de correo electrónico.
PD: Intenté contactar al equipo de Swiftmailer con mis preguntas sin éxito, así que lo estoy intentando aquí.
Editar:
hice algunos casos de prueba con SwiftMailer y esto es lo que he encontrado hasta ahora:
- Cuando se tiene un
<
o>
en el nombre de un remitente, se obtiene a No se pudo entregar correo electrónico de error. Esto de alguna manera puede conducir en un DOS attack de su servidor de correo (tal vez estoy equivocado). ¡¿Esto es normal?! - Las líneas nuevas se escapan por lo que el ataque de inyección falla.
- Las líneas nuevas se escapan por lo que el ataque de inyección falla.
- Probado pero no puedo ver qué hace Swiftmailer (si hace algo). Así que todavía estoy en la oscuridad aquí.
¿Puede alguien aclarar los números 1 y 4 por mí? No estoy seguro si es un comportamiento normal ...
Usted puede mirar siempre a través del código de ...Swiftmailer es solo un script PHP, después de todo. Si eres tan paranoico con las vulnerabilidades, probablemente quieras auditar las bibliotecas externas de todos modos. –
'Proteger de los ataques de inyección de encabezado sin eliminar contenido de solicitud de datos (desde la página de inicio) y de un escaneo aproximado a través del código Supongo que si transfiere algo que no es válido, obtendrá una excepción en lugar de aceptación silenciosa . – hakre
Parece que siempre que elimine \ n y \ r de cualquier encabezado enviado por el usuario, y la conversión de palabra ($ message, 70), debería estar bien. ¿Cuál es el problema con pelar < and > de los nombres de los remitentes? Me interesaría mucho saber a qué tipo de hack te dejan abiertos estos personajes. Cualquier información es muy apreciada. – dqhendricks