While this thread has been focused on scripting languages and cookie theft, that's not the only issue to be concerned about with XSS. Being able to place arbitrary HTML into an intermediate web page is dangerous for other reasons (this is sometimes called "HTML injection," but I view it as another flavor of XSS). For example, this would allow attackers to use META-REFRESH style attacks to redirect victims away from the intended web site. META-REFRESH has also been an important component in some vulnerabilities. More importantly, HTML injection could be used to "anonymously" exploit certain web client vulnerabilities by inserting malicious HTML into XSS-vulnerable sites (the only "trace" might be the web site's logs). Such attacks do not require cookies and could be indistinguishable from genuine content. Not all web client vulnerabilities require scripting languages to exploit. As another example, the "FRAME SECURITY=RESTRICTED" feature described by Michael Howard could be defeated by HTML injection - the attacker could inject a </FRAME> tag and follow it with the malicious code. This could also apply to the <dead> tag proposed by Seth Arnold, at least in some cases. Despite this, these mechanisms would definitely have some benefit - especially when a program *tries* to avoid XSS but doesn't catch every single instance. Some people argue that XSS is not always serious because attackers have to be "enticed" to click on links. But what if, say, a major bulletin board with thousands of visitors has an XSS bug that allows an attacker to exploit web client vulnerabilities? Using XSS style attacks to inject arbitrary HTML into popular web pages is therefore a serious concern with other implications beyond what's already been said. It would be nice to develop protection mechanisms that address more than just cookie theft, but it seems difficult when a web document can have so many different content types scattered in arbitrary locations throughout the document. - Steve
