Pentest FAQ – #18 and #19 – How are vulnerabilities found evaluated? And what is the CVSS?
In our Big Application Security Penetration Test FAQ for clients we answer everything you should know before, during and after the commissioning of an Application Security Penetration Test.
In focus today:
Question #18: How are vulnerabilities found evaluated?
There is no standardised evaluation system for the danger potential of vulnerabilities. Nevertheless, most vendors assess vulnerabilities very similarly, according to a scheme in which the risk potential is divided into the categories low, medium, high and critical. The categories can be roughly interpreted as follows:
Critical: This vulnerability represents an unacceptable risk. The application must not be used productively; if it has already been used, it must be deactivated immediately.
High: This vulnerability must be addressed immediately, possibly by an emergency patch. Further measures for risk avoidance up to the remediation are to be considered.
Medium: This vulnerability must be addressed, even if it involves (moderate) additional costs or other (moderate) disadvantages.
Low: The correction can be included in regular release planning.
Sometimes there is an additional parameter (probability of occurrence or complexity) that tells us how difficult it is to find and exploit the vulnerability – in other words, how likely it is that an exploitation will actually occur via the vulnerability in question.
Question #19: What is the CVSS score and why should I deal with it?
“The Common Vulnerability Scoring System (CVSS) is an industry standard for assessing the severity of potential or actual vulnerabilities in computer systems” (Source: Wikipedia). The design had “off the shelf” applications in mind, but not the specific requirements of custom web applications, which are unique in nature. Nevertheless, the CVSS has become more and more popular in recent years for the evaluation of vulnerabilities in customer-specific web applications due to a lack of better alternatives. In the CVSS, the total score of a vulnerability results from the combination of a series of isolated evaluations of individual aspects (metrics), taking into account the weightings stored in the calculation formula.
It must be said, for example, that the increasing popularity in the area of application security is less due to the particularly good suitability than to the lack of alternatives. The following experiences should be taken into account when using CVSS:
● If the comparability of the evaluation across many applications and/or different pentesters is important – e.g. for large companies with many applications or for integration into DevOps processes – the CVSS should be considered as an evaluation scheme.
● Companies that occasionally carry out pentests or where comparability is not important for other reasons should rather use the criterion of simplicity. The CVSS is then not the first choice.
● The CVSS has a counterproductive effect when the rules for the consequences to be drawn from a vulnerability are too rigidly laid down.
So if, as part of the deployment process, a score that exceeds a specified threshold automatically results in the stop of a go-live – possibly imminent and very important for the business. The process should therefore include a feedback loop to ensure that vulnerability assessments with serious consequences can be subject to a detailed assessment and that the CVSS assessment can be corrected manually
How can you actively prevent usernames from being enumerated on WordPress author pages?
CSRF Countermeasures #2: Another way to protect against CSRF – stateless – is the Double Submit Cookie method.
The NinjaDVA is our comfortable and flexible training environment.
Is your web application vulnerable to SQL Injection? With sqlmap you can test it.
CSRF Countermeasures #1: One possibility to prevent CSRF is the usage of an anti-CSRF token.