A Blueprint to Stop Browser Attacks
A software layer protects against cross-site scripting attacks.
As user-generated content has become more popular online, websites have increasingly allowed users to customize, for example, their blog comments or posts to social-networking sites with HTML code. However, this also opens websites up to the risk of a type of attack known as cross-site scripting, which can allow attackers to steal information from users via a trusted site.
Next week, at the IEEE Symposium on Security and Privacy, in Oakland, CA, researchers from the University of Illinois at Chicago will present a new way to defend against cross-site scripting. The approach lets a website control how user-generated content is transmitted to a Web browser, potentially neutralizing cross-site scripting attacks before they can reach the intended victim.
Cross-site scripting involves getting a user’s browser to run an unauthorized script injected somewhere on the pages of an apparently trustworthy website. The script might let an attacker steal a user’s log-in credentials or other sensitive information.
“Cross-site scripting is the most prevalent vulnerability on the Internet,” says Jeremiah Grossman, founder and chief technology officer for White Hat Security, who was not involved in the research. “It’s kind of a cockroach out there in the industry.” Grossman says that newer websites are better equipped to defend against cross-site scripting, but there are still millions of vulnerable sites on the Internet. “We need alternatives to fixing the code,” he says.
The University of Illinois researchers developed a layer of software–called Blueprint–that Web developers can insert between user-generated pages and the browser. The researchers designed Blueprint to work with eight major browsers, which make up more than 96 percent of current market share, and tested the system against 94 types of cross-site scripting attacks taken from an Internet repository called the XSS Cheat Sheet. They found that it successfully prevented every attack on the list.
Blueprint sits on a website’s servers, reads user-generated HTML, and checks it against a white list of trusted code. It removes any potentially harmful scripts and decides how the content should appear in a browser. Then it reformats the information and transmits it to the browser. Blueprint makes sure, for example, to avoid characters and symbols that are sometimes used to send unauthorized scripting signals to a user’s browser. Nonharmful content should make it through the process unaffected, the researchers say.
The root of the problem, explains V. N. Venkatakrishnan, an assistant professor of computer science who was involved in the project, is that browsers were originally designed to be forgiving of badly written Web-page code. “Browsers try to do the best possible rendering of any type of poorly formatted content,” he says.
Over the years, different browsers have developed their own ways of interpreting poorly formatted content. Attackers can take advantage of this by inserting HTML that will run as a script in the right browser. “This makes the problem of filtering HTML content for scripts very, very challenging,” Venkatakrishnan says. Efforts are under way to change the way browsers work, but the researchers say that another solution is needed in the meantime.
“What we want to do is to take away the ability for the browser’s parser to make any script-identification decisions on the untrusted content that is supplied by the Web application,” Venkatakrishnan says.
Robert Hansen, CEO and founder of the Internet security company SecTheory, which maintains the XSS Cheat Sheet, says that, although Blueprint protects against most major cross-site scripting threats, it doesn’t cover all possible threats. “There are other ways to get stuff rendered inside a browser, and unfortunately, this doesn’t cover any of those,” he says.
Hansen adds that the researchers’ system protects content by wrapping it in a script that search engines can’t read. “This isn’t a panacea,” he says, “but that’s the big issue.” Hansen says that cross-site scripting is too complex a problem to be stopped without changing how the browser works.