Domanda:
Quanto è pericoloso XSS?
Sai Kumar
2019-04-01 08:26:47 UTC
view on stackexchange narkive permalink

Sono un ingegnere del software e ho guardato molti video su XSS.

Ma non riesco a capire quanto sia pericoloso se viene eseguito sul lato client e non sul lato server che contiene i database e molti file importanti.

I commenti non sono per discussioni estese;questa conversazione è stata [spostata in chat] (https://chat.stackexchange.com/rooms/92029/discussion-on-question-by-sai-kumar-how-dangerous-is-xss).
Undici risposte:
Goron
2019-04-01 11:04:37 UTC
view on stackexchange narkive permalink

Di seguito sono elencate le cose che un utente malintenzionato può fare se è presente una vulnerabilità XSS.

  • Ad-Jacking : se riesci a memorizzare XSS su un sito web, inserisci i tuoi annunci al suo interno per fare soldi;)
  • Click-jacking - Puoi creare un overlay nascosto su una pagina per dirottare i clic della vittima per eseguire azioni dannose .
  • Hijacking di sessione : è possibile accedere ai cookie HTTP da JavaScript se il flag SOLO HTTP non è presente nei cookie.

  • Spoofing dei contenuti : JavaScript ha pieno accesso al codice lato client di un'applicazione web e quindi puoi usarlo per mostrare / modificare il contenuto desiderato.

  • Raccolta delle credenziali : la parte più divertente. Puoi utilizzare un popup di fantasia per raccogliere le credenziali. Il firmware WiFi è stato aggiornato, inserisci nuovamente le tue credenziali per autenticarti.

  • Download forzati - Quindi la vittima non sta scaricando il tuo flash player dannoso da assolutamente-safe.com? Non preoccuparti, avrai più fortuna tentando di forzare un download dal sito web affidabile che la tua vittima sta visitando.

  • Crypto Mining - Sì, puoi usare la CPU della vittima per estrarre un po 'di bitcoin per te!

  • Bypassare la protezione CSRF : puoi effettuare richieste POST con JavaScript, puoi raccogliere e inviare un token CSRF con JavaScript, cos'altro ti serve?

  • Keylogging - Sai di cosa si tratta.

  • Registrazione dell'audio : richiede l'autorizzazione dell'utente ma si accede al microfono della vittima. Grazie a HTML5 e JavaScript.

  • Scattare foto - Richiede l'autorizzazione dell'utente ma accedi alla webcam della vittima. Grazie a HTML5 e JavaScript.

  • Posizione geografica : richiede l'autorizzazione dell'utente ma accedi alla posizione geografica della vittima. Grazie a HTML5 e JavaScript. Funziona meglio con i dispositivi con GPS.

  • Rubare i dati dell'archiviazione web HTML5 : HTML5 ha introdotto una nuova funzione, l'archiviazione web. Ora un sito web può memorizzare i dati nel browser per un uso successivo e, naturalmente, JavaScript può accedere a tale spazio di archiviazione tramite window.localStorage () e window.webStorage () Browser & System

  • Fingerprinting : JavaScript semplifica la ricerca del nome del browser, della versione, dei plug-in installati e delle relative versioni, del sistema operativo, dell'architettura, dell'ora del sistema, della lingua e della risoluzione dello schermo.

  • Scansione in rete : il browser della vittima può essere utilizzato in modo improprio per eseguire la scansione di porte e host con JavaScript.

  • Browser in crash - Sì! Puoi bloccare il browser inondandoli di ... roba.

  • Furto di informazioni : prendi le informazioni dalla pagina web e inviale al tuo server. Semplice!

  • Reindirizzamento : puoi utilizzare javascript per reindirizzare gli utenti a una pagina web di tua scelta.

  • Tabnapping : solo una versione stravagante del reindirizzamento. Ad esempio, se per più di un minuto non vengono ricevuti eventi relativi alla tastiera o al mouse, potrebbe significare che l'utente è afk e puoi sostituire di nascosto la pagina web corrente con una falsa.

  • Acquisizione di screenshot: grazie a HTML5 di nuovo, ora puoi acquisire uno screenshot di una pagina web. Gli strumenti di rilevamento XSS ciechi lo hanno fatto prima che fosse interessante.

  • Esegui azioni : stai controllando il browser,

Quindi ho una domanda ... Diciamo che un'app web aveva una vulnerabilità xss e qualcuno l'aveva usata per sfruttare un altro utente eseguendo un codice js dannoso.Supponiamo che questo codice chiave registri e invii le sequenze di tasti a un altro sito Web effettuando una richiesta.Ora questo codice js dannoso continuerà a funzionare finché il browser è aperto o continuerà a funzionare finché la scheda vulnerabile all'interno del browser è aperta?
Dipende ancora da come funziona il programma aggressore.fondamentalmente a seconda degli eventi dell'utente o l'attivazione del codice su intervalli di tempo specifici.
@SaiKumar Solo in quella scheda.
@SaiKumar In generale, una vulnerabilità XSS può fare qualsiasi cosa con il client che tu come amministratore del sito web puoi fare con il client.
Per i punti con "richiede autorizzazione" - va notato che se l'utente ha già dato l'autorizzazione alla pagina web, hai libero sfogo e non devi chiedere.
"scansione di rete" - non proprio.Puoi inviare richieste HTTP come un matto, ma il browser non ti consente di vedere la risposta a meno che un server HTTP non venga effettivamente eseguito nella destinazione _e_ consenta esplicitamente richieste cross-origin.Una porta chiusa ti sembra esattamente come un server SMTP completamente aperto.Questo, ovviamente, vale anche per la pagina web reale.
@JohnDvorak Sì, sono d'accordo con la scansione in rete.Ma la scansione delle porte può essere eseguita molto facilmente.Ci sono molti script open source per raggiungere questo obiettivo.
Ho appena controllato uno dei port scanner su Google.Utilizza gli elementi immagine per aggirare la politica.Non sono ancora sicuro di quante informazioni puoi ottenere in questo modo, ma interessante ...
Vale la pena menzionare le voci etichettate "richiede l'autorizzazione dell'utente": è probabile che l'utente autorizzi perché è un sito di cui si fida, e l'XSS su quel sito lo ottiene gratuitamente se quel sito è già autorizzato.Modifica: qualcun altro lo ha già detto in parte, scusa
@JohnDvorak Sei un esame f.ex.la dimensione di un'immagine, scaricabile da qualsiasi sito.O il mancato caricamento dell'immagine.È comunque una fuga di informazioni inevitabile nel modello di layout HTML, poiché il contenuto dell'immagine caricata determina la dimensione dell'elemento "" sulla pagina.
Margaret Bloom
2019-04-02 12:15:51 UTC
view on stackexchange narkive permalink

Forse un esempio di vita reale aiuterebbe a capire quanto possa essere pericoloso un difetto di sicurezza apparentemente minore, come XSS.

Come parte di una valutazione della sicurezza, la mia azienda è stata incaricata di provare ad accedere al personale del CEO e-mail. Sono riuscito a ottenere il suo indirizzo e-mail personale tramite alcuni OSint, ora si potrebbe fare uno spear phishing con una versione personalizzata di uno dei tanti malware che rubano informazioni ma ho prolungato un po 'più a lungo la fase di raccolta delle informazioni.

Si è scoperto che il CEO amava le barche e ne stava vendendo una in un sito di vendita di barche. Il sito sembra piuttosto amatoriale, mi sono registrato e ho scherzato un po '. E cosa ho trovato? Il sito ti consente di gestire la tua password precompilando un campo password con quella attuale, spinto da questo indago un po 'di più sul sito. Mi sono imbattuto in una vulnerabilità XSS memorizzata: quando rispondi a un'offerta puoi inserire codice HTML arbitrario, incluso lo scripting, in essa e verrà eseguito nel browser del lettore!

Sembra piuttosto "innocuo", non lo fa ' vero? Cosa succede se lo combini con la cattiva gestione della password?

Quindi ho creato uno script che recupera la pagina della password (è una richiesta intra-dominio, SOP è soddisfatto), estratto la password e le informazioni sul client (UA, OS e simili) e inviarlo a un mio C&C. Poi ho instillato un senso di urgenza al CEO scrivendo attentamente una e-mail informandoli della mia "intenzione" di acquistare.

Dopo un giorno ho ricevuto la password che hanno usato per accedere al sito delle barche. Come previsto era la stessa password usata per la loro posta elettronica (non c'era 2FA, non ricordo ancora se fosse una cosa) e sono stato in grado di accedere alla webmail (le informazioni del client sono state utilizzate per simulare un accesso legittimo , nel caso fosse necessario mantenere un profilo basso).

Per farla breve, un attacco non è un singolo passo atomico, è fatto di piccole conquiste. Se dai spazio al tuo avversario per un passo, non saprai mai cosa può fare da lì. Un XSS è spazio per l'attaccante, come hai visto un bel po '.

Steffen Ullrich
2019-04-01 09:26:38 UTC
view on stackexchange narkive permalink

Il codice controllato da un utente malintenzionato, che viene eseguito nel contesto dell'applicazione Web sul lato client, ha il pieno controllo su ciò che fa il client e può anche leggere il DOM della pagina HTML, ecc.

Ciò significa che può sia rubare segreti che si trovano all'interno di questa pagina (password, ecc.) Sia eseguire operazioni come client connesso (come acquistare qualcosa, inviare minacce di bombe in un client di posta, ecc.). Tieni presente che questo tipo di attività può spesso essere nascosto al cliente in modo che non si accorga di essere attualmente attaccato.

520
2019-04-01 21:09:16 UTC
view on stackexchange narkive permalink

Un attacco XSS non è un pericolo per il server. È un pericolo per il motivo per cui hai un server. Non in senso tecnico ma molto umano, poiché qualsiasi tipo di attacco XSS originato dal tuo sito di solito finisce con la tua reputazione nel cesso. Alcuni casi di test:

  • Qualcuno reindirizza dal tuo sito a una falsa pagina di accesso. Ora hai una potenziale violazione di massa della sicurezza degli account utente sul tuo sito.
  • Qualcuno mette un cryptominer sul tuo sito. Questo farà sì che le macchine dei tuoi visitatori facciano gli straordinari e, quando vengono rilevate, ti fa sembrare grossolanamente avido e / o grossolanamente incompetente come amministratore di sistema. Nessuno dei due è un bell'aspetto.
  • Qualcuno reindirizza il traffico dal tuo sito a un concorrente. Non dovrei dover spiegare perché questo non va bene.
  • Qualcuno inserisce un po 'di javascript che rende il tuo sito inutilizzabile o addirittura blocca i browser. Ancora una volta, dovrebbe essere ovvio il motivo per cui questo non va bene.
  • Qualcuno inserisce il codice DDOS nel tuo sito per provare a rimuovere il tuo sito o una terza parte. Se mirato a te, dovrebbe essere ovvio perché questo è un male. Se è rivolto a qualcun altro e il tuo sito è ritenuto colpevole, il tuo provider di hosting può interromperti se non aggiusti il ​​tuo sito per violazione del contratto.
  • Qualcuno sostituisce i tuoi annunci con i propri. Se fai affidamento sulle entrate pubblicitarie, queste stanno rubando quelle entrate.
  • Qualcuno lo usa per curiosare tra i tuoi utenti. Hel-lo, violazione del GDPR.
Vipul Nair
2019-04-01 10:54:17 UTC
view on stackexchange narkive permalink

Quando XSS divenne per la prima volta ampiamente conosciuto nella comunità della sicurezza delle applicazioni web, alcuni penetration tester professionisti erano inclini a considerare XSS come una vulnerabilità "debole"

fonte: Applicazione Web Hackers Handbook

XSS è un'iniezione di comandi dal lato client, come l'altro utente ha sottolineato, può risultare in qualsiasi azione che può essere eseguita dall'utente. Per lo più XSS viene utilizzato per il dirottamento della sessione in cui l'attaccante utilizzando javascript fa in modo che la vittima trasmetta i cookie di sessione a un server controllato dall'aggressore e da lì l'attaccante può eseguire il "session riding".

Ma XSS può anche portare a una completa acquisizione dell'applicazione. Considera uno scenario in cui inserisci javascript e viene memorizzato. L'amministratore quindi lo carica in un browser Web (di solito registri o CMS). Se è presente un XSS, ora hai i token della sessione di amministrazione. Ecco perché XSS può essere molto pericoloso.

Non solo XSS memorizzato, ma cosa succede se invii un URL dannoso all'amministratore?La stessa minaccia si applica.
Assolutamente, non l'ho scritto perché volevo solo aggiungere quello che ha scritto Steffen.
Philipp
2019-04-01 20:30:53 UTC
view on stackexchange narkive permalink

La maggior parte delle possibili conseguenze delle vulnerabilità XSS colpisce l'utente, non il server. Quindi, se non ti interessa che il tuo utente possa compromettere i propri account sul tuo sito web o che i tuoi utenti vedano contenuti sul tuo sito web che non provengono dal tuo server, ignora quelle vulnerabilità.

Ma se il tuo gli utenti dispongono dei diritti di amministratore, quindi una vulnerabilità XSS può facilmente portare ad azioni amministrative involontarie. Un classico caso è un visualizzatore di log nella tua area di amministrazione che non è a prova di XSS. Alcuni snippet javascript nei tuoi log di accesso potrebbero essere eseguiti dai tuoi amministratori ed eseguire azioni amministrative con il loro account. Questo è il motivo per cui a volte vedi frammenti di javascript nelle intestazioni HTTP dei bot che tentano di hackerare il tuo sito web.

H. Idden
2019-04-03 02:24:17 UTC
view on stackexchange narkive permalink

Per darti un esempio di vita reale in cui XSS è stato utilizzato per rilevare direttamente il server in un incidente circa 10 anni fa (anche se ho dimenticato il nome del sito Web (piccolo / poco importante) e dubito che esista più):

Segnala al webmaster: "Sul tuo sito web è presente una vulnerabilità XSS. Dovresti risolvere il problema. Come devo inviarti i dettagli?"

Risposta dell'aspirante webmaster: "Mostrami come lo useresti in modo improprio. Il mio server è super sicuro! Provalo se vuoi ma non avrai alcuna possibilità. "

Risposta del giornalista:" Allora dai un'occhiata alla pagina del mio profilo sul tuo sito web. "

Il webmaster lo ha fatto e improvvisamente l'intero sito web è morto. Quello che è successo? Il reporter ha utilizzato una vulnerabilità XSS per inserire il codice JavaScript nella pagina del suo profilo.

Il codice JavaScript (in esecuzione nel browser e nella sessione del webmaster) ha inviato richieste al server a:

  1. aggiungi un nuovo account con i diritti più elevati (a scopo dimostrativo)
  2. per rinominare i file PHP e le tabelle SQL sul server (il sito web aveva una sezione di amministrazione che lo consentiva per scopi amministrativi come gli aggiornamenti o installando widget simili a molti sistemi CMS)

Si sarebbero potuti arrecare ulteriori danni inviando una richiesta alla società di hosting per cancellare l'abbonamento del server e del dominio e trasferire denaro da il suo conto bancario (a condizione che il webmaster fosse registrato nell'hoster / registrar di dominio / banca e non avessero una protezione CSRF che non era così insolita 10 anni fa).

Inoltre, non dimenticare gli XSS-worm come il worm MySpace Samy che si diffonde su tutte le pagine del profilo e potrebbe danneggiare il tuo server o danneggiare i tuoi utenti.

Grazie.Ora ho capito chiaramente come si può usare xss per rompere un sito web.Ma come si rinominano i file php e le tabelle sql sul server?javascript può essere usato per rinominare un file seduto sul server?e se il file non si trovava nella stessa directory della pagina web?e possiamo eseguire query sql usando javascript?
Il sito Web aveva uno strumento di amministrazione Web simile a phpMyAdmin che consente di modificare tabelle SQL e file PHP con una GUI Web invece di richiedere SSH o simili.JavaScript ha inviato una richiesta simile a quella che avrebbe fatto lo strumento.I file in pericolo dipendono dalle capacità, dalla sicurezza e dalle autorizzazioni dello strumento di amministrazione.
User42
2019-04-01 13:06:48 UTC
view on stackexchange narkive permalink

Sembra che tu stia cercando un pericolo per il server (incluso SQL e così via), non per il client, quindi molti pericoli non si applicano.

Ma c'è un pericolo per il server da ciò che il client è autorizzato a fare sul server. Se il client ha il permesso di modificare il database, può farlo anche un utente malintenzionato. E lo stesso vale per tutto ciò che un client ha il permesso di fare sul server.

Kailash
2020-01-03 23:01:14 UTC
view on stackexchange narkive permalink

XSS stesso è pericoloso nel seguente senso:

  • L'ID sessione / cookie può essere un furto per ottenere pieno accesso agli account delle vittime.
  • Disfacimento temporaneo del sito web. Esecuzione di script JS dannosi (miner, card data stealer, key-logger ecc.)
  • L'utilizzo di framework di sfruttamento come Beef an attacker può eseguire alcuni OScall come l'apertura di webcam da remoto, la rotazione del microfono, il reindirizzamento di tutti i siti Web a siti Web dannosi ecc.
  • A volte XSS può essere utilizzato per rubare token segreti delle vittime, token CSRF (crosssite request forgery), chiavi API e quindi è possibile eseguire ulteriori sfruttamenti come gli attacchi CSRF.

Questo blog e questo mostrano come viene utilizzato l'attacco XSS per eseguire l'iniezione SQL in un'applicazione web.

Fatta eccezione per SQLi, questi sono già trattati nella risposta accettata
WoJ
2019-04-03 19:55:44 UTC
view on stackexchange narkive permalink

Hai da altre risposte un ottimo elenco di ragioni tecniche per cui XSS è un problema. Darò un'altra prospettiva.

XSS è una vulnerabilità che è abbastanza facile da introdurre nel codice ed è rilevabile dagli scanner. Questo è probabilmente uno dei motivi per cui è relativamente ben noto al "grande pubblico", inclusi i giornalisti (nel senso di "ne ho sentito parlare").

Se se ne hai uno disponibile pubblicamente, potrebbe essere descritto come

Sai Kumar LLC ha un sito estremamente vulnerabile, perché ha un XSS. XSS è una vulnerabilità molto pericolosa. Molto. Lo è.

Consente il furto di tutti i tuoi dati. Lo fa. The͟ ̨da҉t͘a̵ ͢haś ̴al͞r̀eadreviewsy͠b̷e̷e̶n̨ s͝t͜o̢l͝e͜n. Įt̨ ̷ha̵s.

Puoi quindi fare tutti i tipi di danza del ventre spiegando che non è la vulnerabilità, l'erratum verrà pubblicato nel carattere 3 pt a pagina 74, in grigio. >

Questo è il motivo per cui sollevo sistematicamente il CVSS dei risultati XSS sui miei siti web pubblici (quando vengono rilevati da un pentest, una scansione o altri test).

Tatum
2020-01-03 18:15:19 UTC
view on stackexchange narkive permalink

Lo scripting cross-site memorizzato è molto rischioso per una serie di motivi: il payload non è più visibile per il filtro XSS del browser. Gli utenti possono per caso attivare il payload se accedono alla pagina interessata, mentre per sfruttare XSS riflesso sarebbero necessari un URL predisposto o input di modulo precisi.



Questa domanda e risposta è stata tradotta automaticamente dalla lingua inglese. Il contenuto originale è disponibile su stackexchange, che ringraziamo per la licenza cc by-sa 4.0 con cui è distribuito.
Loading...