Crack in OpenHack

Crack in OpenHack
( Page 1 of 2 )

Cross-site scripting attack challenge accomplished in first hours of test.Two hours and 20 minutes after eWEEKs OpenHack 4 security test began, a wedge was driven into its defenses. The site is bloody but unbowed, and four hack challenges remain.

Kudos (and a $500 prize) go to Jeremy Poteet, chief technology officer of Technology Partners Inc., an IT consultancy in Chesterfield, Mo. Poteet discovered two different cross-site scripting vulnerabilities on the first day of the test.

This years OpenHack test is focused on application-level security. Microsoft Corp. and Oracle Corp. each wrote, and deployed on their applications servers, a Web-based application that was a functional match for one used in production at eWEEK.

The applications are hosted at openhack.com, which was opened for "business" on Oct. 22.

Poteet found the vulnerabilities in the Oracle version of the application. Its important to note, however, that the vulnerabilities were in the site application code itself, not in Oracle9i Application Server. The holes that allowed the attacks to succeed could have appeared on any platform and illustrate—yet again—that process, not product, is most critical to strong security.

A cross-site scripting vulnerability happens when a Web application allows a user to submit scripting code to it, then displays this input for the user to view, causing the script code to run.

Attackers usually exploit this type of vulnerability by embedding code in a URL; the code runs when users click on the link. Running in the security context of its site host, this parasitic code could access site cookies or do anything else legitimate site scripting code can do.

Poteet first discovered a problem in the Oracle applications user account modification page, which allows logged-in users to edit their user account data. When a user submits changed information, the application checks data for validity. If theres a problem, the page displays an error message and asks the user to correct the bad input. When doing so, it redisplays what is supposed to be sanitized input. However, one field in the Oracle-written app—the user ID itself—wasnt checked for HTML scripting tags.

Poteet created a user account and submitted a hand-crafted URL to the site that passed in a value for his user ID set to a very short JavaScript program. Poteet would have known his attack was successful when he saw a popup box containing the word "Test." In this case, the pages input error handling itself had an error.

>>> More Application Development Articles          >>> More By Timothy Dyck