¿Debe un sitio web limitar los caracteres que pueden ingresarse en sus campos?

Su enfoque, si se usa correctamente, lo protegería contra dos ataques muy comunes: inyección de SQL y XSS. Y las declaraciones de escape / codificación / preparadas son sin duda una herramienta imprescindible y su principal línea de defensa.

Pero como menciona específicamente los cuadros de búsqueda, su enfoque podría, por ejemplo, no detectar los ataques de DOS comodín de SQL (consulte aquí y aquí ), que podría quedar atrapada por la validación de entrada (del lado del servidor; obviamente, no debería hacer esto con JavaScript del lado del cliente).

Su enfoque tampoco detectará errores de seguridad en su código. Cuando su base de código es lo suficientemente grande, la probabilidad de que olvide la codificación adecuada en un solo lugar aumenta, por lo que contar con una protección adicional, en forma de validación de entrada del lado del servidor, no es una mala idea.

Tampoco está mal desde el punto de vista de la experiencia del usuario (si un usuario ingresa datos no válidos, es bueno informarles de esto, para que sepan qué salió mal y ahora pueden ingresar datos válidos).

El inconveniente es que es mucho más trabajo. Debe pensar realmente qué entrada debe permitirse y qué no, porque, como ha dicho, si filtra demasiado, podría limitar a los usuarios. Si no desea realizar este trabajo para cada campo de entrada posible, un servidor de seguridad de aplicación web podría ser una alternativa.

No debes confiar en el cliente. Escribir Javascript para evitar que se ingresen caracteres no impide que nadie los envíe a su búsqueda.

Su rutina de búsqueda debería eliminar los caracteres que no admite, y al imprimirlos de nuevo, debería mostrar lo que realmente aceptó, no lo que se envió.

Para campos de propósito general en un formulario, considere agregar la validación del lado del cliente para una experiencia de usuario más agradable; Preferiría saber antes de presionar enviar que no va a aceptar números que no sean dígitos en el campo Número de teléfono. Pero si reviso sus comprobaciones de Javascript y envío el formulario de todos modos, el servidor de servicios de fondo debería rechazar mis datos no válidos; no lo deje solo para Javascript para sanear la entrada.

Además, aunque está bien que la mayoría de los campos acepten cualquier cosa que el usuario pueda ingresar y repetir de nuevo en otro lugar, debe evitarse correctamente para evitar las secuencias de comandos entre sitios (por ejemplo, para que el usuario no pueda establecer su nombre como <script src="..."> ). Algunos campos tienen preocupaciones adicionales; por ejemplo, si permite a los usuarios elegir un nombre de usuario único, equivalencia de Unicode podría permitirles elegir una codificación única para su nombre que, sin embargo, parece idéntico al nombre de otro usuario, lo que permite la suplantación. La normalización no es suficiente, porque algunos caracteres se ven como otros personajes, aún permitiendo la suplantación. Lea Consideraciones de seguridad de Unicode para obtener más información sobre esto.

Editar: Tu colega todavía tiene un punto. El lado del servidor no vive aislado. Si acepta entradas de un usuario y luego muestra algunas de esas entradas a otros usuarios en un momento posterior, no es suficiente que el lado del servidor sea a prueba de balas contra las entradas poco fiables. Existe una categoría completa de problemas de seguridad que ocurren en el lado del cliente, porque los datos almacenados del lado del servidor tal como están y se los entregan ciegamente a otros clientes (quienes luego son atacados o engañados por ellos). Sí , el lado del servidor debe restringir los caracteres de entrada, si explotarán o engañarán a sus usuarios cuando se los devuelvan de nuevo.

Lectura recomendada:

• Preguntas frecuentes sobre la seguridad de Unicode
• UTR # 36: Consideraciones de seguridad de Unicode
• UTS # 39: Mecanismos de seguridad Unicode (especialmente detección de script mixto )

Debes implementar las medidas y por qué.

Si limita el espacio de caracteres que el usuario puede ingresar (a-zA-Z! @ # $% ^ & *), por ejemplo, hay menos posibilidades de que un usuario involuntario cometa errores e ingrese algunos datos jank. Sin embargo, esto solo realmente impide que los usuarios finales que intentan usar su aplicación ingresen datos con formato incorrecto. El segundo paso, realizar el saneamiento adecuado y la codificación de los datos garantizará que esté libre de XSS / SQLi y otros posibles ataques.

Entonces usa ambos. Limite la entrada de usuarios para detener a los usuarios finales que no conocen mejor y desinfecte los datos para detener a aquellos que son un poco más inteligentes.

Hay un montón de buenos consejos en las respuestas anteriores, pero no estoy seguro de que hayan abordado la parte principal de su pregunta, es decir, limitar el número / tamaño de los datos de entrada.

Para recapitular lo que ya se ha declarado

• Use la validación de entrada del lado del cliente y la retroalimentación para mejorar la experiencia del usuario del cliente, pero NO confíe en nada del lado del cliente por motivos de seguridad. Todas las medidas del lado del cliente son fácilmente derrotadas. El lado del cliente es para el cliente y debe centrarse en el cliente

• Realice todos los controles de seguridad, validación de datos, desinfección de datos, etc. en el lado del servidor. Supongamos que los datos suministrados son hostiles y no se puede confiar. Utilice soluciones conocidas bien probadas cuando sea posible en lugar de reinventar la rueda e intente dar retroalimentación al usuario si no permite algo para que sepa lo que está sucediendo y pueda reestructurar su entrada

Con respecto a la pregunta sobre la restricción de la cantidad de datos y qué datos se permiten y lo que creo que es una interpretación inexacta del concepto de ser liberal con lo que acepta y conservador con lo que hace, sugeriría

• No tiene sentido aceptar datos que no pueda usar. Lo que puede usar dependerá de las limitaciones de los componentes que conforman su aplicación (base de datos, codificaciones de caracteres compatibles, límites máximos de búfer, etc.)

• No tiene sentido aceptar los datos por mucho tiempo para que quepan en el uso que tenga para ellos, es decir, aceptar campos de datos más largos que la longitud del campo de su base de datos no tiene sentido

• Considere el impacto de rendimiento asociado con datos de entrada extremadamente largos. Por ejemplo, si se trata de una cadena de búsqueda, ¿existe un límite en el que el rendimiento o los recursos consumidos por las consultas extremadamente largas afecten negativamente a su sistema o terminen devolviendo resultados inutilizables?

• ¿Existe el riesgo de que longitudes de entrada ilimitadas puedan desencadenar vulnerabilidades de desbordamiento del búfer? ¿Son TODOS los componentes (bibliotecas, sistemas externos, bases de datos, etc.) capaces de manejar longitudes arbitrarias de datos de entrada o se bloquearán, realizarán un truncamiento inesperado, etc.?

Ser liberal en lo que aceptas no significa que tengas que usar todo lo que aceptas. Realmente significa no solo fallar o estrellarse. Significa proporcionar comentarios al usuario por qué no puede manejar la entrada y detectar fallos para que se gestionen correctamente. No tiene sentido argumentar que debe aceptar todo para una buena experiencia de usuario si no puede usar lo que se proporciona o manejarlo de manera confiable. Sin embargo, no debe eliminar caracteres ni truncar la entrada sin informar al usuario de las razones o los límites. Los usuarios solo se sienten frustrados cuando no está claro qué es y qué no es aceptable; proporcione información clara para que sus expectativas coincidan con su capacidad y haya muchos menos usuarios frustrados.

Desde una perspectiva de seguridad pura, su enfoque es el correcto. La interfaz web (html + javascript + lo que sea ...) es solo un cliente para su servidor HTTP. En otras palabras, cualquier cosa / cualquiera puede hacer solicitudes al pasar la seguridad de su cliente. Por lo tanto, la seguridad a ese nivel es básicamente ninguna seguridad.

Desde una perspectiva de la GUI, en realidad podría ser una buena idea limitar los caracteres con javascript / lo que sea. Por ejemplo: si se supone que su campo tiene una edad, no hay razón para aceptar caracteres alfabéticos. Usted al menos evita problemas sintácticos de los usuarios. Si está bien diseñado, puede ser una gran ventaja para su GUI (retroalimentación rápida para el usuario) y para su servidor (evita las solicitudes que devuelven errores de validación).