Cross-site scripting, often abbreviated XSS, is a class of Web security issues. A recent research report stated that XSS is now the top security risk.
If, however, the script that generated the new content did not filter the URI, it would be possible for an attacker to feed the page a custom-designed URI that ran a script. The script could do almost anything, and the user would never know that he wasn't seeing legitimate content unless the hijacker was blatant.
This is potentially very bad, as it is one way to enable phishing. For example, suppose a Web page with a cross-site scripting vulnerability belonged to a bank. An attacker aware of the vulnerability could forge e-mails purporting to be from the bank, with URIs that indeed led to the bank's site, but contained some malicious script that wouldn't be obvious to a casual observer. Once a user clicked on the link in the e-mail and logged into the bank site, their login credentials (in the form of cookies) for the current session would be transmitted to the attacker, who would be able to take over the user's account as long as the session was active.
Cross-site scripting first received wide notice in February, 2000, when CERT Advisory CA-2000-02 Malicious HTML Tags Embedded in Client Web Requests was published. The original summary was:
"A Web site may inadvertently include malicious HTML tags or script in a dynamically generated page based on unvalidated input from untrustworthy sources. This can be a problem when a Web server does not adequately ensure that generated pages are properly encoded to prevent unintended execution of scripts, and when input is not validated to prevent malicious HTML from being presented to the user."
The systems affected were listed as "Web browsers" and "Web servers that dynamically generate pages based on unvalidated input."
One XSS example given in the original CERT Advisory is this link:
< AHREF="http://example.com/comment.cgi?mycomment = < SCRIPT > malicious code< /SCRIPT > " > Click here< /A >
Looking back at this example from the perspective of 6 years of dealing with XSS and malicious spammers, it seems a bit naive. After all, only a user who didn't bother to look at the link destination could be tricked into clicking on such a link. The presence of the tag "< SCRIPT >" would be enough to tip off a sophisticated user, as would the presence of other HTML, such as a "< FORM >" tag, that could be perverted to run scripts.
However, even a sophisticated user might be fooled if the script tag and malicious code were encoded. Attackers use tricks like encoding angle brackets as %3C, constructing unreadable numeric IP addresses, using alternate character sets, and so on. The safest policy for a user is (of course) never to click on links from untrusted sources.
The original CERT Advisory went on to explain the impact of cross-site scripting. It was and is chilling stuff. XSS creates the potential for attackers to force malicious actions on trusted servers, even on SSL-Encrypted servers. Even using a browser that lacks scripting support is not a foolproof solution, because attackers can still "alter the appearance of a page, modify its behavior, or otherwise interfere with normal operation."
It isn't even necessarily over after the first attack. Once malicious code has been executed, the attacker can place a modified or "poisoned" cookie on the victim's computer that compromises every future visit to the affected site. In even more dangerous exploits, the attacker can modify the victim's browser security policies, allowing the attacker to elevate his privilege on the victim's machine, potentially doing more serious damage or gaining access to valuable local information, such as additional stored passwords.