eWEEK Labs fourth OpenHack online security test provided a number of lessons on how to protect corporate data. It also offered further proof that when it comes to security, the devil truly is in the details.
OpenHack is an interactive security evaluation, where a heterogeneous deployment of corporate IT products is evaluated for its ability to withstand the rigors of the Web. Whereas past OpenHack tests have focused on firewalls, IDSes (intrusion detection systems) and trusted operating systems, OpenHack 4 focused on Web application security.
At the heart of this years test, which started Oct. 22 and ended Nov. 8, was a Web application we use in production here at the Labs. We asked Microsoft Corp. and Oracle Corp. to harden the application and then deploy it on their choice of operating system, Web server, application server and database platforms. The hardened applications and the servers upon which they ran were hosted online at www.openhack. com, and a challenge was issued to aspiring hackers the world over to try to complete any of five hacking challenges.
What happened during the course of the test drives home the importance of code review (and review and review again) and a multilayered defense strategy. We also saw clearly the benefit of structured Web programming frameworks that automate some of the work required to write secure code (click here to see how the site fared).
Indeed, its the little things that really matter in security: Each of the two successful cross-site scripting attacks was made possible by a single mistake on a single line of code in the test application.
Its important to reiterate that the OpenHack application is specific to eWEEK and to this test. We discovered no security problems (or any significant operational problems) in any of the other components tested, including Microsofts and Oracles respective Web servers, application servers and databases; in the host Windows 2000 Advanced Server and Red Hat Inc. Red Hat Linux Advanced Server 2.1 operating systems; or in the OpenBSD firewalls or Extreme Networks Inc.s switches we used.
During the 18 days the test was open, only one of the five security challenges we posed was successfully accomplished.
Poteet describes how a functionality bug in the application tipped him off to a possible weakness in the code that he was later able to exploit. He was also able to perform a second cross-site scripting attack by manipulating a URL field to take advantage of the way the application checked unusual data types.
In both cases, Poteet was able to discover exactly where several undiscovered bugs lay in the application simply by careful observation combined with his own experience. He was also able to do this without access to source code—one more reminder that keeping source code secret is very thin protection at best.