Diventa Autore per CoreTech | Scopri di più





Scripting tra siti (XSS)

18/11/21 CoreTech Blog

Cross-site Scripting (XSS) è un attacco di iniezione di codice lato client . L'autore dell'attacco mira a eseguire script dannosi in un browser Web della vittima includendo codice dannoso in una pagina Web o un'applicazione Web legittima. L'attacco vero e proprio si verifica quando la vittima visita la pagina Web o l'applicazione Web che esegue il codice dannoso. La pagina web o l'applicazione web diventa un veicolo per consegnare lo script dannoso al browser dell'utente. I veicoli vulnerabili comunemente utilizzati per gli attacchi di Cross-site Scripting sono forum, bacheche e pagine Web che consentono commenti.

Una pagina Web o un'applicazione Web è vulnerabile a XSS se utilizza input utente non sanificato nell'output che genera. Questo input dell'utente deve quindi essere analizzato dal browser della vittima. Gli attacchi XSS sono possibili in VBScript, ActiveX, Flash e persino CSS. Tuttavia, sono più comuni in JavaScript, principalmente perché JavaScript è fondamentale per la maggior parte delle esperienze di navigazione.

"Lo scripting cross-site non è il problema dell'utente?"

Se un utente malintenzionato può abusare di una vulnerabilità XSS su una pagina Web per eseguire JavaScript arbitrario nel browser di un utente, la sicurezza di quel sito Web vulnerabile o dell'applicazione Web vulnerabile e dei suoi utenti è stata compromessa. XSS non è un problema dell'utente come qualsiasi altra vulnerabilità di sicurezza. Se colpisce i tuoi utenti, colpisce te.

Il cross-site Scripting può anche essere usato per deturpare un sito web invece di prendere di mira l'utente. L'autore dell'attacco può utilizzare script iniettati per modificare il contenuto del sito Web o persino reindirizzare il browser a un'altra pagina Web, ad esempio una che contiene codice dannoso.

Cosa può fare l'attaccante con JavaScript?

Le vulnerabilità XSS sono percepite come meno pericolose rispetto, ad esempio, alle vulnerabilità SQL Injection. Le conseguenze della capacità di eseguire JavaScript su una pagina Web potrebbero non sembrare disastrose all'inizio. La maggior parte dei browser Web esegue JavaScript in un ambiente strettamente controllato. JavaScript ha un accesso limitato al sistema operativo dell'utente e ai file dell'utente. Tuttavia, JavaScript può comunque essere pericoloso se utilizzato in modo improprio come parte di contenuti dannosi:

  • JavaScript dannoso ha accesso a tutti gli oggetti a cui ha accesso il resto della pagina web. Ciò include l'accesso ai cookie dell'utente. I cookie vengono spesso utilizzati per memorizzare token di sessione. Se un utente malintenzionato può ottenere il cookie di sessione di un utente, può impersonare quell'utente, eseguire azioni per conto dell'utente e ottenere l'accesso ai dati sensibili dell'utente.
  • JavaScript può leggere il DOM del browser e apportarvi modifiche arbitrarie. Fortunatamente, questo è possibile solo all'interno della pagina in cui è in esecuzione JavaScript.
  • JavaScript può utilizzare l'XMLHttpRequestoggetto per inviare richieste HTTP con contenuto arbitrario a destinazioni arbitrarie.
  • JavaScript nei browser moderni può utilizzare le API HTML5. Ad esempio, può accedere alla geolocalizzazione, alla webcam, al microfono e persino a file specifici dell'utente dal file system dell'utente. La maggior parte di queste API richiede l'attivazione dell'utente, ma l'autore dell'attacco può utilizzare l'ingegneria sociale per aggirare tale limitazione.

Quanto sopra, in combinazione con l'ingegneria sociale, consente ai criminali di eseguire attacchi avanzati tra cui il furto di cookie, l'installazione di trojan, keylogging, phishing e furto di identità. Le vulnerabilità XSS forniscono il terreno perfetto per intensificare gli attacchi a quelli più gravi. Cross-site Scripting può essere utilizzato anche in combinazione con altri tipi di attacchi, ad esempio Cross-Site Request Forgery (CSRF) .

Esistono diversi tipi di attacchi Cross-site Scripting: XSS archiviato/persistente, XSS riflesso/non persistente e XSS basato su DOM. Puoi leggere di più su di loro in un articolo intitolato Tipi di XSS.

Come funziona lo scripting cross-site

Ci sono due fasi per un tipico attacco XSS:

  1. Per eseguire codice JavaScript dannoso nel browser di una vittima, un utente malintenzionato deve prima trovare un modo per iniettare codice dannoso (payload) in una pagina Web visitata dalla vittima.
  2. Successivamente, la vittima deve visitare la pagina Web con il codice dannoso. Se l'attacco è diretto a determinate vittime, l'autore dell'attacco può utilizzare l'ingegneria sociale e/o il phishing per inviare un URL dannoso alla vittima.

Affinché il primo passaggio sia possibile, il sito Web vulnerabile deve includere direttamente l'input dell'utente nelle sue pagine. Un utente malintenzionato può quindi inserire una stringa dannosa che verrà utilizzata all'interno della pagina Web e trattata come codice sorgente dal browser della vittima. Esistono anche varianti di attacchi XSS in cui l'attaccante induce l'utente a visitare un URL utilizzando l'ingegneria sociale e il payload fa parte del collegamento su cui l'utente fa clic.

Come prevenire XSS

Per proteggerti da XSS, devi disinfettare il tuo input. Il codice dell'applicazione non dovrebbe mai inviare i dati ricevuti come input direttamente al browser senza verificarne la presenza di codice dannoso.


Articoli su Sicurezza

Sicurezza aziendale: da cosa è minacciata e come proteggerla?Il threat modeling per la sicurezza delle applicazioniScanner di vulnerabilità: ecco come funzionanoWeb security: 5 motivi per cui è essenziale contro i ransomwareChe cos'è DevSecOps e come dovrebbe funzionare?Test di penetrazione vs scansione delle vulnerabilitàConsiderazioni sui test di correzione delle applicazioni WebQuattro modi in cui l'analisi AppSec aiuta i tuoi professionisti DevSecOpsQuattro modi per combattere il divario di competenze di sicurezza informaticaDove i framework di cybersecurity incontrano la sicurezza webCome costruire un piano di risposta agli incidenti informaticiRendi i tuoi utenti parte della soluzione di sicurezza webSei l'unico che può proteggere le tue applicazioni webNuovo studio di settore: il 70% dei team salta i passaggi di sicurezzaConvergenza Dev-Sec: i progressi e le sfide sulla strada per garantire l'innovazioneAggiornamento FISMA: cosa sta cambiando e perché è importanteChe cos'è la sicurezza continua delle applicazioni Web?Sei l'unico che può proteggere le tue applicazioni webCos'è la sicurezza del sito Web: come proteggere il tuo sito Web dall'hackingRendi i tuoi utenti parte della soluzione di sicurezza webConvergenza Dev-Sec: la ricerca illustra i progressi per garantire l'innovazioneAggiornamento FISMA: cosa sta cambiando e perché è importanteChe cos'è la sicurezza continua delle applicazioni Web?La differenza tra XSS e CSRFNuovo studio di settore: il 70% dei team salta i passaggi di sicurezzaPrevenzione e mitigazione XSSStop ai compromessi sulla sicurezza delle applicazioni webSfatare 5 miti sulla sicurezza informaticaBasta compromessi sulla sicurezza delle applicazioni webNozioni di base sulla sicurezza web: la tua applicazione web è sicura?Che cos'è l'iniezione dell’header HTTP?Fare shift left o no?Individuazione e correzione di falle di sicurezza in software di terze partiClassi di vulnerabilità Web nel contesto delle certificazioniScripting tra siti (XSS)Che cos'è un attacco CSRFChe cos'è una SQL Injection (SQLi) e come prevenirlaAttacchi di attraversamento di directoryChe cos'è la falsificazione delle richieste lato server (SSRF)?7 migliori pratiche per la sicurezza delle applicazioni WebBlack Hat 2021: la più grande minaccia alla sicurezza informaticaÈ ben fatto? Chiedi allo sviluppatore!Scegli la soluzione di sicurezza delle applicazioni web che fa per teSicurezza fai-da-te: lo stai facendo bene?Sulla sicurezza delle applicazioni web professionali per MSSPLa cattiva comunicazione è al centro delle sfide di AppSecImpostazione e raggiungimento degli obiettivi di sicurezza delle applicazioniMetriche di sicurezza informatica per le applicazioni WebCome evitare attacchi alla supply chainPerché la maggior parte delle misure di sicurezza delle applicazioni fallisceVuoi che la tua sicurezza sia costruita su scuse?Cos'è SCA e perché ne hai bisognoLa scansione ad hoc non è sufficienteEsposizione dei dati sensibili: come si verificano le violazioniHai paura dei test di sicurezza nell'SDLC?Vantaggi di Web Asset DiscoveryStrumenti di scansione delle vulnerabilità: perché non open source?Protezione WAF - Ottieni il massimo dal tuo firewall per applicazioni webL'errore di comunicazione è al centro delle sfide di AppSecDebugger remoti come vettore di attaccoDAST è una parte essenziale di un programma completo per la sicurezza delle applicazioniCome difendersi dagli attacchi recenti su Microsoft Exchange5 principali vantaggi dei primi test di sicurezzaTecniche di attacco Denial-of-Service con avvelenamento della cacheQuali principali attacchi web possiamo aspettarci nella nuova top 10 di OWASP?Hack di SolarWindsPillole di Sicurezza | Episodio 38Pillole di Sicurezza | Episodio 37Perché gli sviluppatori evitano la sicurezza e cosa puoi fare al riguardoPillole di Sicurezza | Episodio 36Cos'è l'attacco RUDYCos'è la navigazione forzataCome gli scanner trovano le vulnerabilitàPillole di Sicurezza | Episodio 34Pillole di Sicurezza | Episodio 35Come eseguire il benchmark di uno scanner di vulnerabilità Web?Pillole di Sicurezza | Episodio 33Pillole di Sicurezza | Episodio 325 proposte di vendita comuni sulla sicurezza delle applicazioni web5 motivi per non fare affidamento sui programmi BountyPillole di Sicurezza | Episodio 315 motivi per cui la sicurezza web è importante quanto la sicurezza degli endpointPillole di Sicurezza | Episodio 305 motivi per cui la sicurezza web è importante per evitare il ransomwarePillole di Sicurezza | Episodio 293 motivi per cui DAST è il migliore per la sicurezza delle applicazioni WebPillole di Sicurezza | Episodio 28Pillole di Sicurezza | Episodio 27Pillole di Sicurezza | Episodio 24Pillole di Sicurezza | Episodio 25Pillole di Sicurezza | Episodio 21Pillole di Sicurezza | Episodio 22Pillole di Sicurezza | Episodio 20Pillole di Sicurezza | Episodio 17Il flag HttpOnly: protezione dei cookie da XSSPillole di Sicurezza | Episodio 16Il Bug Heartbleed – I vecchi Bug sono duri a morirePillole di Sicurezza | Episodio 15Pillole di Sicurezza | Episodio 14Pillole di Sicurezza | Episodio 13Pillole di Sicurezza | Episodio 12Pillole di Sicurezza | Episodio 11Pillole di Sicurezza | Episodio 10Sicurezza delle reti: gli hacker puntano CitrixCyber hacking: la Germania chiede l’intervento dell’UESicurezza informatica: Cisco rilascia aggiornamentiOcchio al cryptojacking: malware infiltrato in Docker HubSIGRed: bug di sistema in Windows Server scovato dopo 17 anniPillole di Sicurezza | Episodio 9Summit Live - Disponibili le registrazioni delle live di MonteleoneCriminalità informatica: Schmersal sventa un cyber-attaccoPillole di Sicurezza | Episodio 8Pillole di Sicurezza | Episodio 7Analisi pratica dei rischi per il SysAdmin, DevOps e Dev | Summit LivePillole di Sicurezza | Episodio 6Pillole di Sicurezza | Episodio 5Pillole di Sicurezza | Episodio 4Pillole di Sicurezza | Episodio 3Pillole di Sicurezza | Episodio 2Pillole di Sicurezza | Episodio 1Pillole di Sicurezza | Episodio 23