¿Qué permitir en los campos de formulario HTML?

Question

Tengo algunos formularios HTML, y estoy implementando el filtrado de estos campos en el lado del servidor (usando servlets Java), y me preguntaba qué debería permitir, o tal vez qué debería no permitir. Para direcciones de correo electrónico, elimino cualquier cosa que coincida con esto:

[^A-Za-z0-9._%-@]

¿Cuáles son algunas reglas similares que podría aplicar para nombrar campos de número de teléfono y número de teléfono?

Supongo que <y> debería escaparse como <y>, ¿qué más debo reemplazar?

En ese sentido, ¿hay alguna recomendación para la longitud máxima permitida para tales campos?

Answer 1

Necesitas escapar & a & primero luego < a <. Contrariamente a la creencia popular, es no es necesario escapar > a >. No hay necesidad de proteger el soporte que cierre una etiqueta HTML si no hay forma de abierto una.

Su llamado sobre si se debe escaparse antes de ser escrito a la base de datos, o si debe hacerlo, ya que se lee desde la base de datos cada vez. Hacerlo en el lado de la entrada será más rápido; Hacerlo en el lado de la salida será más seguro y también facilitará los datos intercambiantes con otras aplicaciones si no tiene que siempre sincera cosas antes de enviarlo a otra aplicación. Personalmente, pagaría el precio de rendimiento y la Unescape en el lado de la salida. El almacenamiento en caché puede ayudar.

El resto de la validación que querrá hacer depende del tipo de datos. Para una dirección de correo electrónico, verifique que tenga un @ y al menos uno . Después de eso, entonces, si le importa si es válido o no, envíe el correo electrónico de prueba de dirección. Es casi imposible validar completamente una dirección de correo electrónico mucho más allá de eso, e incluso si la dirección es sintácticamente válida, eso todavía no significa que se pueda entregar. Del mismo modo, permita casi cualquier cosa como URL y luego Intenta recuperarlo para ver si es válido. Para una dirección de facturación/envío, use el servicio web de USPS para validar y obtener los datos en el mejor formato (para direcciones estadounidenses).

Answer 2

Debes permitir cualquier cosa para los nombres. Considere "O'Malley" o "Hudson-Walker". Algunos idiomas (como Salish) incluyen números para que pueda tener "sqwxwu7mish". Luego hay personajes acentuados, hebreo, cirílico, griego, chino, coreano e incluso el músico anteriormente conocido como Príncipe.

El texto del mensaje debe estar igualmente sin restricciones. Si los mensajes pueden contener HTML, entonces tendrá que analizar el HTML (con un analizador HTML real) y aplicar la etiqueta y atribuir blancos blancos para permitir solo las cosas que está esperando.

Los números de teléfono también deberían estar bastante cerca de la forma gratuita. Los formatos norteamericanos son diferentes a los europeos, a algunas personas les gusta decir "(555) 555-5555", mientras que otras como "555-555-5555", algunos números de teléfono tienen extensiones y otros no.

La única codificación de la que debe preocuparse por la entrada es que todo está en UTF-8 (incluida su base de datos). Y, cuando hable con su base de datos, no intente codificar nada usted mismo, use el mecanismo de cotización del controlador de la base de datos y los marcadores de posición.

Las longitudes generalmente deberían ser mucho más grandes de lo que crees que deberían duplicar (al menos) tu primera suposición con un máximo razonable. La diferencia de almacenamiento entre 20 caracteres para un nombre y 100 no será importante para la mayoría de las aplicaciones, así que sea generoso.

No debe preocuparse por la codificación HTML hasta la salida y luego debe usar las herramientas de codificación HTML y URL que admite su entorno, no intente construir la suya.

No exagere sus aportes, esté lo más suelto y perdonador posible. Sin embargo, sea muy estricto con sus salidas.

Answer 3

Longitud máxima: siempre aplico una longitud máxima en mis campos en el lado del cliente y el lado del servidor. Los valores coinciden con los valores máximos establecidos en la base de datos.

Estoy de acuerdo con escapar de <,> y>, <.

Creo que es un buen hábito tener muy buena validación. Si estuviera trabajando con los campos de nombre, mensaje y número de teléfono, haría lo siguiente.

Para cada cuadro de texto, haga que el cuadro de texto no tome los valores no válidos en absoluto.
Nombre: A-ZZ
Mensaje: 'A-ZZ' '0-9' '. ',' ';' etc..
Número de teléfono: '0-9' No permita ningún espacio, sino que lo permita '-', siempre puede analizar el lado del servidor de cadenas.