Come pentestire il file Flash su webapp con alowscriptaccess = samedomain?

Fonte originale - link

2.4.1. Abusare di Flash's crossdomain.xml

La stessa politica di origine può essere spesso considerata troppo restrittiva, facendo sì che gli sviluppatori di applicazioni chiedano la possibilità per due domini diversi di interagire l'uno con l'altro. Uno dei primi popolari plug-in del browser a supportare tale interazione tra domini era Adobe Flash. Adobe ha compreso i pericoli di consentire un accesso arbitrario tra domini e ha implementato una misura di sicurezza per determinare se Flash avrebbe consentito l'interazione tra domini. Questa misura di sicurezza è implementata tramite il file dei criteri interdominio.

Il file dei criteri dei domini incrociati di Flash definisce le "regole" per l'interazione tra domini. Il file dei criteri interdominio è semplicemente un file XML denominato crossdomain.xml. Ecco un esempio di un file crossdomain.xml:

<?xml version="1.0" encoding="UTF-8" ?>

<cross-domain-policy
    xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance
    xsi:noNamespaceSchemaLocation=
    "http://www.adobe.com/xml/schemas/PolicyFile.xsd">

    <allow-access-from domain="*" /> </cross-domain-policy>

Questo file di criteri crossdomain.xml deve essere ospitato sul server che desidera consentire l'interazione tra domini. Prima di consentire l'interazione tra domini, Flash verificherà la presenza di un file di criteri interdominio sul dominio di destinazione. Se non esiste alcun file di criteri, Flash utilizza automaticamente la stessa politica di origine restrittiva e non consente l'interazione tra domini. Se esiste un file crossdomain.xml nel dominio di destinazione, Flash legge le "regole" contenute nel file di criteri e consente l'interazione tra domini in base alle regole stabilite. Ancora una volta, l'intera premessa è basata sul fatto che il file di criteri interdominio deve essere fornito dal dominio che desidera consentire l'interazione tra domini. Per impostazione predefinita, Flash verifica la presenza di un file di criteri tra domini denominato crossdomain.xml nella radice Web dell'applicazione Web (http://www.example.com/crossdomain.xml).

A partire da Flash 7, puoi eseguire il controllo di Flash per crossdomain.xml in posizioni arbitrarie (non solo la radice della web root) quando il componente Flash richiama loadPolicyFile() con un URL come parametro (contenente la posizione di crossdomain .xml sul server di destinazione).

Nota

Puoi trovare ulteriori informazioni su System.Security.loadPolicyFile() sul seguente sito web:

link

Il concetto di politica dei domini di Flash si basa su poche premesse semplici. Una versione semplificata della logica è la seguente:

Il file dei criteri interdominio deve trovarsi in un percorso accessibile dal Web del server Web per consentire l'accesso tra domini da Flash a quel server.

L'unico modo in cui qualcuno può inserire un file arbitrario in un percorso accessibile dal Web del server web è se ha accesso amministrativo al server web.

Pertanto, se il server Web ha un file di criteri tra domini in un percorso accessibile dal Web sul server Web, un amministratore deve averlo inserito lì.

Questa logica è intrinsecamente imperfetta perché molte applicazioni Web consentono agli utenti di caricare il contenuto sul server web. Se l'applicazione serve successivamente quel contenuto sotto il suo nome di dominio, quell'applicazione web si è inconsapevolmente messa a rischio a causa delle abilità tra domini di Flash. Se un utente malintenzionato è in grado di caricare un file di criteri crossdomain.xml, l'utente malintenzionato può utilizzare un'applet Flash malvagia sul proprio server Web per attaccare l'applicazione vulnerabile. Questa malvagia applet Flash sarà in grado di effettuare richieste interdominio all'applicazione Web vulnerabile e tali richieste verranno fatte con i cookie di sessione di tutti gli utenti sfortunati che si imbattono nel sito Web dell'attaccante. Per peggiorare le cose, il file dei criteri interdominio non deve avere l'estensione .xml. I criteri di sicurezza di Flash rispetteranno qualsiasi estensione di file.

Nota

Adobe Flash 9.0.115.0 consente la specifica di "meta-politiche". Queste politiche definiscono quali file di criteri sul server devono essere rispettati. Puoi trovare ulteriori informazioni sulle meta-politiche all'indirizzo link .

Tutto qui dipende dalla versione di Flash Player. Ecco una lista di cose, che dovresti provare su questo file .swf.

La nostra prima ipotesi è stata Scripting di siti incrociati , quindi dovremmo provare a utilizzare XSS, in particolare che abbiamo notato uno dei metodi non sicuri: loadMovie .

Scripting di siti incrociati

Esistono alcuni tipi di funzioni non sicure. Ciascuno di essi ha un carico utile diverso:

• getURL - payload: javascript:alert('XSS')
• load* (in questo caso: loadMovie ) - payload: asfunction:getURL,javascript:alert('XSS') [ asfunction funziona in questo contesto fino al rilascio di Flash Player 9 r48]
• TextField.htmlText - payload: <img src='javascript:alert("XSS")//.swf'> [.swf è molto importante qui: le altre estensioni non ignoreranno il filtro interno di Flash Player].

Flash lampeggiante

la nostra seconda ipotesi dovrebbe essere XSF . Il primo filmato flash tenta di caricare il secondo. Quando ottiene l'accesso alla stessa parte della sandbox, siamo vulnerabili a XSF. Questo significa che siamo in grado di caricare il file flash esterno, malvagio, che può portare a XSS o ad un falso filmato flash (ad esempio: forma flash falsa, tipo di phishing). Ora pensiamo per un po 'quando potremmo ottenere quei difetti.

Flash Player 7 o versioni successive consente lo scripting tra domini solo tra lo stesso dominio. Possiamo caricare file .swf da domini diversi, ma i file non saranno in grado di scambiare dati. Per maggiori dettagli dovresti controllare System.security.allowDomain .

Ora parliamo di:

AllowScriptAccess

Questo parametro può essere trovato all'interno di param o embed tag e decide sulla possibilità di eseguire l'accesso URL in uscita all'interno del file SWF. Ci sono tre valori possibili:  - sameDomain : l'accesso alla comunicazione è consentito quando il file .swf e la pagina HTML incorporata si trovano nello stesso dominio.  - always : uguale a sameDomain , ma il file .swf potrebbe anche comunicare con .swf dal dominio diverso (di quanto non sia incorporato).  - never - il file .swf non può comunicare con nessuna pagina. Il protocollo del livello di applicazione, il nome del dominio e il numero di porta definiscono l'origine. Quando il file .swf ottiene il codice JavaScript da eseguire dal browser, verrà eseguito all'interno dell'origine del sito Web di incorporamento. Consideriamo due situazioni [ allowScriptAccess = sameDomain ]:

• .swf ospitato su A.com è incorporato nel sito Web HTML su B.com: origin: B.com
• B.com ha un iframe che carica il file .swf da A.com: origin: A.com

Il valore predefinito è impostato su sameDomain . Significa che .swf senza l'attributo AllowScriptAccess deve essere considerato come .swf con la proprietà sameDomain . Nel 2008 è stato notato che sameDomain potrebbe portare a Contrassegno di richiesta cross-site . Consiglio vivamente di leggere il post del blog su questo ( maggiori dettagli - qui ) e guarda PoC .

Non dovresti dimenticare l'Inquinamento dei parametri Flash.

Pollution Parameter Pollution

Non tutti i file .swf possono essere caricati senza l'HTML originale. Se il programmatore si fosse dimenticato dell'igienizzazione, potremmo iniettare le variabili globali in flash:

print '<object type= (...) data="'.$_GET['flash'].'"></object>'

URI: http://example.com/?flash=flash.swf?var=bum

HTML: <object type= (...) data="flash=flash.swf?var=bum"></object>