Using SQL Hotspots in a Prioritization Heuristic for Detecting All Types of Web Application Vulnerabilities: Difference between revisions
Programsam (talk | contribs) |
Programsam (talk | contribs) |
||
| Line 96: | Line 96: | ||
Since Trac integrates with the repository used for each project, we scripted the process of gathering the changed files, and what changes were made to each file due to a certain vulnerability report. If the Trac webpage that described the vulnerability also contained a link to a set of changes to the repository, then our script marked the file as vulnerable in the <code>files</code> dataset. If the webpage containing the description of the vulnerability contained no link to a set of changes, then the report was determined to not be a problem by the development team, or did not warrant a change in the current release of the system and was excluded from our analysis. Trac allows the user to view a text-only version of the changes that were conducted during a given repository revision over the web in diff format (by appending <code>?format=diff</code> to the end of the URL). Our script parsed this resultant diff webpage into data indicating the files that were changed as well as the number of lines changed for each file. | Since Trac integrates with the repository used for each project, we scripted the process of gathering the changed files, and what changes were made to each file due to a certain vulnerability report. If the Trac webpage that described the vulnerability also contained a link to a set of changes to the repository, then our script marked the file as vulnerable in the <code>files</code> dataset. If the webpage containing the description of the vulnerability contained no link to a set of changes, then the report was determined to not be a problem by the development team, or did not warrant a change in the current release of the system and was excluded from our analysis. Trac allows the user to view a text-only version of the changes that were conducted during a given repository revision over the web in diff format (by appending <code>?format=diff</code> to the end of the URL). Our script parsed this resultant diff webpage into data indicating the files that were changed as well as the number of lines changed for each file. | ||
The entire process of analyzing Trac reports and tracing these vulnerabilities to files was achieved using a script that we created. The script stored the following information as extracted from the project Trac website into the <code>tracs</code> dataset: the unique Trac report identification number, the date the report was created, the number of repository revisions due to the report, the number of files changed, and the number of lines of code changed due to the report. | |||
The script determined the revision number using the date stored in the <code>tracs</code> dataset and by following the logic described in this section, stored the release number the issue report belonged to into the <code>tracs</code> dataset. Issue reports can only refer to files that are in the repository at the time of the submission of the report. As such, before gathering either the hotspot information or the information about which files were vulnerable, we downloaded the release of the version of the repository referred to by the report in question. For example, in WordPress, we know that the file <code>wp-includes/script-loader.php</code> exists in WordPress v2.1 but not in WordPress v2.0. We also know that <code>wp-includes/script-loader.php</code> is changed due to the cross-site scripting vulnerability reported in WordPress issue number 3937 . Thus, by downloading the repository revision associated with v2.1 (number 4782), we can include the <code>wp-includes/script-loader.php</code> file in our analysis and properly record the file as vulnerable due to issue 3937. | |||
=== 4.4. Classifying Vulnerabilities === | |||
== 5. Results == | == 5. Results == | ||