Proposing SQL Statement Coverage Metrics: Difference between revisions

Line 30:

Web applications are inherently insecure <ref name="a15">] D. Scott and R. Sharp, "Developing secure Web applications," Internet Computing, IEEE, vol. 6, no. 6, pp. 38-45, 2002.</ref> and web applications’ attackers look the same as any other customer to the server <ref name="a12">E. Ogren, "App Security's Evolution," in DarkReading.com, 2007.</ref>. Developers should, but typically do not, focus on building security into web applications <ref name="a10">G. McGraw, Software Security: Building Security in. Upper Saddle River, NJ: Addison-Wesley Professional, 2006.</ref>. Security has been added to the list of web application quality criteria <ref name="a11">J. Offutt, "Quality attributes of Web software applications," IEEE Software, vol. 19, no. 2, pp. 25-32, 2002.</ref> and the result is that companies have begun to incorporate security testing (including input validation testing) into their development methodologies <ref name="a3">B. Brenner, "CSI 2007: Developers need Web application security assistance," in SearchSecurity.com, 2007. </ref>. Security testing is contrasted from traditional testing, as illustrated by Figure 2: Functional vs. Security Testing, adapted from <ref name="a17">H. H. Thompson and J. A. Whittaker, "Testing for software security," Dr. Dobb's Journal, vol. 27, no. 11, pp. 24-34, 2002.</ref>.

[[File:Sess-figure-2.png|thumb|~~This is the caption]]~~<ref name="a17"></ref>

[[File:Sess-figure-2.png|thumb|'''Figure 2. Intended vs. Actual Behavior, (adapted from <ref name="a17"></ref>)''']]

Represented by the left-hand circle in Figure 2, the current software development paradigm includes a list of testing strategies to ensure the correctness of an application in functionality and usability as indicated by a requirements specification. With respect to intended correctness, verification typically entails creating test cases designed to discover faults by causing failures. Oracles tell us what the system should do and failures tell us that the system does not do what it is supposed to do. The right-hand circle in Figure 2 indicates that we validate not only that the system does what it should, but also that the system does not do what it should not: the right-hand circle represents a failure occurring in the system which causes a security problem. The circles intersect because some intended functionality can cause indirect vulnerabilities because privacy and security were not considered in designing the required functionality <ref name="a17"></ref>. Testing for functionality only validates that the application achieves what was written in the requirements specification. Testing for security validates that the application prevents undesirable security risks from occurring, even when the nature of this functionality is spread across several modules and might be due to an oversight in the application’s design. To adapt to the new paradigm, companies have started to incorporate new techniques. Some companies use vulnerability scanners, which behave like a hacker to make automated attempts at gaining access or misusing the system to discover its flaws <ref name="a4">M. Cobb, "Making the case for Web application vulnerability scanners," in SearchSecurity.com, 2007.</ref>. A blacklist is a representative or comprehensive set of all input validation attacks of a given type (such as SQL injection, see Section 2.2). These vulnerability scanners typically use a blacklist to test potential vulnerabilities against all attacks (or a set of representative attacks). Coverage criteria for target statements can help companies assess how much of their system has the framework for a range of input validation testing. A vulnerability scanner is ineffective if its blacklist is not tested against every target statement in the system.

@@ Line 30: / Line 30: @@
 Web applications are inherently insecure <ref name="a15">] D. Scott and R. Sharp, "Developing secure Web applications," Internet Computing, IEEE, vol. 6, no. 6, pp. 38-45, 2002.</ref> and web applications’ attackers look the same as any other customer to the server <ref name="a12">E. Ogren, "App Security's Evolution," in DarkReading.com, 2007.</ref>. Developers should, but typically do not, focus on building security into web applications <ref name="a10">G. McGraw, Software Security: Building Security in. Upper Saddle River, NJ: Addison-Wesley Professional, 2006.</ref>. Security has been added to the list of web application quality criteria <ref name="a11">J. Offutt, "Quality attributes of Web software applications," IEEE Software, vol. 19, no. 2, pp. 25-32, 2002.</ref> and the result is that companies have begun to incorporate security testing (including input validation testing) into their development methodologies <ref name="a3">B. Brenner, "CSI 2007: Developers need Web application security assistance," in SearchSecurity.com, 2007. </ref>. Security testing is contrasted from traditional testing, as illustrated by Figure 2: Functional vs. Security Testing, adapted from <ref name="a17">H. H. Thompson and J. A. Whittaker, "Testing for software security," Dr. Dobb's Journal, vol. 27, no. 11, pp. 24-34, 2002.</ref>.
-[[File:Sess-figure-2.png|thumb|This is the caption]]<ref name="a17"></ref>
+[[File:Sess-figure-2.png|thumb|'''Figure 2. Intended vs. Actual Behavior, (adapted from <ref name="a17"></ref>)''']]
 Represented by the left-hand circle in Figure 2, the current software development paradigm includes a list of testing strategies to ensure the correctness of an application in functionality and usability as indicated by a requirements specification. With respect to intended correctness, verification typically entails creating test cases designed to discover faults by causing failures. Oracles tell us what the system should do and failures tell us that the system does not do what it is supposed to do. The right-hand circle in Figure 2 indicates that we validate not only that the system does what it should, but also that the system does not do what it should not: the right-hand circle represents a failure occurring in the system which causes a security problem. The circles intersect because some intended functionality can cause indirect vulnerabilities because privacy and security were not considered in designing the required functionality <ref name="a17"></ref>. Testing for functionality only validates that the application achieves what was written in the requirements specification. Testing for security validates that the application prevents undesirable security risks from occurring, even when the nature of this functionality is spread across several modules and might be due to an oversight in the application’s design. To adapt to the new paradigm, companies have started to incorporate new techniques. Some companies use vulnerability scanners, which behave like a hacker to make automated attempts at gaining access or misusing the system to discover its flaws <ref name="a4">M. Cobb, "Making the case for Web application vulnerability scanners," in SearchSecurity.com, 2007.</ref>. A blacklist is a representative or comprehensive set of all input validation attacks of a given type (such as SQL injection, see Section 2.2). These vulnerability scanners typically use a blacklist to test potential vulnerabilities against all attacks (or a set of representative attacks). Coverage criteria for target statements can help companies assess how much of their system has the framework for a range of input validation testing. A vulnerability scanner is ineffective if its blacklist is not tested against every target statement in the system.