One popular way of finding security holes within an application is to hire a company to perform a thorough security assessment. Generally speaking, these companies do a fantastic job: they know the common weak points and can provide helpful remedies to developers otherwise not trained on security. A little while back, a consultant ("Steve") working at one such company wrote in to share his experiences on one of the more interesting assessments he and his colleagues performed.

This particular client (a brokerage/trader firm) was the only one where their standard assessment procedure did not work. Instead of isolating which web pages had security holes, they set out on a much more difficult task: finding out which ones didn't. Following is a sampling of what they were up against:

ServerInterface.jsp - This page was called by about a third of the other pages via Javascript. It works much like the Client-Side PHP page in that it executes any code sent to it on the server.

CalculateFees.jsp - This page was responsible for figuring out and charging various brokerage fees based on everything from the customer's discount rate to the fund they were purchasing. What's interesting is that it could have worked just as easily being called CalculateFees.html -- the page didn't utilize a line of server-side code, instead relying entirely on Javascript and the ServerInterface.jsp page.

ViewStatement.jsp - Responsible for displaying electronic versions of the monthly statements, this page was always called with a single querystring parameter: StatementId. And because StatementIds were sequential ... you can pretty much see where that went.

AccountId - Instead of being stored in a secure session, the current user's AccountId was stored in a browser cookie. Although they obfuscated the name to "AcctId" in the cookie string, it's possible that a sophisticated hacker may be able to figure it out.

TransferFunds.jsp - This page would initiate an ACH transfer between the brokerage company and the users stored bank account numbers. Only certain users were authorized for this page, but a sophisticated hacker might be able to figure out that setting the "canUseACH" cookie token from "N" to "Y" might do the trick.

But after a long and arduous search of over a hundred different pages, they finally found the secure page they were looking for: 

--begin headerPlaceholder.jsp-------

<!-- This page has been intentionally left blank -->

----end headerPlaceholder.jsp-------
[Advertisement] BuildMaster allows you to create a self-service release management platform that allows different teams to manage their applications. Explore how!