2.6 CVE-2003-1582
Microsoft Internet Information Services (IIS) 6.0, quando la risoluzione DNS è abilitata per gli indirizzi IP client, consente agli aggressori remoti di inserire testo arbitrario nei file di registro tramite una richiesta HTTP insieme a una risposta DNS predisposta, come dimostrato dall'iniezione di sequenze XSS, relative a un problema di "Corruzione del registro di ricerca inversa (ILLC)".
https://nvd.nist.gov/vuln/detail/CVE-2003-1582
Categorie
CWE-79 : Neutralizzazione impropria dell'input durante la generazione di pagine Web ("Scripting cross-site")
Il prodotto non neutralizza o neutralizza in modo errato l'input controllabile dall'utente prima che venga inserito nell'output utilizzato come pagina Web servita ad altri utenti. Abbreviazione comune di Cross-Site Scripting. Utilizzato come sinonimo di XSS memorizzato (tipo 2). Nei primi anni dopo la scoperta degli XSS, l'acronimo "CSS" era comunemente utilizzato. Tuttavia, questo acronimo generava confusione con "Cascading Style Sheets", per cui l'uso di questo acronimo è diminuito in modo significativo. Utilizzate strumenti di analisi statica automatizzati che mirano a questo tipo di debolezza. Molte tecniche moderne utilizzano l'analisi del flusso di dati per ridurre al minimo il numero di falsi positivi. Non si tratta di una soluzione perfetta, poiché non è possibile ottenere una precisione e una copertura del 100%, soprattutto quando sono coinvolti più componenti. Utilizzate l'XSS Cheat Sheet [REF-714] o strumenti di generazione automatica di test per lanciare un'ampia varietà di attacchi contro le vostre applicazioni web. Il Cheat Sheet contiene molte sottili variazioni XSS che sono specificamente mirate contro le difese XSS deboli. Comprendete tutte le potenziali aree in cui input non attendibili possono entrare nel vostro software: parametri o argomenti, cookie, qualsiasi cosa letta dalla rete, variabili d'ambiente, ricerche DNS inverse, risultati di query, intestazioni di richieste, componenti di URL, e-mail, file, nomi di file, database e qualsiasi sistema esterno che fornisca dati all'applicazione. Ricordate che tali input possono essere ottenuti indirettamente tramite chiamate API. Per qualsiasi controllo di sicurezza eseguito sul lato client, assicurarsi che tali controlli siano duplicati sul lato server, al fine di evitare CWE-602. Gli aggressori possono aggirare i controlli sul lato client modificando i valori dopo che i controlli sono stati eseguiti o modificando il client per rimuovere completamente i controlli sul lato client. In questo modo, i valori modificati verrebbero inviati al server. Se disponibili, utilizzare meccanismi strutturati che impongano automaticamente la separazione tra dati e codice. Questi meccanismi possono essere in grado di fornire automaticamente la citazione, la codifica e la convalida pertinenti, invece di affidarsi allo sviluppatore per fornire questa capacità in ogni punto in cui viene generato l'output. Con Struts, scrivere tutti i dati dei form beans con l'attributo filter del bean impostato su true. Per attenuare gli attacchi XSS contro il cookie di sessione dell'utente, impostare il cookie di sessione come HttpOnly. Nei browser che supportano la funzione HttpOnly (come le versioni più recenti di Internet Explorer e Firefox), questo attributo può impedire che il cookie di sessione dell'utente sia accessibile a script client-side malevoli che utilizzano document.cookie. Questa non è una soluzione completa, poiché HttpOnly non è supportato da tutti i browser. Inoltre, XMLHTTPRequest e altre potenti tecnologie dei browser forniscono accesso in lettura alle intestazioni HTTP, compresa l'intestazione Set-Cookie in cui è impostato il flag HttpOnly. Quando l'insieme di oggetti accettabili, come nomi di file o URL, è limitato o noto, creare una mappatura da un insieme di valori di input fissi (come gli ID numerici) ai nomi di file o URL effettivi e rifiutare tutti gli altri input. Utilizzare un firewall per applicazioni in grado di rilevare gli attacchi contro questa debolezza. Può essere utile nei casi in cui non sia possibile correggere il codice (perché controllato da terzi), come misura di prevenzione di emergenza mentre vengono applicate misure di sicurezza del software più complete o per fornire una difesa in profondità. Quando si utilizza PHP, configurare l'applicazione in modo che non utilizzi register_globals. Durante l'implementazione, sviluppate l'applicazione in modo che non faccia affidamento su questa funzione, ma fate attenzione a implementare un'emulazione di register_globals che è soggetta a debolezze come CWE-95, CWE-621 e problemi simili. Python Library Manager non neutralizzava sufficientemente un termine di ricerca fornito dall'utente, consentendo un XSS riflesso. La piattaforma di e-commerce basata su Python non evadeva il contenuto restituito nelle pagine di errore, consentendo attacchi Cross-Site Scripting riflessi. XSS universale nel sistema operativo mobile, come sfruttato in natura secondo CISA KEV. Catena: la convalida impropria dell'input (CWE-20) nel prodotto firewall porta a XSS (CWE-79), come sfruttato in natura secondo CISA KEV. L'interfaccia grafica di amministrazione consente XSS tramite cookie. Il programma di statistiche web consente XSS attraverso un'intestazione HTTP modificata. Il prodotto per l'analisi dei registri Web consente XSS attraverso un'intestazione HTTP Referer artigianale. Catena: il fallimento del meccanismo di protezione consente XSS Catena: denylist incompleto (CWE-184) controlla solo il tag "javascript:", consentendo XSS (CWE-79) utilizzando altri tag Catena: denylist incompleto (CWE-184) rimuove solo i tag SCRIPT, consentendo XSS (CWE-79) XSS riflesso utilizzando PATH_INFO in un URL XSS riflesso non gestito correttamente durante la generazione di un messaggio di errore XSS riflesso inviato tramite messaggio e-mail. XSS memorizzato in un prodotto di sicurezza. XSS memorizzato utilizzando una pagina wiki. XSS memorizzato in un'applicazione guestbook. XSS memorizzato in un'applicazione guestbook utilizzando un javascript: URI in un tag bbcode img. Chain: il file di libreria non è protetto contro una richiesta diretta (CWE-425), il che porta a XSS riflessi (CWE-79).
Riferimenti
CPE
| cpe |
avviare |
fine |
| Configuration 1 |
| cpe:2.3:a:microsoft:internet_information_server:6.0:*:*:*:*:*:*:* |
|
|
RIMEDIO
EXPLOITS
Exploit-db.com
| id |
descrizione |
data |
|
| Nessuna impresa nota |
Altro (github, ...)
CAPEC
Common Attack Pattern Enumerations and Classifications
| id |
descrizione |
gravità |
| 209 |
XSS Utilizzo mancata corrispondenza del tipo MIME
Un avversario crea un file con contenuto di scripting ma dove il tipo MIME specificato del file è tale che lo scripting non è previsto. L'avversario inganna la vittima facendole accedere ad un URL che risponde con il file di script. Alcuni browser rileveranno che il tipo MIME specificato del file non corrisponde al tipo reale del suo contenuto e passeranno automaticamente a utilizzare un interprete per il tipo di contenuto reale. Se il browser non invoca i filtri per gli script prima di fare questo, lo script dell'avversario può essere eseguito sul bersaglio non sterilizzato, possibilmente rivelando i cookie della vittima o eseguendo script arbitrari nel suo browser. [Utilizzando un browser o uno strumento automatizzato, un avversario segue tutti i link pubblici e le azioni su un sito web. Registrano tutte le aree che permettono ad un utente di caricare contenuti attraverso una richiesta HTTP POST. Questo si trova tipicamente nei blog o nei forum. [L'avversario utilizza i punti di ingresso raccolti nella fase "Explore" come una lista di obiettivi e carica file con contenuti di scripting, ma il cui tipo MIME è specificato come un tipo di file che non può eseguire contenuti di scripting. Se l'applicazione controlla solo il tipo MIME del file, potrebbe lasciar passare il file, causando l'esecuzione dello script da qualsiasi utente che accede al file. [Una volta che l'avversario ha determinato quali luoghi di caricamento dei file sono vulnerabili al mismatch del tipo MIME, caricherà uno script dannoso camuffato da un file non scripting. L'avversario può avere molti obiettivi, dal rubare ID di sessione, cookie, credenziali e contenuti di pagina da una vittima. [Affinché l'attacco abbia successo, la vittima deve visualizzare il contenuto dannoso memorizzato sulla pagina web. |
Media |
| 588 |
XSS basato su DOM
Questo tipo di attacco è una forma di Cross-Site Scripting (XSS) in cui uno script malevolo viene inserito nell'HTML lato client che viene analizzato da un browser web. Il contenuto servito da un'applicazione web vulnerabile include codice script utilizzato per manipolare il Document Object Model (DOM). Questo codice script o non convalida correttamente l'input, o non esegue una corretta codifica dell'output, creando così un'opportunità per un avversario di iniettare uno script dannoso e lanciare un attacco XSS. Una distinzione chiave tra gli altri attacchi XSS e gli attacchi basati su DOM è che negli altri attacchi XSS, lo script dannoso viene eseguito quando la pagina web vulnerabile viene inizialmente caricata, mentre un attacco basato su DOM viene eseguito dopo il caricamento della pagina. Un'altra distinzione degli attacchi basati su DOM è che in alcuni casi, lo script dannoso non viene mai inviato al server web vulnerabile. Un attacco come questo è garantito per bypassare qualsiasi tentativo di filtraggio lato server per proteggere gli utenti. [Utilizzando un browser o uno strumento automatizzato, un avversario segue tutti i collegamenti pubblici e le azioni su un sito web. Registra tutti i link, i moduli, le risorse a cui si accede e tutti gli altri potenziali punti di ingresso dell'applicazione web. [L'avversario utilizza i punti d'ingresso raccolti nella fase "Explore" come una lista di obiettivi e inietta vari payloads di script comuni e caratteri speciali per determinare se un punto d'ingresso rappresenta effettivamente una vulnerabilità e per caratterizzare la misura in cui la vulnerabilità può essere sfruttata. Specificamente per gli XSS basati su DOM, l'avversario cerca aree in cui l'input viene utilizzato per modificare direttamente il DOM. [Una volta che l'avversario ha determinato quali parametri sono vulnerabili agli XSS, creerà un URL dannoso contenente l'exploit XSS. L'avversario può avere molti obiettivi, dal rubare ID di sessione, cookie, credenziali e contenuti della pagina dalla vittima. Negli XSS basati sul DOM, lo script dannoso potrebbe anche non essere inviato al server, poiché il browser della vittima manipolerà il DOM stesso. Questo può aiutare ad evitare i meccanismi di rilevamento lato server. [Per far sì che l'attacco abbia successo, la vittima deve accedere all'URL dannoso. |
Molto alto |
| 591 |
XSS riflesso
Questo tipo di attacco è una forma di Cross-Site Scripting (XSS) in cui uno script dannoso viene "riflesso" da un'applicazione web vulnerabile e poi eseguito dal browser della vittima. Il processo inizia con un avversario che consegna uno script malevolo a una vittima e la convince a inviare lo script all'applicazione web vulnerabile. [Utilizzando un browser o uno strumento automatizzato, un avversario segue tutti i link pubblici e le azioni su un sito web. Registra tutti i link, i moduli, le risorse a cui si accede e tutti gli altri potenziali punti di ingresso dell'applicazione web. [L'avversario utilizza i punti d'ingresso raccolti nella fase "Explore" come una lista di obiettivi e inietta vari payloads di script comuni e caratteri speciali per determinare se un punto d'ingresso rappresenta effettivamente una vulnerabilità e per caratterizzare la misura in cui la vulnerabilità può essere sfruttata. [Una volta che l'avversario ha determinato quali parametri sono vulnerabili agli XSS, creerà un URL dannoso contenente l'exploit XSS. L'avversario può avere molti obiettivi, dal rubare ID di sessione, cookie, credenziali e contenuti della pagina dalla vittima. [Affinché l'attacco abbia successo, la vittima deve accedere all'URL dannoso. |
Molto alto |
| 592 |
XSS memorizzato
Un avversario utilizza una forma di Cross-site Scripting (XSS) in cui uno script dannoso viene "memorizzato" in modo persistente nell'archivio dati di un'applicazione Web vulnerabile come input valido. [Utilizzando un browser o uno strumento automatico, un avversario segue tutti i collegamenti e le azioni pubbliche di un sito Web. Registra tutti i collegamenti, i moduli, le risorse a cui si accede e tutti gli altri potenziali punti di ingresso dell'applicazione web. L'avversario cerca le aree in cui vengono memorizzati gli input dell'utente, come i profili utente, i carrelli della spesa, i file manager, i forum, i blog e i log. [L'avversario utilizza i punti di ingresso raccolti nella fase "Esplora" come elenco di obiettivi e inietta vari payload di script comuni e caratteri speciali per determinare se un punto di ingresso rappresenta effettivamente una vulnerabilità e per caratterizzare la misura in cui la vulnerabilità può essere sfruttata. [Una volta determinato quali posizioni memorizzate sono vulnerabili agli XSS, l'avversario interagisce con l'applicazione Web per memorizzare il contenuto dannoso. L'avversario può avere diversi obiettivi, come rubare gli ID di sessione, i cookie, le credenziali e il contenuto della pagina della vittima. [Affinché l'attacco abbia successo, la vittima deve visualizzare il contenuto dannoso memorizzato sulla pagina web. |
Molto alto |
| 63 |
Cross-Site Scripting (XSS)
Un avversario incorpora script dannosi nel contenuto che sarà servito ai browser web. L'obiettivo dell'attacco è che il software bersaglio, il browser lato client, esegua lo script con il livello di privilegio degli utenti. Un attacco di questo tipo sfrutta le vulnerabilità di un programma che vengono portate permettendo agli host remoti di eseguire codice e script. I browser web, per esempio, hanno alcuni semplici controlli di sicurezza, ma se un aggressore remoto è autorizzato a eseguire script (attraverso l'iniezione in contenuti generati dall'utente come le bacheche) allora questi controlli possono essere aggirati. Inoltre, questi attacchi sono molto difficili da rilevare per un utente finale. [Utilizzando un browser o uno strumento automatizzato, un attaccante segue tutti i collegamenti pubblici e le azioni su un sito web. Registra tutti i link, i moduli, le risorse a cui si accede e tutti gli altri potenziali punti di ingresso dell'applicazione web. [Sonda i potenziali punti d'ingresso identificati per la vulnerabilità XSS] L'attaccante usa i punti d'ingresso raccolti nella fase "Esplora" come una lista di obiettivi e inietta vari payload di script comuni per determinare se un punto d'ingresso rappresenta effettivamente una vulnerabilità e per caratterizzare la misura in cui la vulnerabilità può essere sfruttata. [Rubare ID di sessione, credenziali, contenuto della pagina, ecc.] Quando l'attaccante riesce a sfruttare la vulnerabilità, può scegliere di rubare le credenziali dell'utente per riutilizzarle o analizzarle in seguito. [Quando l'aggressore prende di mira l'applicazione corrente o un'altra (attraverso le vulnerabilità CSRF), sarà l'utente ad eseguire gli attacchi senza esserne consapevole. Questi attacchi sono per lo più rivolti alle falle della logica delle applicazioni, ma possono anche essere utilizzati per creare un attacco diffuso contro un particolare sito web sulla rete attuale dell'utente (Internet o meno). [Content spoofing] Manipolando il contenuto, l'attaccante prende di mira le informazioni che l'utente vorrebbe ottenere dal sito web. |
Molto alto |
| 85 |
Impronta AJAX
Questo attacco utilizza i frequenti roundtrip client-server nella conversazione Ajax per scansionare un sistema. Mentre Ajax non apre nuove vulnerabilità di per sé, le ottimizza dal punto di vista dell'attaccante. Un primo passo comune per un attaccante è il footprint dell'ambiente di destinazione per capire quali attacchi funzioneranno. Poiché il footprinting si basa sull'enumerazione, il modello di conversazione di richieste e risposte rapide e multiple che sono tipiche nelle applicazioni Ajax permettono ad un attaccante di cercare molte vulnerabilità, porte conosciute, posizioni di rete e così via. La conoscenza acquisita attraverso Ajax fingerprinting può essere utilizzata per supportare altri attacchi, come XSS. [Utilizzando un browser o uno strumento automatizzato, un avversario invia richieste ad una pagina web e registra la risposta HTML ricevuta. Gli avversari quindi analizzano l'HTML per identificare qualsiasi architettura JavaScript sottostante nota. Questo può aiutare nella mappatura delle vulnerabilità pubblicamente note alla pagina web e può anche aiutare l'avversario a indovinare l'architettura dell'applicazione e il funzionamento interno di un sistema. |
Debole |
MITRE
Sherlock® flash
Fotografate la vostra rete di computer in pochi clic !
La soluzione di audit Sherlock® flash consente di eseguire un audit per rafforzare la sicurezza delle risorse IT. Scansione delle vulnerabilità delle apparecchiature fisiche e virtuali. Pianificazione delle patch in base al livello di priorità e al tempo disponibile. Reporting dettagliato e intuitivo.
Scopri questa offerta
