Hacker Log: Pathway to Successful Site Attack

Hacker Log: Pathway to Successful Site Attack
( Page 1 of 2 )

A few fairly simple practices would have prevented my successful attack on eWeek's OpenHack site.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.

Resource Library:

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.

>>> More Application Development Articles          >>> More By Jeremy Poteet