E-Book Application security testing: Protecting your application and data Application security testing is critical in ensuring your data and application is safe from security attack. This ebook offers tips on explaining the basics of application security and how it differs from network security, and then delves deeper into testing for two common vulnerabilities: Injection and cross-site scripting. It ends with a tip regarding performance concerns when adding security protection to code. The ebook is written for IT management, including QA and development managers, interested in ensuring their applications are kept secure. Sponsored By:
E-Book Application security testing: Protecting your application and data Table of Contents Application security: Testing for injection vulnerabilities Overcoming the challenges of cross-site scripting testing Resources from IBM Sponsored By: Page 2 of 9
Application security: Testing for injection vulnerabilities By John Overbaugh One of the most challenging responsibilities of a tester is ensuring the security of a Web application. In this tip, I ll cover a few steps testers can take to be more effective in testing for OWASP s top security vulnerability: injection. According to the OWASP project: Injection occurs when user-supplied data is sent to an interpreter as part of a command or query. Attackers trick the interpreter into executing unintended commands via supplying specially crafted data. Injection flaws allow attackers to create, read, update, or delete any arbitrary data available to the application. In the worst case scenario, these flaws allow an attacker to completely compromise the application and the underlying systems, even bypassing deeply nested firewalled environments. The goal of an injection attack is to trick a Web application into treating input as if it were code, and thereby taking control of an application. The most common injection attacks include SQL injection, XPATH, and HTML injection. Injection attacks are often the basis for other attacks such as cross-site scripting attacks (attacks which inject Javascript code). It is extremely difficult to test security into a project -- if not impossible. The key to fixing injection vulnerabilities is to not introduce them in the first place and/or to detect them in the build phase. Using static code analysis or similar automated tools will uncover a ton of these flaws. Still, no tool can replace a careful, experienced, methodical tester working her way through a Web application. The first step in identifying injection flaws is to understand where user input is captured and used by the application. With injection attacks, it really doesn t matter if the input is stored in a database or other file, or if it s reflected back on the next page. The issue is to root out where unsanitized input is leveraged by the application. So it s critical to understand the input and output of your application -- where is data brought into the application and where Sponsored By: Page 3 of 9
is it later output. This means that as a tester you will need to have a far better understanding of technical implementation of an application than if you were simply testing for conformance to requirements. By understanding the data flow, you can begin to probe how the application leverages data. Another step in testing your application is to understand what technologies are leveraged. For example, does your application run in an LDAP environment? Will LDAP injection testing be important? Is a SQL backend involved? Is your application architected such that XPATH or XQUERY are potential attack vectors? By understanding your application, you can develop an accurate sense of the scope of the project and what technologies and attacks you need to probe. Your patience will be challenged by the next task -- documenting and executing tests. Probing for SQL injection vulnerabilities in an application is fun and exciting the first few times and in an unhealthy sense, discovering a valid defect is definitely rewarding. But these boundaries need to be probed control after control, page after page, POST parameter after POST parameter. It can become tedious. The good news is that this level of a test everything approach is generally a one-time process within legacy code. Once tested, always tested may not be an appropriate maxim, but it s safe to say that a page which passed these tests last year and has not changed since is unlikely to have a new defect on it. There are a few commercial and open-source tools available to aid in your testing, but until a tester really knows an app, relying on an automated tool to probe every corner is insufficient. A few additional notes to consider in your injection testing: Many applications are developed with client-side input validation. This is a good thing; it prevents the benevolent user from uploading bad data. Unfortunately, it sometimes prevents the inexperienced tester from fully testing an application. In order to get beyond client-side input validation, you will need to learn how to use a proxying tool. Using this tool, you will begin to learn what data is input into the application (there is much more input than just the controls on a web page). You ll also be able to bypass client-side validation, so you can run malicious input tests. Sponsored By: Page 4 of 9
Even if a potential injection vulnerability is addressed, it doesn t mean it has been fixed. A common response to an injection vulnerability is to blacklist various inputs (blacklisting means to explicitly deny any request for which the input matches a value in a list). Many hackers get around client- and server-side validation by encapsulating the text used in an attack. The keys to succeeding at injection testing are 1) to be methodical, 2) to understand the technology underlying your application and 3) to use tools appropriately. Sponsored By: Page 5 of 9
Overcoming the challenges of cross-site scripting testing By John Overbaugh Cross-site scripting (often abbreviated as XSS) is by far the most prevalent security vulnerability on the Internet today. Hardly a day goes by without a new report of a successful XSS attack against a prominent website. It is my professional opinion that no software testing is complete without a full battery of XSS tests being performed. How can we call ourselves professionals and let this common, simple flaw slip through time and time again? What is cross-site scripting? TechTarget s definition of cross-site scripting captures the brutal truth about the attack: Cross-site scripting (XSS) is a security exploit in which the attacker inserts malicious coding into a link that appears to be from a trustworthy source. When someone clicks on the link, the embedded programming is submitted as part of the client's Web request and can execute on the user's computer, typically allowing the attacker to steal information. I consider XSS attacks a temporary identify theft -- a well-crafted XSS attack executes code in the user s context. The most serious consequences include disclosure of user session information (such as the theft of an otherwise-secure session cookie), clickjacking (the downloading of malware), and spoofing (the display of malicious Web content in an apparently benevolent context). XSS s insidious nature is rooted in the fact that the user never knows it is happening. We have the responsibility to educate ourselves, our teams and our clients on XSS testing, and root out the risks before our Web applications enter production. How to test for cross-site scripting vulnerabilities So how do we test for cross-site scripting vulnerabilities? Sponsored By: Page 6 of 9
First of all, there are tools to aid in this. No tool can catch everything, but most tools (commercial or other) are able to catch low-hanging fruit. I m a strong advocate of leveraging code analysis and XSS vulnerability detection tools first. Fix valid issues in your tools (and real-world false positive rates are critical in determining which tool will provide the highest percentage of valid issues). This will reduce the scope of manual testing. Focus testing on page elements which render data In testing for XSS vulnerabilities, it s important to remember that you ll find vulnerabilities where data is played out (used to render HTML) that has been inputted by the user session. This is the most helpful method of scoping your testing. Focus testing on page elements which render data. Unfortunately, that inputted data can have numerous sources: user input (text controls, for instance), URL parameters, session cookie parameters, session headers, etc. Don t limit your testing to just basic input boxes. For instance, I ve found XSS vulnerabilities where code was keying off the value of checked radio boxes. Keep in mind that a user can proxy the Web browser and modify the value of the radio box control and inject malicious values. As with all injection testing, several helpful tools exist. There are a number of great tools for proxying browser requests. These tools simplify the modification of request elements and allow you to generate malicious input. Test both reflected and stored data Remember also that inputted data takes two forms: reflected and stored. Some inputted data never makes it to the database, and developers are often less stringent with how this data is used. This data is reflected -- rather than being stored in a database, like a user s first address line, the data is used in generating the server s next response. Query string parameters are often a great example of reflected data. Take, for instance, a query like http://www.mysearch.org?query= my query string Some enterprising developer might think it s a great idea to code the response page to include Your search for <querystring> resulted in 157 results. If the data used to populate <querystring> comes from the query request parameter, this is a great source for injection! I believe reflected vulnerabilities are Sponsored By: Page 7 of 9
more difficult to find, simply because reflected data can be found everywhere in a web application (there s no tell-tale call to a data layer involved). Stored XSS takes on most of the same attributes as reflected, with one caveat: this data is stored in a database and potentially played out a number of times, whereas reflected attacks are characterized by their transient one-time nature. Stored XSS can be more easily discovered -- find any time where data is written to the database, and track back that data to its source. When testing, consider common data which should be stored and retrieved, and focus your test efforts on the input methods for these data points. Use your tools correctly The good news is that there are a number of support technologies available today, which aid the developer in preventing injection vulnerabilities like XSS. But these technologies only work if they are leveraged in code and if they are configured correctly. One critical test, therefore, is to ensure that any anti-xss technologies are properly applied. In the.net world, for example, all IIS servers can run URLScan. This feature scans incoming URL requests searching for potential injection vulnerabilities. URLScan can be complex and misconfiguration happens often. Be sure your team takes the time to enable anti-xss technologies, and to add test cases to validate that the functionality is properly configured. I won t lie to you. The scope of testing for XSS vulnerabilities can be vast. But by utilizing good engineering practices, tools to cover low-hanging fruit, and smart testing skills, you can tackle the challenge of XSS testing. Sponsored By: Page 8 of 9
Resources from IBM The evolution of quality management: security, privacy and accessibility Build in security and drive innovation Security and compliance in the healthcare industry About IBM At IBM, we strive to lead in the creation, development and manufacture of the industry's most advanced information technologies, including computer systems, software, networking systems, storage devices and microelectronics. We translate these advanced technologies into value for our customers through our professional solutions and services businesses worldwide. Sponsored By: Page 9 of 9