You know about cross-site scripting (XSS). It's an attack that injects malicious code into a vulnerable application such that the code executes in the victim's application viewer and, therefore, with the victim's session privileges. In most cases, the viewer is a web browser and the malicious code is written in JavaScript. (XSS won over the arguably more correct abbreviation "CSS" because of confusions with an unrelated term Cascading Style Sheets.) In theory, the victim's viewer could be another application, rather than a web browser. Imagine a vulnerable website that accepts code as input from the attacker and, without properly filtering on input or output, incorporates the code into a spreadsheet that the victim views in Excel. If the attacker could find a way to supply code that Excel will execute, then we have an instance where an XSS attack targeted a non-web browser.

I suppose we could call this a cross-application cross-site scripting (XAXSS) attack. (I wouldn't want to suggest the abbreviation "CAXSS" because then people could confuse it with the term Computer Assisted X-ray Screening System.) XSS has been discussed for a while. Even though the mechanisms of such attacks are well-understood, XSS vulnerabilities continue to plague many web-based applications. SecurityFix mentioned a number of popular sites that have had XSS holes.

The link for this article located at SANS is no longer available.