Crossdomain.xml - accesso in scrittura al dominio

Question

Crossdomain.xml - accesso in scrittura al dominio

#1 da (0 voti)

0

È una politica permissiva crossdomain.xml Flash analoga a una politica CORS permissiva?

vale a dire. È

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

l'equivalente di

Access-Control-Allow-Origin: <origin request header>
Access-Control-Allow-Credentials: true

es. se il sito dell'utente malintenzionato è attacker-site.co.uk su TLS, le seguenti intestazioni si rifletteranno:

Access-Control-Allow-Origin: https://attacker-site.co.uk
Access-Control-Allow-Credentials: true

Direi che la politica di Flash rende le cose più insicure (solo da una prospettiva Flash), anche se sembrano consentire le stesse cose, l'accesso in scrittura non è consentito da Flash a meno che non esista un file di criteri tra domini permissivi, mentre l'accesso in scrittura a un'origine è consentito per impostazione predefinita nello stesso criterio di origine .

Tuttavia, poiché l'accesso in scrittura è consentito in ogni caso (non Flash), il fatto di averlo anche in Flash non aggiunge alcun rischio di integrità all'applicazione. È corretto?

flash same-origin-policy cors

posta SilverlightFox 10.06.2017 - 10:25

fonte

1 risposta

Leggi altre domande sui tag flash same-origin-policy cors

In Signal Protocol, in che modo il mittente può decodificare il messaggio la prossima volta che lo desidera? Quanto ci vuole per stabilire un attacco MITM?

score 0 · Accepted Answer

Sì, sebbene le autorizzazioni di origine incrociata predefinite differiscano tra Flash e HTML:

       Write Access (e.g. POSTing data)            Read Access (e.g. req allowing data to be read)

HTML   Allowed                                     Only allowed with CORS
Flash  Not allowed without cross domain policy     Not allowed without cross domain policy

Detto questo, è possibile eseguire un attacco CSRF utilizzando Flash senza un criterio di dominio incrociato. Evgeniy Yakovchuk ha pubblicato un Github che mostra un POC del problema. Ciò implica che il file Flash effettua una richiesta a un URL sulla stessa origine del file .swf, tuttavia, il gestore di questo URL emette quindi un reindirizzamento 307 che fa sì che la richiesta venga inviata al sito della vittima. Il file crossdomain.xml non viene controllato prima che la richiesta sia stata reindirizzata e CSRF è stato raggiunto, anche con l'opzione di impostare un'intestazione content-type personalizzata che aggirerebbe le solite restrizioni di Same Origin Policy del browser.

Se questo è "in base alla progettazione", Adobe deve confermare. Loro hanno risolto una variazione su questo che consentiva anche l'aggiunta di intestazioni personalizzate, cosa che normalmente non è consentita senza una politica CORS pertinente, tuttavia 307 problema di reindirizzamento rimane ancora.

Tornando alla tabella precedente, poiché l'accesso è consentito comunque dall'HTML, anche il fatto che Flash "scriva" su un'altra origine non aggiunge ulteriori rischi.

Entrambi i metodi, come già accennato, richiedono anche impostazioni aggiuntive per le intestazioni: Flash non può inviare intestazioni personalizzate con una richiesta a meno che esista l'impostazione appropriata in crossdomain.xml :

<allow-http-request-headers-from domain="www.example.com" headers="MyHeader"/>

E ogni intestazione personalizzata richiede una richiesta pre-volo in HTML a assicurati che la configurazione del server li consenta.

Per quanto riguarda il rischio di integrità (all'interno della triade della CIA ), entrambi potrebbero causare un rischio indiretto se la politica lo consente token anti-CSRF da leggere che potrebbero essere utilizzati per effettuare richieste di modifica dello stato all'applicazione.