Reported Incidents based on General Incident Classification Statistic
3.2 Research Approach
CHAPTER 3
3 METHODOLOGY AND WORK PLAN
collecting information about the target web application via indirect and direct means, such as examining web search results, DNS records, and other available information. May include one or more meetings with security personnel, system owners, developers, etc. It is just as important to communicate requirements for web application information.
ii. Step 2: Test Execution
Install and configure the selected tools. This phase discovers vulnerabilities like SQL Injection, Cross-site Scripting (XSS), information leakage, and Cross-site Request Forgery (CSRF). The vulnerability scanners use the web application parameters while scanning., all they need is the IP or URL of the web application. With the IP alone, a vulnerability scanner can find out the potential places where an attack can be performed on the web application. After completing the scanning, a report displaying all the possible vulnerabilities. The result of a scan includes comprehensive details of all the vulnerabilities found within the web application.
iii. Step 3: Vulnerability Analysis
In this phase, attempts are made to exploit the detected vulnerabilities in order to simulate real-world attacks. Not all the vulnerabilities found in scanning are serious because there might be cases, where the scanner will pull the name just because the data which was expected doesn’t match the output. But, that may not be a true vulnerability after all. That is the reason why further analysis has to be done on a vulnerability scan report to find out if the vulnerability found is the right one or not. Basically, further analysis will only be done on vulnerability with high-risk, example input- based vulnerabilities, SQL Injection or SQLi and Cross-Site Scripting (XSS). Below is the guide that we use to manually test the vulnerably.
SQL Injection
SQL injection can be detected manually by using a systematic set of tests against every point in the web application. This typically involves:
o Submitting the single quote character ‘ and look for errors or other anomalies. If an error result means web application is vulnerable.
o Submitting some SQL specific syntax that evaluates to the base (original) value of the entry point, and to a different value, and looking for systematic differences in the resulting application responses.
o Submitting Boolean conditions such as OR 1=1 and OR 1=2, and looking for differences in the application's responses.
o Submitting payloads designed to trigger time delays when executed within an SQL query, and looking for differences in the time taken to respond.
o Submitting OAST payloads designed to trigger an out-of- band network interaction when executed within an SQL query, and monitoring for any resulting interactions.
Cross-Site Scripting (XSS)
The traditional way to prove the XSS vulnerability is to create a popup using the alert() function. This string is submitted as a value of a parameter to the page of the application, and responses with the injected JavaScript that displays a pop-up message with a browser cookie. If the request of browser cookie is responded and is shown as in Figure 3.2, then the application is very likely vulnerable to XSS.
The DVWA
page http://localhost:81/DVWA/vulnerabilities/
xss_r/ is affected by a reflected XSS in the name parameter.
This can be seen in the figure below when we inject the JavaScript code <script>alert(123)</script> and it is reflected and executed in the response page.
Figure 3.2: Example of XSS with Alert Box iv. Step 4: Reporting
A report will be prepared, informing if the application is vulnerable to what attacks, with the priority to solve. The classification of results is based on the risk involved.
v. Step 5: Remediation
The process of fixing the vulnerabilities 3.3 Vulnerability Classification
Classify the nature of a vulnerability based upon the component affected.
Vulnerabilities can exist in several areas of the network, such as in the firewalls, FTP servers, Web servers, operating system or CGI bins. While the class will not be comprehensive, it will explain a number of common vulnerability vectors and the factors which impact discovery and remediation.
Common Vulnerabilities and Exposures (CVE) is a dictionary of publicly known information security vulnerabilities and exposures. Each vulnerability or exposure is given a CVE identifier which is in-turn used across the board by vendors, advisory bodies and vulnerability databases.
Common Vulnerability Scoring System (CVSS) is an open framework for communicating the characteristics and severity of software vulnerabilities. CVSS is owned and managed by FIRST.Org, Inc. (FIRST), a US-based non-profit organization, whose mission is to help computer security incident response teams across the world. CVSS consists of three metric groups: Base, Temporal, and Environmental. The Base metrics produce a score ranging from 0 to 10, which can
then be modified by scoring the Temporal and Environmental metrics. The benefits of CVSS include the provision of a standardized vendor and platform agnostic vulnerability scoring methodology. It is an open framework, providing transparency to the individual characteristics and methodology used to derive a score.
Figure 3.3: Vulnerabilities Classification in Acunetix
Acunetix supports CVSS v3.0 and following the CVSS v3.0 score link will even take you to the CVSS v3.0 calculator right from Acunetix by following the CVSS v3.0 link.
Figure 3.4: CVSS Scoring Calculator Below is the severity level used in this research,
Table 3.1: Severity level and Description