Quali sono i possibili vettori di attacco per lo scripting cross-site riflesso?

Question

Wikipedia fornisce information about one of the most common scenarios per lo sfruttamento di un sito croce scripting attacco riflette - con un certo grado di ingegneria sociale per indurre ignari utenti a fare clic su un link maligno:

1. Alice visita spesso un particolare sito web, che è ospitato da Bob . Il sito web di Bob consente ad Alice di accedere con una coppia nome utente/password e memorizza i dati sensibili , ad esempio la fatturazione informazioni.
2. Mallory osserva che il sito Web di Bob contiene una vulnerabilità XSS riflessa.
3. Mallory crea un URL per sfruttare la vulnerabilità e invia ad Alice un'e-mail , allettandola a fare clic su un collegamento per l'URL con falsi pretesti. Questo URL punterà al sito Web di Bob, ma conterrà il codice dannoso di Mallory, che il sito Web rifletterà.
4. Alice visita l'URL fornito da Mallory mentre è collegato al sito Web di Bob .
5. Lo script dannoso incorporato nell'URL viene eseguito nel browser di Alice, come se provenisse direttamente dal server Bob (questa è la reale vulnerabilità XSS ). Lo script può essere utilizzato per inviare il cookie di sessione di Alice a Mallory. Mallory può quindi utilizzare il cookie di sessione per rubare le informazioni sensibili disponibili ad Alice (credenziali di autenticazione, fatturazione informazioni, ecc.) Senza che Alice ne sia a conoscenza.

Ora, questo è di solito tende ad essere molto buono esempio quando il sito sembra essere una pagina-driven applicazione - la vulnerabilità viene sfruttata da ottenere l'utente di inviare un payload dannoso per l'applicazione (ancora più importante , mediante l'emissione di una richiesta GET dopo l'accesso) che viene riflessa nella risposta.

Ci sono dei vettori di attacco più interessanti, specialmente quelli da considerare quando l'applicazione utilizza un sacco di AJAX con la maggior parte delle richieste fatte su HTTP POST?

EDIT

Nel caso in cui non sono stato chiaro, mi piacerebbe conoscere i vari tipi di attacchi vettori applicabili alle riflette attacchi XSS, soprattutto quando il livello sul lato client dell'applicazione è implementata in modo diverso . Le applicazioni basate sulla pagina avrebbero un vettore di attacco che coinvolge le richieste HTTP GET emesse da un utente, ma sarebbe interessante sapere come questo funzioni per le applicazioni thick client, specialmente quelle che utilizzano oggetti XMLHttpRequest che emettono le richieste HTTP POST. Diversi meccanismi utilizzati nel rendering lato client ovviamente giustificano lo studio di diversi vettori di attacco. In alcuni casi, potrebbero non esserci vettori di attacco applicabili; la domanda è espressa per suscitare una tale risposta.

Answer 1

Sì, in effetti ci sono alcune varianti dell'attacco XSS riflettente. Principalmente è il Samy Worm. In breve, Samy ha usato XSS per sparare a XHR su MySpace.com per leggere il token CSRF e creare una richiesta POST. In realtà questo è un modello di attacco generale che è utile per attaccare siti che utilizzano httponly cookies. Poiché l'uso dei cookie httponly diventa più popolare, così sarà questo modello di attacco.

Un altro carico utile xss è XSS Shell. Ciò fornisce all'utente malintenzionato un canale interattivo per il browser.

XSS viene utilizzato per consegnare un attacco "Drive-By-Download".

Xss può essere utilizzato anche su fake the news. Con xss contro news sources trovato regolarmente, questo è un problema piuttosto serio.

Modifica: Potresti anche essere interessato a come la fondazione Apache got owned utilizza xss e tinyurl. Here è un exploit che ho scritto che utilizza un attacco in stile Samy per ottenere CSRF.

Answer 2

XSS riflesso si verifica quando una pagina visualizza input utente malintenzionato. La domanda "quali sono i vettori di attacco?" è quindi sinonimo di "quale input dell'utente può ricevere una pagina?"

Alcune fonti sono:

• La stringa di query di una richiesta GET che possono provenire da:
  • un URL in un messaggio email
  • un redirect (tramite js, 301 risposta, o meta tag) da un sito hackerato o dannoso
• Il corpo di una richiesta POST che possono provenire da:
  • una richiesta POST AJAX da qualsiasi dominio (la stessa politica di origine non interrompe la richiesta, solo analizzando la risposta)
  • Qualsiasi modulo con method = "POST" e action = "XSSed_site.com". I moduli possono essere inviati tramite js, o facendo clic su un pulsante che potrebbe essere fatto usando click-jacking.
• Altre forme di input come ad esempio:
  • file js esterni come selezionatori di tabella o librerie che la pagina attaccato sta usando
  • comunicazione server-to-server che viene visualizzato sulla pagina attaccato
  • eventuali altri dati visualizzati sulla pagina attaccati che può essere modificato da un aggressore

Mi rendo conto che la sezione "Altre forme di input" sembra più una vulnerabilità XSS memorizzata, ma ogni applicazione è unica e alcuni possono tradurre l'input dell'utente in come i pezzi esterni vengono composti nella pagina (quindi riflessi).

Una stringa di query in una richiesta GET da una e-mail di phishing non è certamente l'unico vettore per XSS riflesso (buona domanda però).

Answer 3

benlbroussard lo ha già toccato, ma voglio reiterarlo a causa dell'importanza. Fat client, thin client, POST, GET, PUT; nessuna di queste cose è importante. Un buco XSS si basa su un sito che restituisce erroneamente qualche input a qualcuno.

Se stai cercando un attacco rigorosamente riflesso, il payload non deve essere memorizzato in nessuna parte nell'app di destinazione.In tal caso, penso che tu abbia ragione che un cliente grasso tenderà ad essere più resistente perché un GET è il modo più semplice per avviare un attacco XSS riflesso.

Per quanto riguarda più vettori di attacco, una cosa interessante sull'architettura Fat Client è la codifica di entità. Un thin client può essere un'entità che codifichi tutto e si faccia con esso, con grande beneficio. Un fat client deve codificare la risposta a un GET iniziale, ma le richieste asincrone con risposte intestate a JavaScript non possono essere (interamente) codificate e JS valide. Questo avanti e indietro aumenta la possibilità di non codificare qualcosa che dovrebbe essere, che è un grande passo verso la creazione di un vettore XSS.

Ha senso?

Carl