Web Testing Environment (WTE) project, which is a part of The Open Web Application Security Project (OWASP) organization, makes application security tools and documentation available to the application developers and QA testers so the security can be built into every aspect of the software development life cycle. InfoQ caught up with WTE project lead Matt Tesauro to learn more about the background, current state, various tools it supports and the future road map of the project.
InfoQ: Hi Matt, can you introduce yourself to our readers and tell us what projects you are currently working on?
Matt Tesauro: Hello, my name is Matt Tesauro and I am an IT security consultant concentrating in application security and penetration testing. Early in my career, I was a web application developer who caught the security bug and never looked back. I'm currently employed by Praetorian, an independent security firm headquartered in Austin, TX that specializes in software security assurance services. I am also heavily involved in the Open Web Application Security Project (OWASP) where I sit on the Board of the OWASP Foundation. OWASP is an open community dedicated to making application security visible. Finally, I am the project lead for OWASP WTE (Web Testing Environment). OWASP WTE aims to provide a complete environment to test applications for security issues.
InfoQ: Can you talk more about OWASP WTE project, how it came about and how it contributes to the security community?
Matt: OWASP WTE started out as a refresh of a previous OWASP Live CD project back in 2008 as part of the OWASP Summer of Code. I applied for the Live CD project and was accepted. I released a new version of the OWASP Live CD in September 2008 and have released four updates since then. The more I worked on improving the OWASP Live CD, the more I realized that I wanted a persistent testing environment. That requirement led to the development of VMware and Virtualbox versions of the Live CD. However, updates became harder and harder to produce and involved the re-creation of existing work, much more than the updates themselves. This led to the current state of the project and the "re-branding" to OWASP WTE. The key difference between the OWASP Live CD and WTE is a matter of perspective. The Live CD's goal was just that - a bootable CD. OWASP WTE's goal is to produce an array of individually installable tools and documentation needed to test web applications. Then, these tools will be grouped into various versions including a Live CD and virtual installations like VMware and Virtualbox. Additionally, a software repository will exist for users to ad-hoc add software to any existing Ubuntu installation. Currently, WTE is targeting Ubuntu 10.04 LTS and 10.10, however since the project creates generic Debian .deb files, the packages should install on any Debian-based Linux distribution.
As for OWASP WTE's contribution to the security community, its use and popularity have surprised me. Since the first Summer of Code release in 2008 there have been more than 300,000 downloads if you total up all the various releases and versions. I've heard back from security professionals globally not only thanking me for my work on the project, but also making feature requests, reporting bugs, and relaying feedback on how useful OWASP WTE was for training. I use WTE daily in my web application penetration tests, particularly the virtual installations. Besides scratching my own itch, I'm quite proud of how useful OWASP WTE has been for web application security training. I've held training classes at conference and private companies as well as heard from many trainers who also had success with OWASP WTE. When it comes to training, nothing is better than knowing that all the needed tools will be installed and working for your students.
InfoQ: What type of security vulnerabilities are addressed by the WTE project?
Matt: The range of tools installed on OWASP WTE allows for nearly all aspects of application security to be tested. For starters, the OWASP Top Ten security risks are easily covered. There are recon and information gathering tools to find out more about an application being tested. There are infrastructure scanners which will help you find configuration and server hardening weaknesses. Authentication, authorization, session management, data validation, business logic, AJAX and Web Services can all be tested with tools on OWASP WTE as well. However, some technology specific tools are missing, Flash/Flex in particular, but those tools are queued up for the next release.
InfoQ: How does WTE framework compare with other application security testing frameworks like Backtrack or Maven Security Dojo?
Matt: I'll take both of those separately.
Backtrack: Backtrack is pen testing focused but it's more the 'general' pen testing distribution. It contains tools for traditional network, application and wireless pen tests. It's a fantastic distribution with tons of testing tools, but the real difference is focus. Backtrack covers three areas while OWASP WTE is only focused on web application testing so WTE generally has more and/or newer tools in that area. Also, the general audience for Backtrack is pen testers. For OWASP WTE, I'm aiming at pen testers too, but also internal web application security professionals, QA teams, and developers. I've tried to add polish to the tools on WTE so that they are as easy as possible to use and get acquainted with.
Maven Security Dojo: Security Dojo is much closer to OWASP WTE. It is much more focused on learning and practicing web testing techniques. The primary difference is that Security Dojo contains purposefully vulnerable applications and fewer tools. OWASP WTE currently doesn't contain any vulnerable applications. While adding some has been considered, much of that work is already being done by the OWASP Broken Web Applications Project. Because of the modular nature of WTE, adding vulnerable applications for training/practice is definitely possible just not on the short-term todo list.
InfoQ: How can the WTE framework be used in Agile software application development environments?
Matt: Some of the usefulness of WTE for Agile development will depend on the maturity level of the development shop. For example, if the story board includes security stories, WTE has the tools to verify the implementation of that story. Does the team play protection poker? If so teams can get hands-on training using OWASP WebGoat which includes code samples and is part of OWASP WTE. Do they need end of sprint security scans? OWASP WTE has those tools already installed and ready to go. Are you doing Continuous Integration (CI)? If your CI efforts include deploying to a test site, you can add dynamic security scans to your process.
However, one area where OWASP WTE is currently lacking is static analysis tools. The tools included in OWASP WTE are designed to dynamically test running web applications. The next push for OWASP WTE is to include static analysis tools to audit source code. Considering the highly dynamic nature of Agile development, tools which evaluate application security as close to when they are introduced is a win for everyone. Static analysis tools can help in that regard, especially if combined with continuous integration where each build can include a source code scan. Also, as I mentioned above, all the tools are installed and configured to be as easy to use as possible. The idea is not to be exclusionary where only seasoned security professionals need to apply. Instead, OWASP WTE makes every effort to smooth out the learning curve and bring more people into application security.
InfoQ: What type of tools are available to help the software developers to use WTE framework?
Matt: There are over 25 tools installed in OWASP WTE by default, the full list can be found on the community site. The types of tools can be categorized into reconnaissance, scanners, proxies, fuzzers, and general tools. One of the single most useful tools included in OWASP WTE is OWASP WebGoat. WebGoat is a web-based training environment designed for hands-on learning about application security. WTE also includes documentation such as the OWASP Top 10, the OWASP Testing Guide, and the OWASP Code Review Guide. Finally, an example of the level of polish in OWASP WTE is the 25 Firefox Addons pre-installed such as Firebug and the Web Developer Toolbar. FoxyProxy is pre-configured to work with all the installed proxy servers. TestGen4Web allows you to record and replay browser activity. If there's something missing, please suggest it on the Feature Request Forum. If it can run on Linux and the license allows redistribution, I'll add it. I'd love to get more feedback from developers and QA testers.
InfoQ: What are the best practices and "gotchas" that WTE users need to keep in mind when using the framework for security testing?
Matt: First I'd say this applies to any framework, be it testing tools or something like .Net or Spring. A fool with a tool is still a fool. There is a certain amount of work you will need to put into anything to get something of value out.
That said, if you are brand new to application security, WebGoat is a great introduction and where I started many years (and versions of WebGoat) ago. After you work through WebGoat, take a look at the OWASP Testing Guide, especially Section 4. As a developer, if you've ever wondered what the security guys were doing to your application, the OWASP Testing Guide will tell you both a description of the issue and how to test for it.
As you move forward, start to look at scanners like w3af and learn how to use a local proxy such as Burp, WebScarab or Zap. For many developers, seeing how easy web traffic can be manipulated is an eye opener. I can remember that moment for me and it changed how I look at web application development forever. If you're already a seasoned security professional, OWASP WTE should be all you need to do the vast majority of your application testing.
InfoQ: What is the future road-map of the project?
Matt: The next big thing for OWASP WTE is the 1.0 release of the conversion from SLAX Linux to Ubuntu. With the 1.0 launch, there will be ISO, VMware, and VirtualBox versions available as well as a package repository. Current testing takes a default install of Ubuntu and adds all the tools with the repository by issuing a "sudo apt-get install owasp-wte-*". After that, I'll be updating tools as needed and starting a "testing" repository where new tools and packages will end up before being added to the main, stable branch. I plan to create updated versions a couple (probably two) times a year. In between the updated versions, anyone can update to the latest packages (from a bootable CD or virtual install) as they will be configured to use the repository.
After the infrastructure is updated, I'll work on the backlog of new packages I have to create. As the number of packages grows, I'm also considering making custom versions by creating meta-packages which will be dependent of the packages for that version. For example, I've thought about creating a "Java programmer" edition where only Java tools would be installed. I'm excited about the possibilities.
InfoQ: Thanks for your time Matt. Do you have any other comments or thoughts about WTE project or web application security in general?
Matt: First, let me thank InfoQ for the interview. It's been fun to pause in my busy schedule and think about WTE from an external perspective and share my excitement about where the project is and going.
The other really great aspect of interviewing with InfoQ is the fact that it is focused on the software development community. While I don't write nearly as much code as I used to, I still consider myself a developer of sorts and follow software development news. But, when I have my OWASP board member hat on, I'm really pleased to be talking to developers about application security. As much fun as pen testing can be, I believe that we will not hack ourselves secure and that working with developers is the most efficient method to raise the level of security in applications. I know in my college programming work, I got ZERO security training. While this is starting to change slowly, any chance to get the security message to developers is great. It's the software developers who are creating the cool new applications of tomorrow, so getting some security stories on the board or increasing the security awareness of developers is a win for everyone. I also suspect that developers who can demonstrate application security skills can also garner higher wages. ;)
Thanks again for the opportunity to talk about OWASP and OWASP WTE.