Cross-site scripting can work when user input is utilized to create a dynamic Web page, and researchers say preventing such attacks is the responsibility of Web site programmers, who must validate any user input and weed out dangerous scripting and HTML.Cross-site scripting (XSS) attacks have become one of the better-known Web security vulnerabilities over the past four years, but they are still easy to carry out on large sites handling sensitive information, such as major banks, as a U.K. researcher recently demonstrated.
They make phishing attacks—which attempt to swipe user login information—harder to spot, even for the most alert users. And while they are simple for site designers to prevent, the errors seem to keep slipping through, security experts say.
XSS, also called script injection, can happen when user input is utilized to create a dynamic Web page—a sites search page, for example. Sites commonly allow such user input to be embedded directly in a URL.
The attack requires that a user click on a URL containing JavaScript or HTML that is disguised as user input. If the site doesnt double-check the user input, then once the dynamic page has rendered, the HTML or script is executed, allowing the attacker to carry out an exploit on the site.
Read more here about the new phishing technique.
In the case of script-injection attacks designed for phishing, the script causes the host site to display a malicious page of the attackers choice, rather than that of the real site. This could be a fake login page collecting passwords, for example.
Phishing has become a major issue because of the increasing volume and sophistication of attacks carried out via junk e-mail messages, often posing very convincingly as a message from a bank. Such attacks so far have relied on spoofing techniques, where a malicious URL is made to appear identical to a trusted URL, through a variety of techniques.
These exploits have a number of limitations, all related to the fact that the site the user is looking at is not really a trusted site, security experts say. For example, they dont open a secure SSL (Secure Sockets Layer) session, easily identifiable by a browser icon.
The main advantage of script-injection phishing attacks is that they are carried out on the trusted site itself. "If the user is vigilant and verifies the identity of the site by examining the SSL certificate, the attacker is still able to steal information," said Thomas Kristensen, chief technology officer at Denmark-based security firm Secunia. Such attacks work just as well on SSL sessions.
Like other kinds of phishing, XSS attacks require sophisticated social engineering—a user must be persuaded to visit an untrusted site or HTML e-mail and then to visit a trusted site via a link from the untrusted source.
All a user has to do to avoid the attack is to type in the trusted URL by hand or to find it via a trusted site such as a search engine. But scammers have shown that fake bank e-mails, for example, can be made very persuasive, experts say.
Script injection hasnt been used in any phishing exploits so far, researchers say. This is likely to be at least partly because XSS has two limitations that spoofing attacks dont. It takes some time and skill to hunt down vulnerabilities within trusted sites, although security researcher Sam Greenhalgh recently proved that this is far from impossible.
eWEEK.com successfully tested his script-injection demonstration on sites such as MasterCard, NatWest, Reuters and Barclaycard, using Internet Explorer on Windows XP with Release Candidate 2 of Service Pack 2, the Mozilla Firefox 0.9.1 browser and Apples Safari.
Click here to read about the final preview of the Firefox browser before its full release.
Secondly, once a scam comes to light, it would take about 10 minutes for an affected site to fix the problem. "The time to exploit it would be very limited, because it is a server-side bug," Kristensen said. "A vulnerability on the client side takes much longer to get users protected."
Besides phishing, researchers consider the most important kind of potential XSS attack to be browser-session hijacking. In this exploit, the malicious script is used to steal the temporary cookies that secure sites use to validate a user during his or her session. These usually have a short shelf life, but until they expire, a stolen cookie could allow an attacker to access a users bank account or carry out "one-click" purchases on an e-commerce site, for example.
Unlike some attacks, script injection isnt a software problem, experts say. "Browsers could have functionality to prevent it, but that is really the wrong place to be fixing the problem. It could be required functionality on certain Web sites," Kristensen said.
For insights on security coverage around the Web, check out eWEEK.com Security Center Editor Larry Seltzers Weblog.
Preventing script-injection attacks is the responsibility of Web site programmers, who must validate any user input and weed out dangerous scripting and HTML, researchers say.
"Web programmers can prevent most cross-site scripting attacks by validating form input and ensuring that all user data is correctly encoded before it is displayed or stored," Mike Prettejohn, president of Web analysis firm Netcraft Ltd., of Bath, England, said in an analysis of the issue. "Never trust user input is a basic security tenet designed to reduce the risk posed by Web forms."
Despite this rule, researchers say vulnerabilities continue to exist and arent difficult to find. One reason is that theyre created by Web developers, who might not be as security-conscious as IT staff, particularly if they are in-house developers, Secunias Kristensen said.
"You might have system administrators out there patching IIS [Internet Information Services], configuring firewall rules and doing everything by the book, but the problem is the developers," he said. "They make the site with functionality as the primary goal, and security is secondary. They might not consider something like script injection. You see that very commonly, unfortunately."
Check out eWEEK.coms Security Center at http://security.eweek.com for security news, views and analysis.
Be sure to add our eWEEK.com security news feed to your RSS newsreader or My Yahoo page: 
Network Security & Hardware 
