Categories
Uncategorized

Il curioso caso di Copia amp Incolla sui rischi d

TheMummichogblog è un partecipante al Amazon Services LLC Associates programma, un programma di affiliazione pubblicitario progettato per fornire un mezzo per siti per guadagnare tariffe pubblicitarie con la pubblicità e il link al amazon.com. Amazon, il logo di Amazon, AmazonSupply, e il logo AmazonSupply sono marchi di Amazon.com, Inc. o delle sue affiliate.

Il curioso caso di Copia & Incolla – sui rischi di incollare contenuti arbitrari nei browser
MICHAŁ BENTKOWSKI | 2 giugno 2020 | Ricerca
Questo è un interessante resoconto sommario della mia ricerca sui problemi nella gestione di copiare e incollare in: browser, editor WYSIWYG popolari, e siti web. Il suo obiettivo principale è quello di aumentare la consapevolezza che il seguente scenario può rendere gli utenti esposti ad attacchi:

Le visite vittima di un sito malevolo,
La copia vittima qualcosa dal sito negli appunti,
La vittima passa a un altro sito (ad esempio Gmail) con editor WYSIWYG.
La vittima incolla dati dagli appunti.
Questa interazione può portare a Cross-Site Scripting, come mostrato nel video qui sotto:

--------------------------------------------------------------------------------------------------



Le labbra dello stolto provocano liti e la sua bocca gli provoca percosse.


Subscribe By E-mail:

Enter your email address:

Delivered by FeedBurner



----------------------------------------------------------------------------------------------

Nelle sezioni successive, spiegherò come questi problemi possano essere identificati e sfruttati.

Io non sono la prima persona a copertura di rischi per la sicurezza associati a copiare e incollare. Nel 2015, il grande Mario Heiderich ha avuto una presentazione chiamato Copy & Pest su questo argomento molto. Mario si è concentrato su come copiare i dati da applicazioni diverse dai browser (come LibreOffice o MS Word) e incollare nei browser e ha dimostrato che questo potrebbe portare a XSS.

Ho esteso le ricerche per dimostrare che:

XSS non è l’unico problema nella gestione dei dati degli Appunti; exfiltration essendo l’altro rischio,
Anche se i browser sono al sicuro da questo tipo di insetti, gli editor WYSIWYG JavaScript possono ancora introdurre problemi di sicurezza.
Infine, credo che uno scenario di attacco che include copiare e incollare tra due schede del browser è più probabilità di essere sfruttati rispetto alla copia da un’applicazione esterna e incollare nel browser.

In questo lavoro, mi spiego 4 problemi di sicurezza nei browser e 5 vulnerabilità in editori ricchi, per i quali ho avuto una taglia combinato di più di $ 30.000.

nozioni di base Appunti
Copia e incolla è una delle maggior parte delle interazioni utente comune per condividere i dati tra le due applicazioni. Gli appunti può contenere diversi tipi di dati, ad esempio:

testo normale
Testo formattato,
File,
Immagini,
Eccetera.
In questo documento intitolata, mi concentrerò su testo formattato dal momento che è equivalente a HTML markup nel mondo dei browser. Questo significa che se si copia il seguente testo: “ciao là”, quindi gli appunti sarà contenere contenuti HTML: ciao non b.

È interessante notare che i browser espongono API che permette di impostare il contenuto degli appunti arbitrario da codice JavaScript. Si consideri il seguente esempio:

document.oncopy = evento => {
event.preventDefault ();
event.clipboardData.setData ( ‘text / html’, ‘ Qualsiasi HTML qui b>!’);
}
1
2
3
4
document.oncopy = evento => {
event.preventDefault ();
event.clipboardData.setData ( ‘text / html’, ‘ Qualsiasi HTML qui b>!’);
}
è necessaria l’event.preventDefault call () per garantire che il comportamento standard del browser sulla copia è bloccata, e la clipboard è riempito solo con il secondo argomento di clipboardData.setData.

L’ovvio vettore di attacco qui è la capacità di mettere XSS payload negli appunti:

document.oncopy = evento => {
event.preventDefault ();
event.clipboardData.setData ( ‘text / html’, ‘’);
}
1
2
3
4
document.oncopy = evento => {
event.preventDefault ();
event.clipboardData.setData ( ‘text / html’, ‘’);
}
produttori di browser sono pienamente consapevoli di questo scenario di attacco. Come metodo di prevenzione, hanno introdotto sanitizzazione contenuto di incollare; cioè, il prelievo di elementi e attributi che sono considerati nocivi.

Ho creato un semplice sito web chiamato “Copy & Paste Playground” per semplificare il processo di ricerca di bug nei browser di sanificazione.

Fig 1. Copiare e incollare parco giochi
L’interfaccia è divisa in due parti:

Sulla sinistra, è possibile inserire il codice HTML, e guardare l’albero DOM generata dal browser. Poi, dopo aver cliccato “Copia come HTML”, l’esatto HTML immesso viene copiata negli appunti.
Il lato destro, d’altra parte, contiene un editor (o editor WYSIWYG) in cui è possibile incollare dagli appunti. DOM albero è mostrato anche per i contenuti di l’editor in modo che sia facile da confrontare con il lato sinistro per scoprire come il browser sterilizzate il codice HTML.
Nell’esempio di figura 1: in primo luogo, ho inserito il seguente payload XSS nel campo di input HTML: ; in secondo luogo, ho cliccato su “Copia come HTML”; Infine, ho incollato nel target pasta. La vista di alberi DOM lo rende facile vedere che il browser spogliato l’attributo onerror dopo aver incollato. È inoltre possibile utilizzare “Copia & Incolla parco giochi” per prova per le questioni XSS tramite copia e incolla in pagine esterne; prima copiare HTML arbitrario dal parco giochi e poi incollarlo in una pagina esterna (o anche un’applicazione esterna).

Considerando che i browser devono impiegare un po ‘di logica dietro decidere se qualsiasi elemento HTML o un attributo devono essere sterilizzate o no, ho deciso di dare loro un aspetto, e cercare di trovare bypass. Come risultato, ho trovato almeno un bypass disinfettante in tutti i principali browser: Chromium, Firefox, Safari, e il classico bordo.

Copiare e incollare i bug nei browser
In questa sezione descriverò in dettaglio una selezione di temi disinfettante appunti ho identificato.

Cromo # 1 (Universal XSS)
Il primo errore ho identificato è un XSS universale, fissato Chromium 79 (crbug.com/1011950). Ho notato una particolarità interessante quando si incolla un codice HTML con un elemento

. DOM albero creato dopo aver incollato dipendeva il luogo esatto in cui si è verificato l’impasto. Si consideri il semplice HTML frammento:

A

DIV
1
A
DIV
E che il ricco editor ha contenuti:

1234
1
1234
Ora, quando il frammento viene incollato alla fine, il codice HTML risultante è:

1234A

DIV div>
1
1234A
DIV div>
Questo è previsto come il codice HTML risultante è lo stesso del codice HTML copiato negli appunti. Tuttavia, se il frammento viene incollato nel mezzo del 1234, quindi un diverso HTML è resa:

12A
DIV34
1
12A
DIV34

Sorprendente comportamento dopo aver incollato nel mezzo del testo
Il comportamento sembra insolito: l’elemento

mancano totalmente contenuto incollato, mentre nel punto in cui
dovrebbe normalmente concludersi, un
tag apparso. Lo stesso comportamento si osserva con qualsiasi elemento HTML che ha una regola CSS: display: block. Questo sembrava davvero promettente, perché ciò che stiamo assistendo è una mutazione. E se la storia dei browser ci insegna qualcosa, è che le mutazioni spesso portano a vulnerabilità.

Dopo alcune indagini, elemento si è rivelato utile. Spesso è utile in vari bypassando disinfettanti perché introduce il cosiddetto “content straniera” e un po ‘di markup viene analizzato in modo diverso quando si tratta di un discendente di un elemento che in qualsiasi altra parte del codice HTML.

Diamo un’occhiata a un semplice esempio. In HTML parsing del

La conclusione è che il contenuto all’interno del


In questo caso, l’elemento

Quindi cerchiamo di prendere il seguente frammento di codice HTML:


1

che viene analizzato in:

L’albero DOM sembra sicura: la è all’interno dell’attributo titolo in modo che non viene eseguito il rendering. Tuttavia, dopo aver rimosso elemento, il parsing del codice HTML produce un albero DOM diverso:

Le esegue XSS payload come il style> tag di chiusura, che in origine era collocato nella attributo title, ora chiude la

Tornando a copiare e incollare, mi sono chiesto che cosa succede al contenuto degli appunti quando contiene un elemento che contiene un elemento figlio con style = display: block sapendo che quest’ultima porta ad una mutazione sul incollare. Ho creato il seguente frammento:

un b TEST
1
un b TEST

(Side-nota: tutti gli elementi hanno un nodo di testo a causa di cromo tende ad omettere elementi HTML completamente dopo aver incollato se hanno alcun testo)

Poi ho incollato nel bel mezzo di un editor che contiene solo un nodo di testo con i contenuti: “1234”. L’albero DOM dopo aver incollato era:

Si noti che la stringa “TEST” che inizialmente era all’interno dell’elemento (e, per estensione, il elemento) è posto al di fuori di dopo mutazione.

Così, il carico utile finale è:

un b c “> e
1
un b c “> e

E dopo incollandolo nel bel mezzo di un editor, ha creato la seguente struttura DOM:

Dopo la mutazione, l’elemento “fuggito” da attributo title ed è stata collocata nella struttura DOM senza alcuna sorta di sanificazione. Per dimostrare che l’exploit opere di Chromium Security Team, li ho fornito con il seguente video, che mostra posso innescare XSS su GMail, Wikipedia, e Blogger.

Google ha premiato il rapporto con una taglia di $ 2.000.

Cromo # 2 (perdita CSS)
Quando ho segnalato il XSS universale alla Chromium, ho detto come un lato nota che un altro modo di abusare negli appunti è quello di iniettare

Abusando fogli di stile a trapelare i dati da siti web non è una novità. Per esempio, nel 2018 Pepe Vila ha dimostrato che un singolo punto di iniezione è sufficiente a perdere i dati dal CSS, lo stesso trucco è stato poi riscoperto da d0nut nel 2019. Ho anche scritto un articolo su exfiltration dati CSS in Firefox tramite un unico punto di iniezione al All’inizio di quest’anno (anche se il titolo del post cita esplicitamente Firefox, lo stesso codice funziona anche per Chromium).

Quindi il mio compito era quello di convincere la gente di sicurezza di cromo che l’iniezione di stili tramite copia & incolla ha infatti implicazioni per la sicurezza. E l’ho fatto con il seguente video che dimostra che si può perdere l’indirizzo di posta elettronica attualmente collegato a Gmail.

Se si desidera capire come l’exploit esattamente opere, consultare l’articolo su exfiltration dati attraverso un singolo punto di iniezione. Per questo bug, Google ha deciso di emettere un premio di $ 10.000.

Ho segnalato più di due copia & incolla bug da Cromo (crbug / 1.040.755 e crbug / 1.065.761), uno a Safari e uno a bordo classico. Tuttavia, tutti questi bug sono molto simili, e considerando che non tutti sono fissi o de-ristretta, ho deciso di astenersi dal rivelare per il momento.

Firefox # (perdita di dati CSS) 1
Tuttavia, ci sono altri due bug Sono perfettamente bene di rivelare, che è accaduto in Firefox: CVE-2.019-17.016 e CVE-2.019-17.022. Entrambi sono stati fissati in Firefox 72, uscito il 7 gennaio 2020.

Firefox ha permesso incollare fogli di stile dagli appunti. Ad esempio, se copiamo il seguente codice HTML:

Si consideri il seguente snippet HTML:

Ho notato che Firefox strapazza la funzione CSS piuttosto oscuro che è la @namespace at-regola. Secondo MDN: “la regola @namespace è generalmente utile solo quando si tratta di documenti che contiene più spazi dei nomicome HTML5 con SVG in linea o MathML o XML che mescola più vocabolari”.

Ho creato un semplice foglio di stile con la regola @namespace:

Per dimostrare a Mozilla che l’exploit funziona davvero, ho creato un video che perde un CSRF gettone da una pagina di esempio. Consultare l’articolo di rubare dati con i CSS attraverso un singolo punto di iniezione in Firefox per scoprire come esattamente l’exploit sembrava.

Firefox # 2 (mutazione XSS)
Inoltre, ho riportato un altro problema a Firefox, rintracciato come CVE-2.019-17.022, che ha introdotto un XSS mutazione a Firefox.

La causa principale di questo problema è esattamente identico a quello precedente, ma questa volta viene sfruttata in modo diverso.

Supponiamo di avere il seguente foglio di stile:

textEditor.innerHTML = clipboardData.innerHTML;
1
textEditor.innerHTML = clipboardData.innerHTML;
allora è vulnerabile a XSS, perché l’elemento lascerebbe l’elemento

Ho dato un’occhiata a GitHub repo chiamato awesome-WYSIWYG per vedere se il comportamento di Firefox rende qualsiasi editor vulnerabili. E la ricerca non è stata troppo a lungo perché il primo editore dall’alto: Aloha Editor è accaduto a essere vulnerabile. Dopo aver incollato il payload summenzionato, il XSS attiva immediatamente.

Aloha Editor utilizza un out-of-screen

memorizzato in una variabile denominata $ APPUNTI:

var $ APPUNTI = $ ( ‘

‘Clip: rect (0px, 0px, 0px, 0px); ‘+
‘Width: 1px; altezza:. 1px; “> div> ‘) contentEditable (true);
1
2
3
var $ APPUNTI = $ ( ‘
‘Clip: rect (0px, 0px, 0px, 0px); ‘+
‘Width: 1px; altezza:. 1px; “> div> ‘) contentEditable (true);
(Fonte: github.com/alohaeditor/Aloha-Editor/blob/04c76a1013ae1c65af2ac34e5e95dfedda175f99/src/plugins/common/paste/lib/paste-plugin.js#L93)

Sul incollare il contenuto degli appunti viene incollato nella elemento, e poi gestite tramite la funzione handleContent che rimuove alcuni elementi:

handleContent: function (contenuto) {
var $ content;

if (typeof contenuti === ‘stringa’) {
$ Content = $ ( ‘

’ + contenuti + ‘ div>’);
} Else if (tenore instanceof $) {
$ Content = $ ( ‘
’) append (contenuto).;
}

if (THIS.Enabled) {
removeFormatting ($ content, this.strippedElements);
}

return $ content.html ();
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
handleContent: function (contenuto) {
var $ content;

if (typeof contenuti === ‘stringa’) {
$ Content = $ ( ‘

’ + contenuti + ‘ div>’);
} Else if (tenore instanceof $) {
$ Content = $ ( ‘
’) append (contenuto).;
}

if (THIS.Enabled) {
removeFormatting ($ content, this.strippedElements);
}

return $ content.html ();
}
I trigger XSS mutazione quando la variabile di contenuti (che contiene HTML pre-sterilizzate dal browser) è usato come un argomento nella funzione jQuery $. A questo punto il contenuto contiene:

Aloha Editor non è stato l’unico editor in cui è stato possibile attivare il XSS mutazione. Lascio come esercizio al lettore di trovare gli altri.

Mozilla mi ha ricompensato con una taglia combinato di $ 3.000 per questi due insetti.

Ora supponiamo che viviamo in un mondo perfetto in cui i browser fissati tutti i bypass disinfettante e non esistono più. Questo significa che siamo al sicuro quando siamo incollare i dati da siti web non attendibili? La risposta breve è: no.

Bugs in editor visuali
Un codice JavaScript può ignorare completamente processo di sanificazione del browser e di gestire manualmente. Questo approccio richiede l’ascolto di incollare evento, per esempio:

document.addEventListener ( ‘pasta’, evento => {
event.preventDefault ();
const html = event.clipboardData.getData ( ‘text / html’);
// gestisce l’html …
// … per esempio
someElement.innerHTML = html; // 😱
});
1
2
3
4
5
6
7
document.addEventListener ( ‘pasta’, evento => {
event.preventDefault ();
const html = event.clipboardData.getData ( ‘text / html’);
// gestisce l’html …
// … per esempio
someElement.innerHTML = html; // 😱
});
Nel frammento, il contenuto clipboard è assegnato alla variabile html, che, a sua volta, viene assegnato a innerHTML di un elemento, che porta a XSS.

In pratica ogni editore popolare WYSIWYG gestisce l’evento pasta da solo. Ci sono diversi motivi per farlo:

Rimozione di elementi pericolosi (come

TinyMCE
TinyMCE è auto-proclamata “il più avanzato editor WYSIWYG HTML” e, dalla mia esperienza, è infatti uno dei più popolari editor (se non il più).

Su incollare, TinyMCE gestisce il contenuto dal parsing del codice HTML, l’applicazione di alcune trasformazioni, e quindi la serializzazione di nuovo a HTML. TinyMCE non usa alcun parser HTML forniti in JavaScript (come DOMParser), ma si avvale di una propria soluzione.

Come esempio di TinyMCE sanificazione, si consideri il seguente snippet HTML da incollare dagli appunti:

grassetto b>
1
grassetto b>
TinyMCE analizza al seguente struttura DOM:

Poi decide che elemento dovrebbe essere sostituito con e il commento deve essere lasciato intatto. L’albero DOM viene serializzato in:

grassetto strong>
1
grassetto strong>
E questa stringa viene assegnato a outerHTML di un determinato elemento.

Fin qui tutto bene. Il problema con parser di TinyMCE è che non è riuscito a riconoscere che in HTML5 -!> È un commento finale valida. Così, il seguente codice HTML:

un -> b
1
un -> b
viene analizzato nelle seguenti albero per TinyMCE:

Dal momento che l’editor si assume l’albero è innocuo, è tornato serializzato alla stessa forma:

un -> b
1
un -> b
Ed è assegnato al outerHTML. Dopo l’assegnazione, è il turno del browser per analizzare il codice HTML e lo fa in modo diverso:

Dal momento che l’elemento appare nel documento, il XSS sparerà.

Ho segnalato il bug (e pochi altri) per TinyMCE e hanno pubblicato due avvisi di sicurezza:

github.com/tinymce/tinymce/security/advisories/GHSA-27gm-ghr9-4v95
github.com/tinymce/tinymce/security/advisories/GHSA-c78w-2gw7-gjv3
Se sei uno sviluppatore di un’applicazione che utilizza TinyMCE, assicuratevi di aggiornare alla versione 5.2.2 o successiva.

CKEditor 4
CKEditor 4 è un altro editor WYSIWYG molto popolare, che si pubblicizza comeil numero # 1 ricco editor di testo con il maggior numero di caratteristiche”.

CKEditor ha un interessante concetto di “proteggere” alcuni dati su come copiare in modo che esattamente la stessa marcatura viene incollato. Ad esempio, se il codice HTML all’interno di CKEditor ha un commento:

A B p>
1

A B p>
Poi, se si copia dall’editor, appunti conterrà il seguente codice HTML:

A B
1
A B
L’idea è che CKEditor vuole assicurarsi che il commento viene incollato così com’è, senza alcuna scrambling. Il problema (! Ancora una volta) è che CKEditor non sapeva che -!> Chiude il commento HTML, che permette di intrufolarsi markup arbitraria. Quindi, il seguente payload ha attivato l’XSS:

A -> B
1
A -> B
CKEditor presume che -!> è il testo del commento e incollato parola per parola, mentre ha chiuso il browser su -> e reso l’elemento .

Ho segnalato il bug a CKEditor ed è stato risolto nella versione 4.14.0.

Froala
Froala, secondo il suo sito ufficiale, è un editor WYSIWYG che “costruisce software di editing per lo sviluppo veloce con una migliore esperienza di sviluppatori e utenti in mente”.

Il bug che sto descrivendo è un 0-day e, come del 4 giugno 2020, ancora funziona nella versione corrente stabile. Ho segnalato il bug il 22 gennaio 2020, e l’unica risposta che ho ottenuto è stato: “Ho presentato questo problema per lo sviluppo, ma una linea temporale non è ancora stato stabilito per una correzione”. Ho chiesto in merito alla questione per tre volte, nel frattempo, senza alcun risultato.

Froala è colpevole di effettuare svariati processi di lavorazione HTML utilizzando espressioni regolari e l’elaborazione delle stringhe. Quello che sto mostrando qui di seguito è solo un problema che deriva da esso, ma sono sicuro che non ci sarà più.

Dopo aver incollato dagli appunti, Froala prende il codice HTML e (tra gli altri) eseguire le seguenti operazioni:

Sostituire tutte le partite di regex: /? (:?! () / gi con [FROALA.EDITOR.NOSCRIPT 0] (il numero viene incrementato se più tag si trovano). L’obiettivo del regex è quello di abbinare tutti gli elementi



1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22



It lets the browser sanitize the content from clipboard but then decides to remove all
1

Afterward, removal of