Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CWE number as enum #31

Closed
wants to merge 14 commits into from
Closed

CWE number as enum #31

wants to merge 14 commits into from

Conversation

darkspirit510
Copy link
Contributor

@darkspirit510 darkspirit510 commented Nov 1, 2022

Migrated CweNumber to enum to ensure there is no magic number stuff going on. Could remove a lot of mapping code that just attempts to map string to number. Since the code has to go through CweNumber's lookup method (which informs about request of unknown number), this (at least somehow) handles #6 and #7. It obviously does not handle default blocks for mapping of any tools internal namings/ids to CweNumbers.

// Add any 'new' CWEs ever found to switch above so we know they are mapped properly.
System.out.println("INFO: Found following CWE which we haven't seen before: " + cweNum);
return Integer.parseInt(cweNum);
return CweNumber.lookup(cweNum);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This change doesn't allow us to manually decide how to map these. This can be especially important for DAST tools as they frequently report 1 type of injection as another. I'm thinking in cases like this we should leave the manual mapping the way it was. What do you think?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As discussed: #31 (comment)

return CweNumber
.SENSITIVE_INFORMATION_IN_BROWSER_CACHE; // Information Exposure Through
// Browser Caching-Cacheable HTTPS
// Response
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you merge the above 2 lines into a single line comment?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Already fixed

}
return 0000;

return CweNumber.lookup(name.trim());
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Again, I think its better to leave the manual mapping here so we can map in anything 'new'.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As discussed: #31 (comment)

case 36:
case 23:
return CweNumber.PATH_TRAVERSAL;
case 338:
return CweNumber.WEAK_RANDOM;
}
return cwe;

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we should add a warning like the others, e.g., "something new seen here not mapped before". Take exact message from other parser that already has this warning.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As discussed: #31 (comment)

case 36:
case 23:
return CweNumber.PATH_TRAVERSAL;
case 338:
return CweNumber.WEAK_RANDOM;
}
return cwe;

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you add new/missing mapping warning here?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As discussed: #31 (comment)

+ " for rule: "
+ ruleName);
private CweNumber mapCWE(Integer cweNumber) {
if (cweNumber == 335) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should retain the explanatory comment of why we are doing this.

}
return 0; // Not mapped to anything

return CweNumber.lookup(cweNumber);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I prefer that we keep the manual mapping so we can get the warning of 'new' types of issues not yet mapped.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As discussed: #31 (comment)

}

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we restore what we had so we can flag reported CWEs not yet mapped?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As discussed: #31 (comment)

int cwe = cweNumber(finding);
tcr.setCWE(cwe);
String cwe = finding.getString("cwe").substring(4);
tcr.setCWE(CweNumber.lookup(cwe));
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Restore what we had so we can flag reported CWEs not yet mapped. And there is one mapping here that doesn't go straight up, 326 to Weak Crypto.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done

}

return cwe;
return CweNumber.lookup(cwe);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we restore what we had so we can flag reported CWEs not yet mapped?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As discussed: #31 (comment)

}
return cwe;
return CweNumber.lookup(cwe);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we restore what we had so we can flag reported CWEs not yet mapped?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As discussed: #31 (comment)

case "xss":
return 79;
return CweNumber.XSS;
default:
throw new RuntimeException("Unknown category: " + category);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe change this to a simple system out println? Runtime exception seems harsh.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I can change this, but I didn't touch this in my PR.

}
return 0;

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we restore what we had so we can flag reported CWEs not yet mapped?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As discussed: #31 (comment)

Node refs = getNamedChild("references", vuln);
List<Node> references = getNamedChildren("reference", refs);
for (Node ref : references) {
String title = getNamedChild("title", ref).getTextContent();
if (title.startsWith("CWE-")) {
String cweNum = title.substring("CWE-".length(), title.indexOf(":"));
cwe = cweLookup(cweNum);
cwe = CweNumber.lookup(cweNum);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we restore the old cweLookup so we can still get the warning "WARNING: Wapiti-Unmapped CWE number: " + cwe);"?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As discussed: #31 (comment)

}

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we restore the old cweLookup so we can still get the warning "WARNING: ZAP CWE not mapped to expected test suite CWE: " + cwe);

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As discussed: #31 (comment)

@davewichers
Copy link
Contributor

@darkspirit510 - Thanks so much for all this refactoring work! I provided some minor comments in a few dozen of the files changed. Can you address those comments and we should be good to go.

@darkspirit510
Copy link
Contributor Author

Sorry for the late reply :-) Since most of your comments are about the "missing" default message, one general reply why I removed them:

After checking all mapping methods in all Reader classes, you can divide them into three groups:

  1. Mapping from tool-internal string/code/whatever to CWE number. This can definitly not be automated and is untouched from me (except, of course, the enum conversion)
  2. Mapping from one CWE number to another. This is "hacky", because Benchmark has a limited set of expected CWE numbers, although there are some more detailed CWE numbers describing the same thing (e. g. CWE-89 "SQL injection" and CWE-564 "Hibernate SQL Injection"). Since Benchmark does not have any fuzzyness/forgiveness and only accepts a specific CWE numbers, some readers contain mappings to "fix"/map one CWE number to another. This is sad, but has to stay in the reader.
  3. The only type of mappings I removed (which for some classes means remove the mapping code completly) is mapping one CWE number (sometimes as String) to exactly the same CWE number. If a given number did not exist in a mapping method, there was a log message. What's the value of this, if it is just mapping a number on itself? If a tool already reports CWE numbers, why not just pass them to the enum and only warn if the enum does not (yet) contain this number.

@davewichers
Copy link
Contributor

As you address issues per my comments above, can you add comments to each issue you've addressed so I can resolve comments on fixed issues?

@darkspirit510
Copy link
Contributor Author

If you accept my explaination, i can write a short note to every comment.

@davewichers
Copy link
Contributor

@darkspirit510 - that works. Thanks.

@davewichers
Copy link
Contributor

@darkspirit510 - Did you ever work on my comments (per above)? Also, there is a branch conflict now, w/SemgrepReader. Can you resolve that too?

@darkspirit510
Copy link
Contributor Author

@davewichers most of the comments should be explained in comment #31 (comment). But I actually missed some comments, I'll go through them within the next days.

@darkspirit510
Copy link
Contributor Author

I fixed/commented all the things. If you're still not sure about this PR, I think about closing and redoing it in smaller chunks.

@davewichers
Copy link
Contributor

@darkspirit510 - There was a lot of work done here, but might have been overcome by events. Do you want finish this one? Or start over and do this in smaller chunks?

@davewichers
Copy link
Contributor

@darkspirit510 - There was a lot of work done here, but might have been overcome by events. Do you want finish this one? Or start over and do this in smaller chunks?

@darkspirit510 - Nudge :-)

@darkspirit510
Copy link
Contributor Author

Since this is way too old, I'll redo it in smaller chunks 😅

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants