Perché vietare XSS invece di segnalarlo?

Question

Perché vietare XSS invece di segnalarlo?

#1 da (7 voti)
#2 da (2 voti)

1

Considera un browser che consente a XMLHttpRequest scaricato da foo.net di effettuare richieste a bar.net, ma allega un XHR-Origin: http://foo.net (o forse un valore più descrittivo come http://foo.net/trustedapp.js ). L'XHR non poteva toccare quell'intestazione e il server poteva impostare le regole in base alla provenienza del codice di istanziazione XHR.

Poiché le specifiche del W3C (anche se rilassate con CORS) sono più estreme di questo, cosa hanno trovato sbagliato in questa tecnica? Quali vulnerabilità esistono che richiedono veramente un divieto XSS?

javascript http xss

posta Jordan 09.08.2012 - 06:14

fonte

2 risposte

2

What vulnerabilities exist that truly require a [Cross-Site Request] ban?

XHR come implementato porta automaticamente i cookie alla richiesta. Ciò significa che se il server presuppone che le richieste che hanno il cookie appropriato provengano da una pagina servita dai loro server, sono vulnerabili a csrf (sito di richiesta di falsificazione tra siti). Poiché XHR consente allo script invocante di ispezionare a livello di codice il risultato in modo che i tag <form> non lo facciano, XHR cross-site consente gli exploit che hanno infranto le ipotesi formulate da molti scrittori di server prima che AJAX diventi noto.

A causa di queste vecchie ipotesi, CORS e meccanismi concorrenti consentono ai siti di optare per l'accesso API programmatico e l'inoltro delle credenziali.

risposta data 13.08.2012 - 17:11

fonte

Leggi altre domande sui tag javascript http xss

Pulendo completamente un HDD (cioè non è recuperabile) [duplicato] È bruteforcing l'ultimo carattere di un sale una buona idea?

score 7 · Accepted Answer

Ci sono siti web là fuori, che non saranno aggiornati non appena il primo browser supporta la tua proposta. Questi siti non controllano l'intestazione XHR-Origin e sono quindi vulnerabili.

Esempio di vulnerabilità

Supponiamo che tu abbia effettuato l'accesso alla tua banca. Senza uscire, visiti un altro sito web. Questo sito Web invia una richiesta XHR alla tua banca per richiedere una risposta JSON, che viene utilizzata nella visualizzazione della cronologia dell'account.

Sì, questa richiesta avrà un'intestazione XHR-Origin, ma se il software della banca non viene regolato, rivelerà dati sensibili.

Quindi è responsabilità del browser non interrompere le restrizioni SOP esistenti.

CORS è completamente compatibile SOP?

Le specifiche CORS fanno una serie di eccezioni per le quali non è richiesto il controllo di preflight. Quelli si basano su situazioni in cui il SOP non è mai stato applicato nello psat (per esempio nel modulo di invio).

Il problema nella bozza corrente è che si basa esclusivamente sull'intestazione Content-Type, ma le applicazioni web tendono a ignorarlo.

C'è stata una bella chiacchierata di Shreeraj Shah a Blackhat Europe 2012 su HTML5 Le 10 principali minacce: attacchi furtivi e exploit silenziosi