¿Qué es la Prevención de Scripting entre sitios?
La prevención de scripts entre sitios es el proceso de detección y corrección de vulnerabilidades XSS en sus sitios web o aplicaciones web antes de que lleguen a la producción. La detección de vulnerabilidades XSS se puede realizar de forma automática, utilizando un escáner de vulnerabilidades automatizado, o manualmente realizando pruebas de penetración. En este artículo, aprenderá las mejores prácticas para la prevención de secuencias de comandos entre sitios y cómo puede implementarlas de inmediato. Al final del artículo, también encontrará un enlace a un escáner de vulnerabilidades gratuito centrado en el desarrollador para que pueda comenzar a detectar y remediar las vulnerabilidades de scripting entre sitios de forma temprana y frecuente, como parte de sus canalizaciones de desarrollo
En este artículo, aprenderá:
- ¿Qué es la Prevención de Scripting entre Sitios?
- ¿Cómo funciona el scripting entre sitios?
- ¿Cuáles son los tipos de ataques XSS?
- ¿Qué importancia tiene la prevención de scripts entre sitios?
- Protección de scripts entre sitios
- Escape de contenido dinámico
- Valores de lista blanca
- Implementar una política de seguridad de contenido
- Desinfectar HTML
- Cookies de solo HTTP
- Prevención de XSS con ejemplos de código
- Prevención de scripts entre sitios en Python (Django)
- Prevención de scripts entre sitios en Ruby (Rails)
- Prevención de scripts entre sitios en Java (Páginas de servidor Java)
- Prevención de scripts entre sitios en C# (ASP.NET)
- Prevención de secuencias de comandos entre sitios en el nodo
- Bigote.js
- Polvo.js
- Nunjucks
- Cross-site scripting prevención en PHP
- Cross-site scripting prevención en AngularJS
- Cross-site scripting prevención en Reaccionar
- ¿Cómo pueden las herramientas automatizadas que ayudan a prevenir el cross-site scripting?
¿Cómo funciona el scripting entre sitios?
Los ataques XSS (Cross-Site Scripting) son una forma de ataque de inyección, en el que se inyectan scripts maliciosos en aplicaciones web de confianza.
Un atacante puede usar la aplicación web para enviar código malicioso, normalmente en forma de script del lado del navegador, a un usuario final diferente, lo que resulta en un ataque XSS.
Las vulnerabilidades XSS son muy comunes, y ocurren cuando una aplicación web utiliza la entrada de un usuario válido contenida en la salida generada, pero sin la validación o codificación adecuadas.
Con el script malicioso enviado al usuario, su navegador no puede saber categóricamente que el script no debe ser de confianza y, posteriormente, lo ejecuta. Este script puede acceder a una multitud de datos, incluidas las cookies, los tokens de sesión o, de hecho, cualquier otra información confidencial que pueda conservar el navegador de ese sitio.
¿Cuáles son los tipos de ataques XSS?
Hay tres tipos principales de ataques XSS:
- XSS reflejado: el script malicioso proviene de la solicitud HTTP actual
- XSS almacenado: el script malicioso proviene de la base de datos del sitio web
- XSS basado en DOM: donde la vulnerabilidad existe en el código del lado del cliente en lugar de en el código del lado del servidor.
¿Qué importancia tiene la prevención de scripts entre sitios?
El daño de explotar una vulnerabilidad XSS depende de la sensibilidad de los datos que maneja su sitio. Estos son algunos ejemplos en los que los hackers explotaron aplicaciones vulnerables de XSS:
- Propagando gusanos en las redes sociales: Facebook, Twitter y YouTube han sido atacados con éxito de esta manera.
- Secuestro de sesión: JavaScript malicioso puede ser capaz de enviar el ID de sesión a un sitio remoto bajo el control del hacker, lo que permite al hacker hacerse pasar por ese usuario secuestrando una sesión en curso.
- Robo de identidad: Si el usuario introduce información confidencial, como números de tarjetas de crédito, en un sitio web comprometido, estos detalles pueden ser robados utilizando JavaScript malicioso.
- Ataques de denegación de servicio y vandalismo del sitio web.
- Robo de datos confidenciales, como contraseñas.
- Fraude financiero en sitios bancarios.
Protección de secuencias de comandos entre sitios
Escape de contenido dinámico
Por lo general, cuando se representa una página web, el contenido dinámico se entreteje en HTML. Si el contenido dinámico se trata incorrectamente, un atacante puede usarlo para construir un ataque XSS almacenado. El atacante abusaría de un campo editable insertando algún código JavaScript malicioso, que se evalúa en el navegador cuando otro usuario visita esa página.
Es posible que no desee que sus usuarios creen HTML sin procesar a menos que su sitio sea un sistema de gestión de contenido. Escape todo el contenido dinámico que proviene de un almacén de datos, para que el navegador sepa que debe tratarse como el contenido de etiquetas HTML, en lugar de HTML sin procesar.
El contenido dinámico de escape generalmente consiste en reemplazar caracteres significativos con la codificación de entidad HTML:
» "
# #
& &
‘ '
( (
) )
/ /
; ;
< <
> >
Como verá en los ejemplos de código a continuación, la mayoría de los frameworks modernos escaparán al contenido dinámico de forma predeterminada.
Al escapar contenido editable de esta manera, el contenido nunca será tratado como código ejecutable por el navegador. Esto evitará la mayoría de los ataques XSS.
Valores de lista blanca
Si un elemento de datos dinámico solo puede tomar unos cuantos valores válidos, restrinja los valores en el almacén de datos. Además, asegúrese de que su lógica de renderizado solo permita valores conocidos y adecuados.
Un ejemplo en el que puede querer usar este enfoque es pedirle a un usuario que seleccione su país de una lista desplegable, en lugar de que lo escriba manualmente.
Implementar una directiva de seguridad de contenido
Los navegadores modernos admiten Directivas de seguridad de contenido. Las directivas de seguridad de contenido permiten al autor de una página web controlar desde dónde se pueden cargar y ejecutar JavaScript y otros recursos.
Para que un ataque XSS sea posible, el atacante tiene que ser capaz de ejecutar scripts maliciosos en la página web de un usuario, ya sea inyectando etiquetas <script> en algún lugar dentro de la etiqueta <html> de una página, o engañando al navegador para que cargue JavaScript desde un dominio de terceros malicioso.
Establecer una política de seguridad de contenido en el encabezado de respuesta le permitirá decirle al navegador que nunca ejecute JavaScript en línea y que elija los dominios que pueden alojar JavaScript para una página:
Content-Security-Policy: script-src 'self' https://apis.google.com
Al incluir en la lista blanca las URL desde las que se pueden cargar los scripts, está indicando implícitamente que no se permite JavaScript en línea.
También puede colocar la directiva de seguridad de contenido en una etiqueta <meta> en el elemento <head> de una página:
<meta http-equiv="Content-Security-Policy" content="script-scr 'self' https://apis.google.com">
Este enfoque es muy efectivo para proteger a sus usuarios, pero requiere disciplina para que su sitio esté listo para tal encabezado. Si bien tener scripts en línea se considera una mala práctica en el desarrollo web moderno, son comunes en sitios antiguos y heredados.
Para migrar de secuencias de comandos en línea de forma incremental, considere la posibilidad de utilizar informes de violaciones de CSP. Al agregar una directiva uri de informe en el encabezado de la política, el navegador le notificará de cualquier violación de la política, en lugar de impedir que se ejecute JavaScript en línea:
Content-Security-Policy-Report-Only: script-src 'self'; report-uri http://example.com/csr-reports
Esto le dará la seguridad de que no hay scripts en línea persistentes, antes de banearlos directamente.
Desinfectar HTML
Para algunos sitios, existe una necesidad legítima de almacenar y procesar HTML sin procesar. Si su sitio almacena y renderiza contenido enriquecido, debe usar una biblioteca de desinfección HTML para garantizar que los usuarios malintencionados no puedan inyectar scripts en sus envíos HTML.
Cookies de solo HTTP
JavaScript malicioso se puede usar para robar una cookie que contiene el ID de sesión del usuario. Rara vez hay una buena razón para leer o manipular cookies en JavaScript del lado del cliente, así que considere marcar las cookies como solo HTTP, lo que significa que las cookies serán recibidas, almacenadas y enviadas por el navegador, pero no pueden ser modificadas o leídas por JavaScript.
Prevención XSS con ejemplos de código
Prevención de scripts entre sitios en Python (Django)
Plantillas en HTML de escape de Django de forma predeterminada, por lo que cualquier cosa que parezca lo siguiente generalmente es segura:
**{{ contents }}**
Puede anular escape utilizando el filtro / safe. A menudo hay buenas razones para hacer esto, pero necesitará realizar revisiones de código en cualquier cosa que use este comando:
**{{ contents | safe }}**
Tenga en cuenta que el escape de HTML también se puede activar o desactivar con la etiqueta {% autoescape %}.
Prevención de scripts entre sitios en Ruby (Rails)
Las plantillas de Rails escapan del HTML de forma predeterminada, por lo que cualquier cosa que parezca lo siguiente generalmente es segura:
<%= contents %>
Puede anular escape utilizando la función raw o el operador <%==. A menudo hay buenas razones para hacer esto, pero deberá realizar revisiones del código en cualquier cosa que use estas funciones:
<% raw contents %>
<%== contents %>
Prevención de scripting entre sitios en Java (Páginas de servidor Java)
Utilice la etiqueta c:out para escapar de HTML de forma segura:
<c:out value="${contents}">
Las siguientes formas de escribir en una plantilla no escapan al HTML, por lo que debe usarlas con cuidado:
<%= contents %>
${contents}
<%
out.println(contents);
%>
Prevención de scripting entre sitios en C# (ASP.NET)
Utilice cualquiera de las siguientes funciones para escapar de forma segura de HTML (el formulario <%: se introdujo en ASP.NET 4.0):
<%= HttpUtility.HtmlEncode(contents) %>
<%: contents %>
La siguiente forma de escribir en una plantilla no escapa automáticamente al HTML, por lo que debe usarlas con cuidado:
<%= contents %>
Use HttpUtility.HtmlEncode(...) si necesita escapar manualmente de HTML.
Prevención de secuencias de comandos entre sitios en el nodo
Bigote.js
En Bigote.js, cualquier etiqueta en bigotes dobles escapa automáticamente de HTML:
{{ contents }}
Tenga en cuenta que las etiquetas en bigotes triples no escapan al HTML, así que úselas con cuidado:
{{{ contents }}}
Polvo.las etiquetas clave js
escapan automáticamente del HTML:
{ contents }
Sin embargo, el escape se puede desactivar con el operador |s, así que úselo con cuidado
{ contents | s }
Nunjucks
Si el escape automático está activado en el entorno, Nunjucks escapará automáticamente las etiquetas para una salida segura:
{{ contents }}
El contenido marcado con el filtro seguro no se escapará: use esta función con cuidado:
{{ contents | safe }}
El escape automático se puede desactivar para una plantilla, en cuyo caso las etiquetas se deben escapar manualmente:
{{ contents | escape }}
Prevención de scripts entre sitios en PHP
El comando echo en PHP no escapa al HTML de forma predeterminada, lo que significa que cualquier código como el siguiente que extrae datos directamente de la solicitud HTTP es vulnerable a ataques XSS:
<?php
Echo $_POST;
?>
Prevención de scripting entre sitios en AngularJS
Cualquier contenido escrito entre corchetes se escapará automáticamente, por lo que lo siguiente es seguro:
<div>{{dynamicContent}}</div>
tenga en cuenta que cualquier código que vincula el contenido dinámico para el atributo innerHTML no será automáticamente escapado:
<div ="dynamicContent"></div><div innerHTML]="{{dynamicContent}}"></div>
Cross-site scripting prevención en Reaccionar
el contenido dinámico escrito entre llaves automáticamente se escapó en Reaccionar, por lo que el siguiente código es seguro:
render() {
return <div>{dynamicContent}</div>
}
también puede escribir HTML en bruto mediante la unión de contenido a la dangerouslySetInnerHTML de la propiedad. El nombre no es una coincidencia, así que busque cualquier código que se parezca al siguiente:
render() {
return <div dangerouslySetInnerHTML={ __html: dynamicContent } />
}
¿Cómo pueden las herramientas automatizadas ayudar a prevenir el scripting entre sitios?
Como se mencionó anteriormente, evitar ataques de scripting entre sitios puede ser fácil, ya que muchos frameworks escapan de contenido dinámico de forma predeterminada. Pero esa comodidad puede provocar inadvertencia y algunas debilidades de seguridad graves para su aplicación y su negocio.
Asegúrese siempre de analizar sus aplicaciones en busca de vulnerabilidades antes de lanzarlas a producción, idealmente como parte de sus canalizaciones de DevOps y CI/CD para detectar y remediar las vulnerabilidades de seguridad de forma temprana, en cada compilación / confirmación.
Puede comenzar a automatizar sus pruebas de seguridad hoy mismo con el escáner Dinámico de Pruebas de Seguridad de Aplicaciones de NeuraLegion, Nexploit. Diseñado para desarrolladores y sin falsos positivos, puede integrarlo en sus canalizaciones para cambiar las pruebas de seguridad y estar seguro por diseño.
Regístrese para obtener su cuenta GRATUITA aquí: https://nexploit.app/signup