Decidere il parametro dell'oscilloscopio CVSS v3 per alcune delle principali 10 vulnerabilità OWASP

2

Sto cercando di assegnare owasp top 10 su cvss v3 e ho difficoltà ad assegnare il parametro "scope" per alcuni. Correggi l'elenco qui sotto se ci sono dei difetti.

  • Iniezione SQL: modificato.
    Componente vulnerabile: server Web / server di database
    Componente interessato: applicazione Web. Può causare che la webapp non sia disponibile.

  • XSS: modificato
    Componente vulnerabile: webserver
    Componente interessato: browser

  • Reindirizzamenti non convalidati: modificato Componente vulnerabile: webserver
    Componente interessato: browser (il malware può essere scaricato)

  • CSRF: invariato

  • Correzione della sessione: invariata

  • Riferimento ad oggetti diretti non sicuri: invariato

  • Caricamento file illimitato: modificato
    Componente vulnerabile: server Web
    Componente impattato: potrebbe essere il sistema operativo host

posta one 05.07.2016 - 14:28
fonte

3 risposte

1

Ambito in CVSSv3

L'ambito è definito nella documentazione :

When the vulnerability of a software component governed by one authorization scope is able to affect resources governed by another authorization scope, a Scope change has occurred.

Esempi

1) SQL Injection: Changed.
Vulnerable component: Webserver/database server
Impacted component: Web application. Can cause webapp to be non-available.

Non sarei d'accordo con il tuo ragionamento, ma acconsentirei che l'ambito sia cambiato.

Il componente vulnerabile è l'applicazione Web: la vulnerabilità non è stata introdotta dal server, né dal DBMS, ma il problema esiste perché l'applicazione Web ha inserito l'input dell'utente in una query SQL.

Il componente interessato è il database, in quanto governa i dati che contiene e un attacco può estrarre informazioni da esso che non dovrebbero essere disponibili. Se i comandi di sistema possono essere eseguiti o se i file possono essere caricati, anche il server ne risentirebbe.

Altre opinioni:

Si può vedere che c'è almeno una certa non chiarezza nel valutare l'ambito delle iniezioni SQL. Non ho trovato nessun altro esempio che determini l'ambito di un'iniezione SQL.

2) XSS: Changed
Vulnerable component: webserver
Impacted component: browser

Ha senso, e questo è anche il modo in cui First la classifica nel loro esempio XSS .

3) Unvalidated Redirects: Changed.
Vulnerable component: webserver
Impacted component: browser (malware can be downloaded)

Anche questo ha senso, per lo stesso motivo dell'XSS.

4) CSRF: Unchanged

Questo ha anche senso, ed è anche il modo in cui First lo valuta nel loro esempio CSRF . Il componente vulnerabile e il componente interessato sono entrambi l'applicazione Web.

5) Session Fixation: Unchanged

Questo ha anche senso, per lo stesso motivo di CSRF.

6) Insecure Direct Object Reference: Unchanged

Questo ha anche senso, per lo stesso motivo di CSRF.

7) Unrestricted File Upload: Changed
Vulnerable Component: web server
Impacted Component : could be host OS

Questo ha senso.

    
risposta data 05.07.2016 - 16:04
fonte
0

Questo parametro è stato introdotto perché alcuni sistemi diversi potrebbero essere interessati. XSS è un esempio molto reale: nelle versioni precedenti di CVSS, XSS avrebbe un punteggio molto basso perché mentre la vulnerabilità esiste in un'applicazione Web, l'applicazione Web stessa o il server su cui gira non sono realmente interessati: è un altro utente da qualche parte chi è la vittima.

Lo stesso vale per cose come l'avvelenamento da ARP. Ciò non ha alcun impatto sullo switch o sul router che viene attaccato, ma piuttosto su altri dispositivi nella stessa rete che ora possono essere "man in the middle'd.

Vedi anche link per ulteriori spiegazioni.

Quindi nel caso dell'XSS penso che sia corretto usare il punteggio "C", ma per l'iniezione SQL non ne sono così sicuro. Questa è una semplice irruzione nell'applicazione in questione. (a meno che, naturalmente, non si verifichi qualche errore di configurazione del database attraverso il quale è possibile un ulteriore compromesso della rete, ma l'iniezione SQL da sola dovrebbe avere un impatto solo sull'applicazione interessata).

    
risposta data 05.07.2016 - 15:34
fonte
0

Penso che l'iniezione SQL abbia uno scope invariato la maggior parte del tempo.

Ecco alcuni esempi di vulnerabilità di SQL injection, con punteggio CVSS 3:

Tutti questi hanno lo scope invariato.

Ci sono anche iniezioni SQL con scope modificate, ma queste non sono le normali iniezioni SQL:

Anche se sono abbastanza sicuro che SQL injection abbia scope invariate, non ne so abbastanza dell'ambito CVSS per determinare perché è così.

    
risposta data 06.06.2017 - 16:27
fonte

Leggi altre domande sui tag