eWEEK content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
A few fairly simple practices would have prevented my successful attack on eWEEKs OpenHack site. The bottom line is that application security can be attained, but it must be consistently applied and methodically checked to be effective.
Rather than focusing on one of the five OpenHack challenges presented by eWEEK, I decided to try to find any security problems I could.
My attempt to hack the site began by making a quick pass through the Microsoft Corp. and Oracle Corp. versions of the OpenHack application, both to get an idea of their scope and an overview of their architecture.
The first decision I made was to determine which application would be more vulnerable.
While registering for an account, I noticed some inconsistencies in the Oracle version, where nonrequired items such as “title” generated unexpected error messages. This is not a security hole per se, but it did indicate a lack of consistency, which I felt was the most likely avenue of vulnerability in an application with the security attention that this one had received.
After using the Oracle OpenHack application for a few minutes, it appeared that the application used a common routine for conducting field input validation. I began looking for fields that stood out as being different, in the hope that one or more of these fields might have been overlooked or that the standard checks might prove ineffective.
The OpenHack application is small, and the list of interesting fields was quite short. These included a few hidden form fields, some ID numbers passed as query parameters, a URL field and a set of radio buttons.
The first field I began evaluating was a hidden form field for user identification that appeared when editing an account.
The application contained a label that stated: “(User ID cannot be changed once an account is created).” I changed the hidden form field to be a new user ID and hit the submit button.
The application processed my request and changed my user ID to the new ID. I logged out and tried logging in with my old ID. That ID was no longer known to the application. I logged in with the new ID and my original password. I was then logged in as that new user. I repeated the process and changed my log-in ID back to the original state. While not one of the program challenges, I reported this to eWEEK as a bug in the intended use of the program.
I then began thinking about the fact that the developer had not checked whether the ID had changed. I believe this was due to the fact that the same screen is used to both add and edit existing users.
Although it can be done securely, using the same screen to conduct two tasks does place a higher level of responsibility on the developer to ensure that the logic is appropriate in both cases. It seemed as if the developer had not fully expected the field to be changed in the case of the edit scenario.
Page Two
: Hackers Log”>
However, when I chose a duplicate ID, it returned the duplicate ID in the user ID field along with an error message. When I saw the data returned to the screen, I tried using a script tag as the user ID. This proved to be successful.
I know the Oracle developers were aware that hidden form fields can be modified, but I believe this vulnerability was missed in their initial assessments because the screen can be used in multiple contexts.
To ensure a secure system, each scenario must be run through the logic to ensure that all cases are dealt with appropriately.
The second cross-site scripting bug I discovered was in the URL field on the “Product or Services” Web page. The field seemed to use the same field input validation routine as the rest of the application. However, the context in which this field was used, constructing a URL, was different from any other fields in the application.
I entered a normal URL and looked at the HTML source that was returned to see the specific syntax I needed to inject into. Because the same routine that was used for checking the large comment fields was being used to check the URL, characters such as “, =, (, ) and a space were all considered valid. Adding a JavaScript event to the anchor tag was a simple process and proved to be effective.
Although the technique I used to exploit this cross-site scripting vulnerability was different from the one I described earlier, the source problem was actually the same.
Reuse is an important concept in software development and can be very useful in a well-designed security model, but the developer must be careful not to allow reuse to expose security holes.
The same validation routine was used in all cases, even though the context in which the fields were being used was not consistent. This variation in field usage should have resulted in a corresponding variation in the field validation routines.
This reuse, combined with the fact that cross-site scripting can be accomplished in a variety of ways, allowed my successful attack.
Jeremy Poteet (jpoteet@tech-partners.com) is chief technology officer at IT consultancy Technology Partners Inc., based in Chesterfield, Mo. Company information can be found at www.tech-partners.com.