eWEEK content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
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.
Page Two
: Crack in OpenHack”>
This vulnerability wouldnt get an attacker far, however, because the page properly detected that this string was an invalid user ID. Even if this check had failed, the application would have replaced angle brackets, quotes, parentheses and semicolons with spaces before the user input was saved in the database.
One hour after reporting the first vulnerability, Poteet reported a second successful cross-site scripting attack. This one occurred in a separate area of the site, where logged-in users are asked to confirm various inputs entered on a previous page. One of these inputs is a URL.
Poteets second attack mode would be harder for site administrators to detect because it doesnt use any tags that tip it off as script code.
During his OpenHack crack, Poteet subverted the HTML control characters in the URL display code that turns the URL into a clickable link. He submitted the string a” onclick=”javascript:alert(document.cookie); as his URL. When the code was placed between anchor tags that the application adds automatically, a clickable URL with an associated JavaScript block was created.
In contrast to the first case, this input passes the applications first line of input checks and is considered a legal URL. However, when saved, another input sanitization routine swings into action and makes the URL script code non-functional by removing the two parentheses and semicolon from it. This second-layer defense restricts the attack to one particular verify page and to the logged-on user that submitted the bad URL in the first place.
Poteet tried his cross-site scripting attacks against the functionally identical Microsoft test application, but both were blocked there.
Oracle fixed both problems the same day they were confirmed.
West Coast Technical Director Timothy Dyck can be reached at [email protected].