|
INTEGRATION WATCH: Worming Their Way to the Heart
By Andrew Binstock
 March 1, 2004 — With the pandemic spread of the MyDoom virus in January, every IT department in the world is reminded anew that no site can ever consider itself immune from attack. This perception would seem like no big deal. But if we spiral back 12 to 18 months, you might remember how some sites were forcibly closed down by viruses. Today, due to much greater awareness, companies have invested wisely in software and hardware defenses to keep infrastructure safe and humming. But these defenses are inherently time-sensitive: They weaken as time passes if managers and developers do not stay abreast of what crackers are up to.
With this in mind, SD Times and DevelopMentor presented a toe-curling Web seminar in January that featured Keith Brown, a security expert at training firm DevelopMentor, showing the ease with which carelessness in code could allow him to stroll through a company’s databases.
Within minutes he was into the site, searching for and finding the records he needed. He then had the site’s Web server display a nicely formatted report of customer names, addresses and credit-card information. He employed a technique called SQL injection, in which he inserts his own SQL commands into the SQL strings the Web server sends to the database. This hack works because of a simple error: The Web site asks the user for his name. It then takes the user-entered name and concatenates a SQL select statement that fetches the user’s data.
By inserting malicious data, Brown demonstrated how he could change the SQL string to make the database do his bidding. First, he closed off the original statement with an escape character, then concatenated his own request, and finished that malicious code with a comment character so that anything that followed it (from the original programmer’s SQL statement) was ignored.
By deft probing of the information, he could quickly find out what other databases were hosted, what their contents were, and how to dump them in a formatted display. There were 170 attendees at the Web seminar. At the end of the Q&A, not one had stirred. Like them, I was transfixed. Seeing a professional dismantle a site in minutes makes your palms sweat and knots your tummy in unpleasant ways.
Brown then demonstrated how to do similar things with C/C++ and .NET languages. In all cases, the problem and the solution were the same. The security hole was that unchecked user-entered data was driving program functionality. We all know that user data ultimately must drive program logic, but what we forget is that all user-supplied data must be viewed as hostile. It must be scanned and processed before it can direct logic flow. Brown wisely recommends that all data be verified via a regular-expression engine that can check for escape characters and peculiar sequences. Once a data string passes this hurdle, the program can accept that it is handling true data, and then it can key off it. But not until then.
There are subtle ramifications to this point. Suppose you post an app in which user selections are done by drop-down menus. Wouldn’t you be safe because you’ve limited the choices a user can make? He can choose among only A, B or C. Nothing else, right? No. Suppose the cracker dials into your app without using a browser. Let’s say he’s just sending your server commands and requests via HTTP. He can send any menu pick he wants, and if you’re not checking it before using this value, he can crash or control the app as he wishes.
What should you do if the menu pick is invalid? Log it, along with the IP address and any known data about the user. Then return an error message. However, this error message should not be the one returned by the SQL server or the Java app server. That information tells the hacker too much: If he knows how to jigger SQL code, you’re dead if he can direct feedback from the SQL engine. Rather, the message should say something like “Invalid menu pick, please try again.” Definitely do not announce the specific problem. Error messages like “Part numbers cannot contain more than two letters” is much too informative.
One reason developers like you and me don’t automatically think about these things is because they did not exist in this form when we learned languages—that is, before last year. I’ve gone through the standard textbooks on C, C++, Java and Python. Not one has index entries for buffer over-run, security or hacking. I’m betting that soon this will no longer be so.
Andrew Binstock is the principal analyst at Pacific Data Works LLC
|
|
Advertisement
Click here for a complete listing of Integration Watch Columns
Click here to see a complete Column Archive. |
Back to Top
|