Proposing SQL Statement Coverage Metrics: Difference between revisions
Programsam (talk | contribs) |
Programsam (talk | contribs) |
||
| 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>. | 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>. | ||
'''PLACEHOLDER FOR FIGURE 2''' | '''PLACEHOLDER FOR FIGURE 2'''<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 | 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 | ||