Core Security Patterns: Best Practices and Strategies for J2EE, Web Services, and Identity Management
| One of the most important and most frequently overlooked areas of application development is security testing. While we pay much heed to functional testing, it is surprising how little security testing we do. This may be attributed to many factors:
Regardless of the reasons, it is not being done and it poses a serious security risk to the application. Security testing is a time-consuming and tedious process, most often even more so than functional testing. It is also spread across a variety of disciplines. There are the functional business security requirements that the regular test team will perform. However, there are also non-business functional, or operational, tests that must be performed as well. These can be broken down into two categories, Black Box Testing and White Box Testing. Black Box Testing
Zero knowledge or "black box" testing assumes no knowledge of the application. Black box testers approach the application as an attacker would, probing for information about the internals of the application and then attempting a mixture of different exploits based on that information. For example, if a URL of the application contained a ".cgi" extension, it might be inferred that the application was developed in CGI and therefore may be vulnerable to many well-known attacks. Black box testers will employ a variety of tools for scanning and probing the application. There are hundreds of different tools out on the Internet for hacking into Web applications. These tools attempt everything from port scanning to attempting exploits for multiple implementation languages (Perl, CGI, C, PHP, and Java). Many such tools are quite sophisticated and provide comprehensive vulnerability scanning of any type of Web application. In fact, many operational groups will run such scans on their applications periodically to ensure that they are not vulnerable to the latest automated attacks. Black box testing will generally not uncover application-codespecific vulnerabilities. It will, however, ferret out unanticipated vulnerabilities arising from the infrastructure that the application was built on. This could range from host or network misconfiguration (routers, services, and OS patches) to problems with the implementation language or version of the virtual machine that it runs on. All of these types of vulnerabilities are not easily foreseen by the developers or business owners and are usually only discovered during black box testing. White Box Testing
The converse of black box testing is white box testing, where you have full knowledge of the application being tested. In this case, the testers will have access to all configuration information and the source code itself. They will perform code reviews, looking for possible weaknesses in the code and write test harnesses to try to take advantage of those weaknesses. White box testers are generally ex-developers or testers that have enough development background to understand the application's programming language and know the nuances of it. White box testers have a toolbox of their own, albeit different from the black box testers. Their toolkit will contain tools that scan the code and can probe it internally. Debuggers and source code scanners are the most prevalent. These allow the testers to find very application-specific bugs and vulnerabilities. Problems such as race conditions and input parameter checking are specific to that application and will not be discovered through black box testing tools (hopefully). These tools will often find other problems with the application, such as memory leaks or performance issues. While these are not security vulnerabilities per se, they do contribute to the reliability and availability of the system, which is, after all, one of the main concerns of security. |
Категории