javascript - uso - ¿Qué tan seguro es la Sanitización de HTML del lado del cliente?
script type= text/javascript src= (4)
Últimamente he estado buscando en Pagedown.js el encanto de utilizar el marcado en mis páginas en lugar de feo texto de solo lectura.
Soy extremadamente cauteloso, ya que parece bastante fácil engañar al convertidor desinfectado. He visto algo de discusión sobre Angular.js y sus enlaces html y también escuché algo cuando Knockout.js 3.0 salió que había habido una inseguridad previa al enlace html.
Parece que todo lo que alguien debería hacer para desactivar el sanitizador en Pagedown.js, por ejemplo, es algo así como ...
var safeConverter = new Markdown.Converter();
// safeConverter is open to script injection
safeConverter = Markdown.getSanitizingConverter();
// safeConverter is now safe
// Override the getSanitizingConverter pseudo-code
Markdown.getSanitizingConverter = function () {
return Markdown.Converter;
};
y podrían abrir un sitio hasta la inyección de guiones. ¿Eso no es verdad?
Editar
Entonces, ¿por qué las bibliotecas como ese paquete serían un sanitizante para usar en el lado del cliente? Claro que dicen que no rinden html no esterilizado, pero la siguiente línea dice usar Markdown.Sanitizer ..
¿Cómo Angular no está abierto con el servicio de desinfectante o es solo una farsa también?
Creo que hay un pequeño malentendido sobre el propósito y la naturaleza de tales "desinfectantes".
El objetivo de un desinfectante (por ejemplo, Angular''s ngSanitize ) no es evitar que los datos "malos" se envíen al servidor. Es más bien al revés: un desinfectante está ahí para proteger al usuario no malicioso de datos maliciosos (ya sea como resultado de un agujero de seguridad en el lado del servidor (sí, no hay configuración perfecta) o de otras fuentes ( unos de los que no tienes control)).
Por supuesto, al ser una función del lado del cliente, un desinfectante podría pasarse por alto, pero (dado que el desinfectante está allí para proteger al usuario (no al servidor)) al pasar por alto, el desvío quedará desprotegido (lo cual no se puede hacer , ni debería importarte, es su elección).
Además, los desinfectantes (pueden) tienen otra función (potencialmente más importante): un desinfectante es una herramienta que ayuda al desarrollador a organizar mejor su código de una manera que es más fácilmente comprobable para ciertos tipos de vulnerabilidades (por ejemplo, ataques XSS) e incluso ayuda en la auditoría de código real para ese tipo de agujeros de seguridad.
En mi opinión, los documentos angulares resumen el concepto bastante bien:
El Escape contextual estricto (SCE) es un modo en el que AngularJS requiere enlaces en ciertos contextos para dar como resultado un valor marcado como seguro para ese contexto.
[...]
SCE ayuda a escribir el código de forma que (a) sea seguro por defecto y (b) hace que la auditoría de vulnerabilidades de seguridad como XSS, clickjacking, etc. sea mucho más fácil .[...]
En un ejemplo más realista, uno puede presentar comentarios de usuario, artículos de blog, etc. a través de enlaces. (HTML es solo un ejemplo de un contexto en el que la entrada de representación controlada por el usuario crea vulnerabilidades de seguridad).Para el caso de HTML, puede usar una biblioteca, ya sea del lado del cliente o del servidor, para desinfectar el HTML inseguro antes de vincularlo al valor y representarlo en el documento.
¿Cómo se aseguraría de que cada lugar que utilizara estos tipos de enlaces se vinculó a un valor que fue desinfectado por su biblioteca (o devuelto como seguro para ser procesado por su servidor?) ¿Cómo puede asegurarse de que no haya eliminado accidentalmente la línea que desinfectaron el valor, o cambiaron el nombre de algunas propiedades / campos y se olvidó de actualizar el enlace al valor sanitizado?
Para estar seguro de forma predeterminada, debe asegurarse de que dichos enlaces no se permitan a menos que pueda determinar que algo explícitamente dice que es seguro usar un valor para vincular en ese contexto. Luego puede auditar su código (lo haría con un simple grep) para asegurarse de que esto solo se haga para aquellos valores que usted puede ver fácilmente como seguros, ya que fueron recibidos de su servidor, desinfectados por su biblioteca, etc. Puede organizar su base de código para ayudar con esto , tal vez permitiendo que solo los archivos en un directorio específico hagan esto. Garantizar que la API interna expuesta por ese código no marque valores arbitrarios como seguros se convierte en una tarea más manejable .
Nota 1: el énfasis es mío
Nota 2: Perdón por la cita larga, pero considero que se trata de un tema muy importante (tanto como sensible) y que a menudo se malinterpreta.
No puedes desinfectar el lado del cliente. Cualquiera puede desactivar JavaScript o cambiar los valores y enviarlos a su servidor.
El servidor necesita verificarlo dos veces. El lado del cliente en mi mente es realmente solo una característica de usabilidad. Entonces saben a medida que escriben si están equivocados o no.
En respuesta a la edición:
La mayoría de ellos son convenientes o proporcionan funcionalidad. Por ejemplo, una validación discreta hará que mis cuadros de texto sean rojos si ingresan un número inválido. Eso es bueno, y no tuve que publicar y verificar y luego cambiar el cuadro de texto borde blablablabla ...
Pero cuando publican, todavía necesito validar sus datos. Por lo general, lo mantengo en una biblioteca central que se puede compartir en todas las aplicaciones (web, servicio web, aplicación móvil, cliente grueso, etc.)
La validación de usabilidad varía de plataforma a plataforma. Pero en el núcleo, antes de que cualquier aplicación confíe en los datos, tiene que verificarlo dentro de su barrera de confianza. Nadie puede cambiar el valor detrás de mi if en el servidor, pero cualquiera puede cambiar el valor en su navegador sin tropezar con mi JS.
Pagedown puede ejecutarse tanto en el servidor como en el cliente.
Para desinfectar html en el cliente, tiene más sentido desinfectar el resultado en lugar de la entrada. No se desinfectaría antes de enviar datos a un servidor, pero podría desinfectarse después de recibir datos de un servidor.
Imagine hacer una llamada al servicio web al cliente y obtener datos de un servicio externo. Se puede pasar a través de un desinfectante en el cliente antes de ser procesado. El usuario podría desactivar la desinfección en su propia computadora, pero solo se están lastimando a sí mismos.
También es útil por razones de seguridad solo para evitar que la entrada del usuario modifique accidentalmente el formato de la página circundante. Por ejemplo, al escribir una publicación html con una vista previa en tiempo real (como en ).
Nada seguro.
La sanitización / validación del lado del cliente debe usarse por algunas razones:
- manera más fácil y más rápida de decirle al usuario no malicioso lo que hizo mal
- disminuir la cantidad de veces que el usuario no malicioso se comunica con su servidor (en caso de errores)
Todo lo que valide se puede cambiar porque el cliente no lo controla. Cosas como dev console, fiddler , wireshark te permiten manipular los datos básicamente de la forma que quieras.
Entonces, solo el servidor es responsable de la verdadera sanitización / validación.