Perché CVSSv2 non considera XSS un impatto di riservatezza?

Question

Perché CVSSv2 non considera XSS un impatto di riservatezza?

#1 da (2 voti)

4

Dalla specifica CVSSv2:

SCORING TIP #2: When scoring a vulnerability, consider the direct impact to the target host only. For example, consider a cross-site scripting vulnerability: the impact to a user's system could be much greater than the impact to the target host. However, this is an indirect impact. Cross-site scripting vulnerabilities should be scored with no impact to confidentiality or availability, and partial impact to integrity _{CVSSv2 spec}

Questo è anche il modo in cui ho visto il punteggio XSS in pratica.

Ma anche se consideriamo solo l'impatto sull'host, un utente malintenzionato potrebbe utilizzare un payload JavaScript che legge le informazioni sensibili dall'applicazione Web interessata (se la vittima è attualmente connessa, e se tali informazioni sensibili esistono ).

Quindi, perché la riservatezza non è considerata così bassa? È un impatto indiretto? E se sì, perché (e perché l'impatto sull'integrità non è indiretto allora)? E del resto, perché non c'è un impatto sulla disponibilità? Un utente malintenzionato potrebbe ignorare la protezione CSRF e quindi probabilmente (a seconda dell'applicazione ovviamente) eliminare dati importanti o modificare le impostazioni per rendere l'applicazione non disponibile?

Correlati: Perché XSS ha ottenuto un impatto parziale sull'integrità in CVSS V2? .

So che è stato modificato in CVSSv3 (perché ora il browser viene considerato al posto dell'host).

xss risk-analysis cvss

posta tim 09.10.2016 - 22:49

fonte

1 risposta

Leggi altre domande sui tag xss risk-analysis cvss

Perché l'hash SHA-1 del certificato è stato inviato nell'estensione TLS "URL certificato client"? Qual è la prassi migliore per fornire le credenziali del DB Oracle a un'applicazione Java?

score 2 · Accepted Answer

La risposta è piuttosto semplice. Poiché è un effetto indiretto dell'XSS. Esempio: una vulnerabilità che consente di leggere i cookie avrebbe un impatto di riservatezza. Ma una vulnerabilità che ti permette di iniettare XSS ha un impatto sull'integrità (ti permette di cambiare pagina), ma come puoi cambiare arbitrariamente la pagina, in una pagina malevola che ruba i cookie, il punteggio non prende in considerazione le vulnerabilità indirette che sono stati trovati.

Prendi ad esempio questo: Una vulnerabilità in uno script di download consente a un utente malintenzionato di sostituire l'EXE che viene scaricato. Avrebbe un impatto sull'integrità piuttosto elevato.

Ma non ha un impatto sulla riservatezza solo perché l'EXE malevolo scaricato potrebbe perdere informazioni.

Uguale a XSS. Questo punteggio è importante in quanto la correzione della vulnerabilità consiste nel risolverlo all'origine (rimuovere la possibilità di XSS filtrando meglio). Migliorare la riservatezza non risolverà questo senza incorrere in effetti collaterali non previsti, e per di più l'XSS rimarrà nell'applicazione web, facendo sì che la vulnerabilità sia ancora in vigore (il CVE non può essere registrato come risolto) perché altri rischi rispetto ai rischi di riservatezza.

Il sistema CVSSv3 ha alcuni altri vettori aggiunti che compensano questo, ecco perché è anche cambiato in CVSSv3. (con le metriche di modifica dell'ambito, che prendono in considerazione se l'effetto dell'attacco si verifica da qualche altra parte e questo può essere preso in considerazione quando mitiga la vulnerabilità)