Luego de de una extensa recopilación de información dimos con la respuesta esta obstáculo que tienen ciertos de nuestros lectores. Te compartimos la respuesta y nuestro objetivo es servirte de gran ayuda.
Solución:
No, no es necesario. Pero por favor, sigue leyendo.
Aporte higienización es un término horrible que pretende que puede agitar una varita mágica a los datos y convertirlos en “datos seguros”. El problema es que la definición de “seguro” cambia cuando los datos son interpretados por diferentes piezas de software.
Los datos que pueden ser seguros para incrustar en una consulta SQL pueden no ser seguros para incrustar en HTML. O JSON. O comandos de shell. O CSV. Y eliminar (o rechazar por completo) los valores para que sean seguros para incrustarlos en todos esos contextos (y muchos otros) es demasiado restrictivo.
¿Entonces, qué debemos hacer? Asegúrese de que los datos nunca estén en condiciones de causar daños.
La mejor manera de lograrlo es evitar la interpretación de los datos en primer lugar. Las consultas SQL parametrizadas son un excelente ejemplo de esto; los parámetros nunca se interpretan como SQL, simplemente se colocan en la base de datos como también datos.
Para muchas otras situaciones, los datos aún deben estar incrustados en otros formatos, por ejemplo, HTML. En ese caso, los datos deben escaparse para ese idioma en particular en el momento en que está incrustado. Por lo tanto, para evitar XSS, los datos se escapan en HTML en el momento de la visualización. No en el momento de la entrada. Lo mismo se aplica a otras situaciones de incrustación.
Entonces, ¿deberíamos pasar todo lo que obtenemos directamente a la base de datos?
Quizás. Depende.
Definitivamente hay cosas que puede verificar sobre la entrada del usuario, pero esto depende en gran medida del contexto. Debido a que la desinfección está mal definida y mal utilizada, prefiero llamar a esto validación.
- Por ejemplo, si se supone que algún campo es un número entero, ciertamente puede validar este campo para asegurarse de que contiene un número entero (o tal vez NULL).
- Ciertamente puede hacer algo de validación en los campos de correo electrónico (aunque algunas personas argumentan que no hay mucho que pueda hacer además de verificar la presencia de un
@, y tienen un buen punto). - Puede solicitar que los comentarios tengan una extensión mínima y máxima.
- Probablemente debería verificar que cualquier string contiene solo caracteres válidos para su codificación (por ejemplo, no secuencias UTF-8 inválidas).
- Puede restringir un nombre de usuario a ciertos caracteres, si eso tiene sentido para su base de usuarios.
- Una longitud mínima para las contraseñas es, por supuesto, increíblemente común.
Como puede ver, estas comprobaciones dependen mucho del contexto. Y todos ellos son para ayudar a aumentar las probabilidades de que termine con datos que tengan sentido. No son para proteger su aplicación de entradas maliciosas (inyección SQL, XSS, inyección de comandos, etc.), porque este no es el lugar para hacerlo.
Los usuarios deben tener libertad para escribir '; DROP TABLE users; -- sin que su publicación sea rechazada o destrozada '; DROP TABLE users; --. ¡Tenga en cuenta que puedo incluir ese tipo de contenido “malicioso” en sec.SE!
Entonces, para responder a su pregunta original:
… ¿sigue siendo necesario y / o relevante para la seguridad desinfectar de alguna manera la entrada?
No, no es. Pero, por favor, escape correctamente los datos donde sea necesario antes de generarlos. Y considere las validaciones, cuando corresponda.
Pienso en herramientas de terceros benignas, pero no tan bien diseñadas (tal vez scripts autoescritos por el administrador, o algunos CrystalReports sofisticados hechos por un no técnico) que intentan consumir datos no higienizados de nuestra base de datos.
Luego escape o filtre los datos antes de enviarlos a esas herramientas, pero no manipule los datos en su base de datos.
Pero realmente, esos scripts deben corregirse o reescribirse teniendo en cuenta la seguridad.
(MySQL parece tener problemas con Emojis)
Un poco fuera de tema, pero eche un vistazo a la utfmb4 juego de caracteres para MySQL;)
Si utilizo consultas totalmente parametrizadas en todas partes, ¿sigue siendo necesario y / o relevante para la seguridad desinfectar de alguna manera la entrada?
Si. Siempre es una buena idea desinfectar la entrada antes de enviarla a la base de datos.
Las consultas parametrizadas pueden salvarlo de los ataques de inyección SQL, pero pueden no resultar beneficiosas en el caso de ataques XSS almacenados. Si un usuario envía un código javascript malicioso a su formulario y usted lo almacena correctamente en su base de datos y muestra el mismo campo en otro lugar, la secuencia de comandos maliciosa podría ejecutarse en el navegador de la víctima.
Siempre es una buena idea desinfectar la entrada antes de enviarla por adelantado y desinfectar la salida antes de enviarla al navegador del cliente.
EDITAR: Como se señaló en los comentarios, la desinfección es diferente de la codificación / escape de valores. La desinfección, aquí, significaba que las entradas se pueden validar para algunas comprobaciones básicas antes de pasarlas a la base de datos (o cualquier otra capa). Por ejemplo, un campo que espera una dirección de correo electrónico se puede validar para una dirección de correo electrónico válida, un campo de edad se puede validar solo para números enteros, etc. Las expresiones regulares resultan ser de gran ayuda aquí. Cabe señalar que estas comprobaciones deben colocarse tanto en el front-end (del lado del cliente) como en el back-end.
En el caso de los campos que esperan texto enriquecido, puede implementar la Política de seguridad de contenido en las páginas donde se muestre la entrada del usuario. También puede utilizar un desinfectante HTML para desinfectar la entrada del usuario.
Sí, siempre debe desinfectar los datos de entrada. El saneamiento no se trata solo de protegerlo de la inyección, sino también de validar tipos, valores restringidos (enumeraciones), rangos, etc. Si bien es posible que un atacante no pueda manipular su sql, aún puede causar un comportamiento no deseado en el resto de su aplicación.
Por ejemplo, si un atacante cambiara un valor de enumeración, ¿podría manipular el sistema? ¿Acaban de cambiar un rol, tipo de usuario, etc.? Alternativamente, podrían ingresar un valor mayor que el que se puede aceptar en su esquema o el tipo de datos (byte v int32, int64), ¿podría esto causar que la aplicación se bloquee y exponga información o deje datos huérfanos cambiados (no tratados)?
Nos puedes añadir valor a nuestro contenido informacional añadiendo tu experiencia en las referencias.