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.