Securing the web: New tool would automatically plug holes that hackers exploit

October 8, 2009 by Larry Hardesty,
Graphic: Christine Daniloff

( -- More and more, malicious hackers are exploiting web site security holes to attack their victims' computers. Programmers try to identify those holes in advance and plug them with code that performs security checks; but if they find a hundred holes and miss one, their programs are still insecure. At next week's ACM Symposium on Operating Systems Principles, however, MIT researchers will present a new system called Resin, which automatically calls up security checks whenever they're required, even in unforeseen circumstances.

Typically, web programmers will associate security checks with particular application functions. If you belonged to a social-networking site, for instance, you might be able to e-mail your friends, or post remarks on their pages, or comment on their own posts, or tag their pictures, and so on. Each of these operations executes its own chunk of code, and the developer will usually attach a security check to each chunk, to ensure that the user is authorized to invoke it. (These types of security checks operate in the background: they don't require you, for instance, to reenter your user name and password.) Many web applications also "sanitize" data posted by their subscribers: if a friend posts something to your social-network page, the application probably won't show you the post without inspecting it for malicious code.

"We've looked at a lot of these web applications, and there's literally hundreds of places where these checks happen," says Nickolai Zeldovich, an assistant professor in MIT's Computer Science and Lab. Indeed, Zeldovich and his colleagues identified one popular web application that sanitized data in more than 1,400 places (but still had about 60 security holes).

They also, however, identified a feature that web application security checks usually had in common: "Namely," Zeldovich says, "it's that the same data is being handled in all these hundreds of places."

So Zeldovich, grad students Alexander Yip and Xi Wang, and Professor Frans Kaashoek developed a system that associates security checks with particular chunks of data rather than with particular chunks of code. Any attempt to access the data, by any imaginable route, invokes the check.

The researchers modified 12 existing applications written in the popular web programming languages Python and PHP so that they used the Resin system. In experiments, the modified applications repelled attacks that exploited known security holes. But the researchers also developed their own attacks, which Resin thwarted as well.

For programmers, the new system should be easy to adopt. They're already writing code for security checks and sanitization anyway; now, they'd have to write it only once, instead of pasting it into their programs in hundreds of different places.

But the MIT system relies on additional software that tracks data as they flow through an application, to make sure that security rules remain associated with the information wherever it's being stored and however it's being used. And the data tracker presents the biggest obstacle to commercial adoption.

Web applications need to run on any type of computer, regardless of the operating system or web browser being used, so web languages like Python and PHP require an extra layer of software called a "runtime" to translate code into the language spoken by a given machine. Generally, the organizations that develop new programming languages also maintain the runtimes, which undergo sequential releases, just like any commercial program. The MIT system's data tracker would have to be incorporated into several different languages' runtimes, which could be a hard sell.

"At least in PHP, the focus tends to be on performance," says Eddie Kohler, an assistant professor of computer science at UCLA. Resin, Kohler says, "shows that you can do it without too much of a performance loss," but "it's not zero; it's not a performance gain." Kohler points out, however, that Resin could gain traction with the runtime gatekeepers if it first proves itself in some particular, real-world instances. "A place like, maybe Facebook, say, that runs other people's code on their servers already has an environment where they're much more worried about people stealing data out of their servers than they are necessarily about getting the last two percent of performance," Kohler says. "I expect that as it gets deployed, it would get deployed by individual companies first."

Provided by Massachusetts Institute of Technology (news : web)

Explore further: How to Protect Your Web Server from Attacks

Related Stories

How to Protect Your Web Server from Attacks

October 11, 2007

The National Institute of Standards and Technology has released a new publication that provides detailed tips on how to make web servers more resistant to potential attacks. Called “Guidelines on Securing Public Web Servers,” ...

Software Tool Plugs Security Leaks

August 1, 2007

Often when you make an Internet transaction, symbols on the Web page assure you that your transaction will be secure and that private information about you, such as passwords, bank account or credit card numbers, will not ...

Java Security Traps Getting Worse

May 10, 2007

A year ago at JavaOne , Fortify Software Founder and Chief Scientist Brian Chess gave a presentation titled " 12 Java Technology Security Traps and How to Avoid Them ."

Hackers breach US air traffic control computers

May 8, 2009

Hackers broke into US air traffic control computers on several occasions over the past few years and increased reliance on Web applications and commercial software has made networks more vulnerable, according to a government ...

Recommended for you


Adjust slider to filter visible comments by rank

Display comments: newest first

not rated yet Oct 08, 2009
Hardware is now so cheap that all performance losses caused by implementing better protection from hack attacks can be easily compensated for by additional processing and memory resources, (be it an additional computing unit in a server farm, or a processor upgrade in a single server ... or just some more/faster memory).

Not taking preemptive action should be considered neglegence, and systems from which the clients' private information is lost should be audited, evaluated and the owners penalised where all reasonable measures are not employed.

Education of the end-users, (obvious warnings about the possibilities of information loss), should also be encouraged on social networks.
not rated yet Oct 08, 2009
The process of securing data at one point is nothing new by any stretch of the imagination. In fact, we developers routinely do this in a software layer we call a DAL (Data Access Layer) where all reads and writes of the data go through the DAL.

We also write multiple business logic layers on top of the DAL. This is were higher level logic decisions are made and there's even more security built into these.

Finally, at the very top of the "thought" process stack, so to speak, is the actual application logic which simply asks the business layer to do stuff.

Securing data as it moves has probably been implemented in a few places too and is not as common and has certainly been discussed.

They're all good practices, but nothing new.

Please sign in to add a comment. Registration is free, and takes less than a minute. Read more

Click here to reset your password.
Sign in to get notified via email when new comments are made.