I. Introducción
La filtración de información de 120 millones de direcciones de usuarios en febrero volvió a hacer sonar la alarma para las grandes empresas. La importancia de la seguridad de los datos se ha vuelto cada vez más prominente, lo que también ha fortalecido nuestra determinación de implementar pruebas de seguridad normalizadas. Con la normalización de las pruebas de seguridad en el grupo de prueba, más colegas se han interesado en las vulnerabilidades lógicas. Esta serie de artículos tiene como objetivo revelar el alcance, los principios y las medidas preventivas de las vulnerabilidades lógicas y mejorar gradualmente la conciencia de seguridad de todos. Como primer capítulo, este artículo selecciona la conocida vulnerabilidad lógica XSS como introducción.
2. Introducción a las vulnerabilidades XSS
1.Definición de vulnerabilidad XSS
Cross Site Script (Cross Site Script), para no confundirse con la abreviatura de Cascading Style Sheets (CSS), cross-site script se abrevia como XSS. Las secuencias de comandos entre sitios (en lo sucesivo, XSS) generalmente ocurren en el lado del cliente. El atacante inserta código JavaScript malicioso (incluido el código VBScript y ActionScript, etc.) en la página web. Cuando el usuario navega por esta página, estos códigos maliciosos ejecutarse, exponiendo así al usuario a ataques.
2. Principales formas de ataque de XSS
- Ataque de secuencias de comandos entre sitios almacenados
Los atacantes utilizan las funciones de agregar y modificar datos proporcionados por la aplicación para almacenar datos maliciosos en el servidor. Cuando otros usuarios navegan por la página que muestra los datos, el navegador ejecutará el script malicioso incrustado en la página, logrando así el propósito del ataque malicioso. Este ataque es persistente.
- Ataque de secuencias de comandos entre sitios reflejado
El atacante envía una URL al usuario y lo induce a visitarla. El navegador ejecutará el script malicioso incrustado en la página para lograr el propósito del ataque malicioso. Este ataque solo se ejecuta una vez y no es persistente.
- Ataque de secuencias de comandos entre sitios DOM
En la página HTML, los datos ingresados por el usuario no se manipulan directamente a través de JavaScript estandarizado. Cuando el atacante inserta un fragmento de código malicioso, el script malicioso se ejecutará en la visualización final de la página, logrando así el propósito del ataque malicioso. .
3.Peligros de vulnerabilidad XSS
- Robo de información (como robar cookies de usuarios, falsificar la identidad del usuario)
- Estafa de phishing
- ataque de gusano
3. Análisis de los principios de vulnerabilidad XSS.
4. Análisis de ejemplos de vulnerabilidad XSS
1. XSS almacenado
- En realidad, hay dos ubicaciones de vulnerabilidad. Esto es similar a la incrustación de iframe. La URL original es test.jd.com, por lo que afecta directamente a dos sitios web.
- Prueba de vulnerabilidad: envíe el siguiente paquete de datos para insertar el XSS almacenado
2. XSS reflejado
- No aparece ninguna ventana emergente después de ingresar la declaración universal <script>alert()</script>. Ver el código fuente muestra que <> se ha escapado.
- En el valor de la etiqueta de entrada, el contenido que ingresamos no se filtra estrictamente, por lo que cerramos manualmente el valor y luego ejecutamos el script "><script>alert()</script>
5. Opiniones sobre prevención de vulnerabilidades XSS
1. XSS almacenado y reflejado
Después de que el código malicioso se elimina del lado del servidor, tanto el XSS almacenado como el reflejado se insertan en el HTML de respuesta. Los "datos" escritos deliberadamente por el atacante se incrustan en el "código" y el navegador los ejecuta. Hay dos formas comunes de prevenir estas dos vulnerabilidades:
1) Cambiar a renderizado front-end puro para separar código y datos
Escapa completamente de HTML. El navegador primero carga un HTML estático, que no contiene ningún dato comercial. Luego, el navegador ejecuta JavaScript en el HTML. JavaScript carga datos comerciales a través de Ajax y llama a la API DOM para actualizarlos en la página. En la representación puramente frontal, le indicaremos claramente al navegador: el contenido que se configurará a continuación es texto (.innerText), atributo (.setAttribute), estilo (.style), etc. Ya no es fácil engañar a los navegadores para que ejecuten código inesperado.
Sin embargo, también se debe prestar atención a la representación puramente frontal para evitar vulnerabilidades XSS de tipo DOM (como eventos de carga y javascript:xxx en href, etc., consulte la sección "Prevención de ataques XSS de tipo DOM" a continuación). En muchos sistemas internos y de gestión, es muy apropiado utilizar renderizado frontal puro. Pero para páginas con requisitos de alto rendimiento o requisitos de SEO, todavía tenemos que enfrentar el problema de empalmar HTML.
2) Escapar de HTML
Si es necesario empalmar HTML, debe utilizar una biblioteca de escape adecuada para escapar completamente de los puntos de inserción en la plantilla HTML.
Los motores de plantillas de uso común, como doT.js, ejs, FreeMarker, etc., generalmente tienen solo una regla para el escape HTML, que es reemplazar & < >
" ' / Estos personajes están escapados.
2. Prevenir ataques XSS de tipo DOM
Los ataques XSS de tipo DOM en realidad son causados porque el código JavaScript del front-end del sitio web no es lo suficientemente riguroso y ejecuta datos que no son de confianza como código.
Tenga especial cuidado al utilizar .innerHTML, .outerHTML y document.write(). No inserte datos que no sean de confianza en la página como HTML. En su lugar, intente utilizar .textContent, .setAttribute(), etc.
Si usa la pila de tecnología Vue/React y no usa la función v-html/dangerfullySetInnerHTML, evite los riesgos XSS de internalHTML y externalHTML en la etapa de renderizado frontal.
Los detectores de eventos en línea en el DOM, como ubicación, onclick, onerror, onload, onmouseover, etc., el atributo href de la etiqueta a, eval(), setTimeout(), setInterval(), etc. de JavaScript, pueden ejecutar cadenas. como código... Si los datos que no son de confianza se unen en una cadena y se pasan a estas API, es fácil causar riesgos de seguridad, así que asegúrese de evitarlos.
3. Otras medidas de prevención del XSS
Aunque XSS se puede prevenir mediante un escape cuidadoso al representar páginas y ejecutar JavaScript, confiar únicamente en la precaución del desarrollo aún no es suficiente. A continuación se presentan algunas soluciones generales que pueden reducir los riesgos y consecuencias de XSS.
1）Política de seguridad de contenido
El CSP estricto puede desempeñar las siguientes funciones en la prevención de XSS:
Está prohibido cargar código de dominio externo para evitar una lógica de ataque compleja.
Los envíos desde dominios externos están prohibidos. Después de que el sitio web sea atacado, los datos del usuario no se filtrarán a dominios externos.
La ejecución de scripts en línea está prohibida (las reglas son estrictas y actualmente GitHub las utiliza).
Evite la ejecución de scripts no autorizados (nueva característica, utilizada por la versión móvil de Google Maps).
El uso razonable de informes puede detectar XSS a tiempo y ayudar a solucionar el problema lo antes posible.
Para obtener detalles sobre CSP, preste atención a los artículos posteriores de la serie de seguridad front-end.
2) Control de longitud del contenido de entrada
Para entradas que no sean de confianza, se debe limitar una longitud razonable. Aunque no se puede evitar por completo que se produzca XSS, se pueden dificultar los ataques XSS.
3) Otras medidas de seguridad
Cookie de solo HTTP: evita que JavaScript lea ciertas cookies confidenciales. Los atacantes no pueden robar esta cookie después de completar la inyección XSS.
Autor: JD Logistics Fan Wenjun
Fuente: Comunidad de desarrolladores de JD Cloud Ziyuanqishuo Tech Indique la fuente para la reimpresión
JetBrains lanza Rust IDE: RustRover Java 21 / JDK 21 (LTS) GA Con tantos desarrolladores de Java en China, debería nacer un marco de desarrollo de aplicaciones de nivel ecológico .NET 8. El rendimiento ha mejorado enormemente y está muy por delante de . NET 7. PostgreSQL 16 es lanzado por un ex miembro del equipo de Rust. Lo lamento profundamente y pedí cancelar mi nombre. Ayer completé la eliminación de Nue JS en el front-end. El autor dijo que crearé un nuevo ecosistema web. NetEase Fuxi respondió a la muerte de un empleado que fue "amenazado por RR.HH. debido a un ERROR" Ren Zhengfei: Estamos a punto de entrar en la cuarta revolución industrial, Apple es el nuevo producto "v0" del maestro de Huawei Vercel: genera código de interfaz de usuario basado en texto