2

I am trying to score owasp top 10 on cvss v3 and I am having difficulties assigning "scope" parameter for some. Please correct the below list if there are some faults.

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

  • XSS: Changed
    Vulnerable component: webserver
    Impacted component: browser

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

  • CSRF: Unchanged

  • Session Fixation: Unchanged

  • Insecure Direct Object Reference: Unchanged

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

|improve this question
  • We're assuming you read the spec document (section 2.2): first.org/cvss/specification-document – schroeder♦ Jul 5 '16 at 12:45
  • perhaps it would be useful if you explained why you assigned scope the way you did - this question, as it stands, is difficult to answer – schroeder♦ Jul 5 '16 at 12:46
  • @schroeder, you are right. I could project this question in a better way because this is vague right now. I am just randomly selecting vulnerabilities and trying to calculate risk rating on cvss v3. For example, consider unvalidated redirects in an application. In the URL, say, there is a parameter named "TARGET" which is susceptible to the vulnerability. Now I am thinking of the "scope". An attacker can trick a victim to install malware with it. And hence I put "changed" in it. As the vulnerable component is web server. So is this thinking right? – one Jul 5 '16 at 12:48
  • @schroeder, I did read the whole documents presented by FIRST. But I want to do the analysis for web application based vulnerabilities. – one Jul 5 '16 at 12:53
1

Scope in CVSSv3

Scope is defined in the documentation:

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.

Examples

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

I would disagree with your reasoning, but would agree that the scope is changed.

The vulnerable component is the web application: The vulnerability wasn't introduced by the server, nor by the DBMS, but the issue exists because the web application inserted user input into an SQL query.

The affected component is the database, as it governs the data it holds, and an attack can extract information from it that shouldn't be available. If system commands can be executed or if files can be uploaded, the server would also be affected.

Other opinions:

It can be seen that there is at least some unclarity about rating the scope of SQL injections. I haven't found any other examples that determine the scope of an SQL injection.

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

Makes sense, and this is also how First rates it in their XSS example.

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

This also makes sense, for the same reason as XSS.

4) CSRF: Unchanged

This also makes sense, and is also how First rates it in their CSRF example. The vulnerable and the impacted component are both the web application.

5) Session Fixation: Unchanged

This also makes sense, for the same reason as CSRF.

6) Insecure Direct Object Reference: Unchanged

This also makes sense, for the same reason as CSRF.

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

This makes sense.

|improve this answer
  • thanks a lot for the efforts. So in my opinion, sql injection 'scope' will depend on what remediation steps you want to focus on. If we are saying lack of white-listing characters led to SQLi, then scope changed as vulnerable component is web server and the affected component is DB. But if we consider absence of parameterized queries, we can say both the affected and vulnerable component are databases. Please correct me if I am wrong. – one Jul 5 '16 at 15:04
0

This parameter was introduced because some different system might be impacted. XSS is a very real example - in previous versions of CVSS, XSS would score very low because while the vulnerability exists in a web application, the web application itself, or the server it runs on, are not really impacted - it is another user somewhere who is the victim.

The same goes for things like ARP poisoning. That doesn't really impact the switch or router that is attacked, but rather other devices in the same network that can now be 'man in the middle'd.

See also https://www.first.org/cvss/user-guide for more explanation.

So in the case of XSS I think you are correct to use the "C" score, but for SQL injection I am not so sure. That is a simple break-in into the application concerned. (unless, of course, there is some database misconfiguration happening through which further compromise of the network is possible - but the SQL injection by itself should only impact the application concerned).

|improve this answer
0

I think SQL injection has scope unchanged most of the time.

Here are examples of some SQL injection vulnerabilities, with CVSS 3 score:

All these have scope unchanged.

There are also SQL injections with scope changed, but these are not your normal SQL injections:

Even though I am pretty sure that SQL injection has scope unchanged, I don't know enough about CVSS scope to determine why this is so.

|improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.