SQL Injection Attacks and Defense - 2009

130 Chapter 3 • Reviewing Code for SQL Injection
and products chosen in each situation are modified to individual requirements. Good quality
assurance techniques can be effective in identifying and eliminating vulnerabilities during
the development stage. Penetration testing, fuzz testing, and source code audits should all be
incorporated as part of an effective quality assurance program. Improving the software
development process and building better software are ways to improve software security
(i.e., by producing software with fewer defects and vulnerabilities). Many COTS software
packages are available to support software security assurance activities. However, before you
use these tools, you must carefully evaluate them and ensure that they are effective. I suggest
that before parting with what can be very large sums of money, you perform your own
comprehensive product evaluation. To research the tools, you can use the free trials that are
available from the companies’ Web sites or contact a sales representative.
Notes from the Underground…
The Right Tool for the Job
Implementing SCAs into the development life cycle does not automatically result in
the production of secure application code. Tools that implement metrics based on
historical data in an attempt to provide management with pretty graphs and trend
analysis reports that inadvertently lead to reprimands for developers or project leads
for failing to meet arbitrary targets can be counterproductive. Just like hackers,
developers can be very capable of finding ingenious ways to “beat the system” so
that metrics are favorable (i.e., producing code in such a manner that the SCA does
not flag their code). This can lead to vulnerabilities being resident within the code
and not being identified.
In addition, if the developer does not understand why a vulnerability is being
reported and the tool does not provide sufficient information to instill a comprehensive
understanding, he can be lulled into believing that the alert is nothing more than a
false positive. There are a couple of very public and well-known examples of such
situations occurring in the code of the RealNetworks RealPlayer software
(CVE–2005–0455, CAN–2005–1766, and CVE–2007–3410). The published vulnerability
announcements contained the vulnerable lines of source code. The ignore directive
for a popular SCA (Flawfinder) was appended to the vulnerable lines. The tool had
reported the vulnerability, but instead of fixing it, a developer had added the ignore
directive to the code so that tool would stop reporting the vulnerability!
Continued