XSS a través de JSON: ¿Por qué una aplicación web no desinfecta el hash de parámetros entrantes o los valores JSON salientes de etiquetas maliciosas como Script?

Esto a menudo se menciona en todas partes, en parte porque todos repiten el mantra de que la respuesta es el saneamiento de entrada. No lo es Es peligroso, propenso a los insectos y necesita desaparecer. Por supuesto, siempre debe verificar si las longitudes de entrada corresponden correctamente a sus columnas apropiadas.

Entrada de desinfección frente a salida de desinfección.

La entrada de desinfección brinda a las personas una falsa sensación de seguridad, ya que hay muchas formas de evitarlo y porque es difícil de implementar correctamente, lo que obliga a los desarrolladores a buscar en Google una implementación obsoleta que puede o no ser segura. Por este motivo, es mejor desinfectar salida .

Parte de la razón por la que esto se hace más tarde es porque desea conservar los datos correctos, pero también para protegerse contra los ataques de inyección de SQL. Los ataques de inyección de SQL son en gran parte derrotados por declaraciones preparadas, que no son realmente insumos de saneamiento. Debe reemplazar todas las etiquetas de script y salidas peligrosas con entidades html .

Este es un ejemplo de reemplazo de posibles caracteres de script con entidades html en la salida, no en la entrada:

1. < se convierte en < , aún se muestra como < en la página, pero sin alterar el diseño o la base de datos.

2. > se convierte en > , aún se muestra como > en la página, pero sin alterar el diseño o la base de datos.

Entonces, ¿por qué no sanear la entrada? ¿Qué pasa si lo implementamos correctamente?

La mayoría de los desarrolladores no son expertos en seguridad de TI. La mayoría de los desarrolladores no tendrían ni idea de qué hacer en esta área. Al enseñarles estos dos métodos comunes de protección de datos, ahorrará tiempo de desarrollo y aumentará significativamente la seguridad general de su aplicación web. Mejor aún, ayuda a sus desarrolladores a comprender por qué es necesario, en lugar de por qué se necesitan 2340939403424 diferentes tipos de saneamiento de entrada, y previene muchos problemas de implementación que aparecerán invariablemente más adelante.

Como dije antes, buscar en Google funciones de saneamiento de entradas obsoletas no es seguridad. Esa es una falsa sensación de seguridad. Debe comprender qué es aceptable y qué no, y el proceso por el que pasan los datos.

Con el saneamiento de salida, no tienes que preocuparte por que ocurra algún error extraño más adelante en el camino que olvidaste. No tiene que meterse con toneladas de diferentes funciones complicadas que podrían implementarse incorrectamente y dar una falsa sensación de seguridad. Tampoco debe preocuparse por la inyección de scripts.

Pero, ¿qué pasa si reemplazamos todas las entidades html antes de que se inserten? Si lo intentas en el lado del cliente, cualquiera podría modificar la solicitud. Si lo verificas en el back-end antes de ponerlos en la base de datos, eso también podría funcionar ... pero luego hay un problema :

¿Qué sucede si hay un campo que requiere que se coloque una entidad HTML real en él? Digamos un empaque, una dirección, o algo tonto como eso. Tal vez sea un nombre de archivo, tal vez sea algo que has implementado de una manera.

Ejemplo de por qué la entrada de saneamiento chupa

¿Quizás alguien tiene un teclado divertido que usa un apóstrofe diferente para su nombre o dirección? Esto podría dejar algunas bases de datos abiertas al contrabando basado en Unicode.

¿Quizás necesitas un registro que tenga < or > dentro de él? ¿Qué vas a hacer? ¿Buscar por la entidad html? Eso es bastante ineficiente, y requiere muchos trucos para funcionar correctamente en muchas bases de datos.

Tal vez el nombre de alguien tenga un apóstrofe, por ejemplo, Rory O'Cune . Con el saneamiento de entrada, estás destruyendo su nombre y requiriendo más código para resolverlo. ¿Qué pasa si uno de sus empleados está buscando por apellidos y no puede encontrarlo porque se ha reducido a OCune ? Esto es horrible.

Esa es otra razón por la que utiliza consultas parametrizadas y no ingresa el saneamiento. Con declaraciones preparadas y saneamiento de salida, puede hacer esto:

SELECT * FROM [table] WHERE [last_name] = @Lastname -- (or ?)

La variable de parámetro / límite @Lastname (sería un ? en Java) se traducirá correctamente a O'Cune . No se requieren negocios divertidos. No hay errores para cazar. Es infinitamente más seguro, y solo puede generar el html entity si es un carácter que rompe páginas.

Entonces, ¿por qué Ruby no arregla esto automáticamente?

¿Por qué deberían? Todavía no he encontrado ninguna implementación de JSON en cualquier idioma que elimine automáticamente estas etiquetas de script. ¿Qué sucede si desea usar JSON para mostrar etiquetas de script por alguna extraña razón en su sitio web?

Al eliminar esta función, está impidiendo que alguien genere código HTML a través de JSON, lo que sospecho podría romper muchas cosas para mucha gente.

Por lo tanto, la respuesta es hacerlo usted mismo . Reemplace esas etiquetas de script con entidades HTML antes de que se serialicen y devuelvan.

Hacer los insumos seguros es mejor hacerlo lo más tarde posible. Es decir, cuando los datos se envían a la página. En general, los datos de entrada de "desinfección" son malos porque es imposible distinguir entre datos buenos y datos malos en esta etapa (como usted dice, si está permitiendo que sus usuarios ingresen HTML, el marco no puede distinguir la diferencia entre HTML que está destinado a estar allí vs HTML que no está). Incluso con el script en la entrada, a veces esto puede ser válido (piense en los cuadros de texto StackOverflow / StackExchange que contienen código).

Tan tarde como sea posible, entonces su aplicación debería estar codificada en el formato en que esté la salida. Por ejemplo, HTML o JSON. Con el signo anterior y & se convierte en & para que se muestre correctamente para su visualización, para este último se debe usar un codificador JSON que convertirá de & a \x26 dentro de una cadena JSON.

El JSON en sí no es un riesgo XSS ya que el script no se ejecuta en un navegador desde una solicitud JSON (JSONP es otro asunto, ya que estos se incluyen con las referencias del src del script en lugar de cargarlos como datos). El riesgo de XSS con JSON es cuando JavaScript en la página intenta crear o completar elementos HTML con los datos JSON recuperados. El propio JavaScript debe codificar HTML los datos o usar miembros de objetos seguros para completar el DOM (por ejemplo, textContent ).

La desinfección se puede realizar como una capa adicional, sin embargo, el enfoque debe ser la codificación adecuada. Por ejemplo, es posible que desee validar del lado del servidor que un código postal o código postal solo contiene caracteres alfanuméricos y el carácter de espacio. Para campos más complejos, esta no es una opción sin limitar gravemente sus capacidades de entrada.

Algunos marcos intentan sanear globalmente los datos, como .NET con el uso de solicitar validación . Sin embargo, se encuentran vulnerabilidades todo el tiempo, incluyendo esta muy reciente . En resumen, no funciona y causa problemas funcionales para los idiomas que lo intentan. Tampoco ofrece protección contra XSS en los datos que se recuperan de otras fuentes que no sean la aplicación en sí.