Hacking Web Services
siduri writes "Udi Manber, chief scientist at Yahoo!, gave a great talk on the kinds of hacks that Yahoo sees at the IEEE's Symposium on Security and Privacy. I wrote an overview of his talk for Dr. Dobb's Journal. While some of the message is well-known stuff (like that people will spend a lot of time hacking the most trivial things), the details of what Yahoo has to deal with are really pretty interesting."
Often, it's not a matter of restricting access. The description of the E-Bay situation where other people would generate bad logins as a competitor to lock them out is a good example. You need to provide this functionality, to keep from having your client's accounts broken into. Yet, that very policy can be used effectively as a denial of service against your clients.
I run into sysadmins who assume that issues are binary--something is bad, cut it off; something is good, allow it. Usually more complex applications require much more of an understanding of a balance between business functionality and security. In the case of E-Bay and user lockout, there is no exact solution--you need to satisfy two opposing interests--so you make a compromise between the two and try to forge a workable solution.
I think the biggest challenge for the security community will be how to modify their practices (and others') to be able to quantify risk in applications so that businesses can make good functional decisions. Security teams have largely focused on perimeter security and things like web parameter checking, but they don't usually stray into the gray area of functional requirements--or if they do, usually only to, as some have put it, cut the wings off flies.
So, to get back to the original point of the post--it's not so easy to solve as just blocking traffic. Nope, sorry, it's a lot more work than that.
he talked about countermeasures instituted against hackers, but doesn't want them openly published (security through obscurity, anyone?)
I'm quite tired of hearing statements like 'company X won't reveal Y; this demonstrates security though obscurity which everyone knows is bad.' Well, it's not! Your statement demonstates that you can echo the slogans but don't understand what security really means. I strongly encourage you to read a recent Crypto-gram by Bruce Schneier. You cannot apply the principles used for analyzing a mathematical system to all real world security issues.
Given one hour to live, the student replied: "I'd spend it with professor FP who can make an hour seem like a lifetime."
Yahoo!'s problems are no different from those brick-and-mortar retailers have with loss leaders and promotions: if you give something away at a loss, there is a good chance that others will find it profitable to get lots of it and resell it. It's not a security problem, it's a problem with the business model. Welcome to the real world.
Yahoo! may want to continue to bask in the glory of having many millions of users, but if they want stop these problems, all they have to do is charge for all of their services. The choice is really theirs.
Don't get me wrong: I like Yahoo! services and I think it would be great if they continue to be free. But I really worry when Manber uses terms like "theft" and "security" for a problem that has very little to do with "theft" and "security". Fortunately, Manber himself isn't calling for a legal solution, but management and lawmakers may be less understanding of the issues involved.
During hotly contested auctions, some users will mount password attacks on other bidder's accounts an hour before the end of the auction -- not to actually gain access, but merely to trigger a security lockout, thereby ensuring that the legitimate user cannot place last-minute bids.
I realize how ridiculously easy it is to get a new IP address on a dialup system or in a facility where someone has access to many addresses but wouldn't a simple IP block after so many attempts help discourage the casual DoS but still allow the legitimate user access when they come to make their last minute bid?
If not this then what about using a login name which is different then the displayed account name? This way the login name is not available to people viewing a particular account's public details for their use in a DoS. I know this is an added step of complication but may be necessary to eliminate bad side effects.