Sono entrambi attacchi cross-script scripting?

Question

Sono entrambi attacchi cross-script scripting?

#1 da (5 voti)
#2 da (4 voti)

3

Ho ricevuto una recente recensione sulla sicurezza di un sito Web che menzionava una vulnerabilità di cross-frame scripting. In breve, ha menzionato che un sito dannoso potrebbe caricare la pagina in un iframe, ingannando l'utente a pensare che siano nella pagina legittima per l'applicazione, mentre sovrappone i controlli e tale da raccogliere dati e svolgere altre attività dannose. Ma ho anche sentito che un XFS è quando un attacco XSS viene utilizzato per iniettare un iframe nell'applicazione che punta a un sito dannoso che consente al sito malevolo caricato nel frame di raccogliere dati da quelli che utilizzano l'applicazione e altri malintenzionati attività.

Quindi, sono questi entrambi gli attacchi di cross frame scripting perché entrambi usano iframe come elemento chiave? O è solo il primo attacco a XFS mentre il secondo è considerato una versione di XSS usando iframe?

P.S. Sia XSS che CSRF hanno tag, esiste un motivo per cui XFS non lo fa?

javascript xss cross-frame-scripting

posta Lawtonfogle 05.11.2013 - 17:44

fonte

2 risposte

Leggi altre domande sui tag javascript xss cross-frame-scripting

PCI DSS 2.0 e chiavi ssh Il frazionamento di una chiave AES è un problema?

score 5 · Answer 1

Anche se questa è una vecchia domanda, sto aggiungendo una risposta per i futuri spettatori.

"Cross-Frame Scripting" è fondamentalmente una perdita di dati che può accadere quando un utente malintenzionato inserisce il sito Web di una vittima in un frame all'interno del proprio sito Web e monitora / spiare le attività sul sito Web incorniciato. Un utente malintenzionato può registrare un listener JavaScript che ascolta tutti gli eventi chiave nella pagina. Lo spionaggio è possibile perché, il browser (buggy) notifica l'ascoltatore di eventi chiave anche dalla pagina web della vittima incorniciata. Pertanto, l'utente malintenzionato può incorporare la pagina di accesso della vittima nel proprio sito Web (in iframe ) e ottenere così le credenziali di accesso di una vittima innocente.

"Cross-Site Scripting", d'altra parte è in realtà più un'esecuzione forzata di JavaScript in cui un utente malintenzionato inietta / riflette il JavaScript dannoso che viene poi eseguito sul browser del client.

La prevenzione

XFS ruota attorno al frame-busting o aggiunge x-frame-options nelle intestazioni HTTP, uguale a DENY (che informa il browser di non incorniciare mai il sito Web) o sameorigin (frame solo se nello stesso contesto) . La prevenzione di XSS , tuttavia, riguarda maggiormente la disinfezione degli input.

Detto questo, nello scenario che hai descritto, il primo caso è un esempio di attacco XFS , mentre il secondo caso può essere considerato come un esempio di attacco XSS che coinvolge i frame.

score 4 · Answer 2

Una vulnerabilità non esiste finché qualcuno non crea una Prova di concetto o un metodo per sfruttare un determinato difetto del software.

"Cross-Frame Scripting" non esiste ed è un nome orribile. Detto questo, OWASP ha una voce disorganizzata per Cross-Frame Scripting .

I frame hanno i diritti di scripting e le protezioni garantite dalla politica Same-Origin . Uno script eseguito su un genitore non può leggere il contenuto di un iframe secondario che è di un altro dominio. gli iframe possono essere utili per sfruttare XSS, ma lo sono anche i tag <form> e <input> .

Questo strumento probabilmente sta segnalando clickjacking , che può essere sfruttato con o senza JavaScript. Per impedire il clickjacking basta aggiungere l'elemento di intestazione HTTP: x-frame-options: sameorigin . È molto facile per uno strumento di sicurezza scritto in modo insufficiente segnalare la mancanza di x-frame-options come vulnerabilità senza prendere in considerazione se è effettivamente sfruttabile.

(XSS e CSRF hanno tag su security.se perché sono reali. "XFS" è un errore e non ci sarà mai questo tag su security.se.)