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 144: | Line 144: | ||
=== 5.2. Comparing the Projects === | === 5.2. Comparing the Projects === | ||
In WordPress, the ability to interact with the database is exposed directly to whichever page is needing access through the <code>$wpdb -> query</code> function | |||
(and similar), which takes the SQL query in question as its parameters, and parses user input in a filtered manner into the query where required. | |||
In WikkaWiki, however, the developers made a high-level design decision to separate the database concern to a specific source code location. Specifically, database access is required through a class, called <code>Wakka</code>, which encapsulates the various queries into functions that perform database operations on behalf of the client page. The SQL hotspots found in WordPress are more spread out among the files in WordPress than in the files in WikkaWiki (H6). The developers of WikkaWiki have chosen to centralize the functionality related to database interaction into a single set of classes that contain all the SQL hotspots. | |||
This set of classes abstracts interactions with the database into a set of semantic methods that hide the direct interaction with the database from the programmer. These methods provide the necessary implementation required for input validation techniques, such as sanitizing a URL to protect the system from URL manipulation attacks, and stripping any HTML returned to the user for any potentially dangerous tags. Centralizing database interaction also provides the convenience of not having to make changes throughout the code due to a single security problem. When there is a problem with database interaction in WikkaWiki, developers usually know immediately where to look. In WordPress, some time and energy may be consumed looking around for the source of the problem. | |||
Our data shows that this high-level design decision coincides with a key difference in the security posture of the two studied projects: WikkaWiki has less input validation vulnerabilities than WordPress. First, in the predictive models described in Section 5.1, the number of SQL queries in a given file was a better predictor of the vulnerability of that file in WordPress than in WikkaWiki. But this evidence is further supported by the fact that 29% of the total reported vulnerabilities in WordPress were input validation vulnerabilities, which is a higher proportion than the 18% of total reported vulnerabilities that were input validation vulnerabilities in WikkaWiki (H7). Finally, we examined the number of changed lines of code due to security vulnerabilities that were hotspots. In WordPress, this proportion was higher at 3% than WikkaWiki, where the proportion was only 0.7% (H8). The implications of H8 for the development team are that hotspots in a project that has utilized a design like the one in WikkaWiki are going to be changed less often because they are easier to maintain. ''In short, designing a web application with all database interaction and input validation located in a single component can help decrease that applications' proportion of reported input validation vulnerabilities.'' | |||
== 6. Limitations == | == 6. Limitations == | ||