Cross Site Scripting

[Sep 29, 2006] How to defeat the new No. 1 security threat cross-site scripting

 September 29, 2006 (Computerworld) 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.

In a typical XSS scenario, a Web page might use JavaScript to dynamically generate some document content based on a field in a Uniform Resource Identifier (URI). In the normal course of events, the site itself would generate legitimate information for that field.

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, since 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.

This is considerably worse than an attack that takes users to a forged Web page, because it can in principle bypass most forms of authentication protection. After all, it's using the bank's own authentication system, and then hijacking the results. David Flanagan, author of JavaScript: The Definitive Guide, says cross-site scripting "enables a pernicious vulnerability whose roots go deep into the architecture of the Web."

Some history

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:

<A HREF="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 naïve. 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.

Sites that have had XSS vulnerabilities

You'd think that cross-site scripting would be restricted to sites designed and administered by the unsophisticated, and that once you got beyond mom-and-pop e-commerce sites, you'd be free of the problem. You'd be wrong; even very sophisticated, security-conscious sites have had XSS vulnerabilities.

As I have found by regular reading of security sites like the SANS Institute's Internet Storm Center, their Top 20 Most Critical Internet Security Vulnerabilities page, Microsoft's security home page, and Brian Krebs' Washington Post security blog (see for example, the entry Cross-Site Scripting Flaws Abound), cross-site scripting vulnerabilities have affected most browsers, many content management systems and many high-profile sites.

It's bad enough to find XSS vulnerabilities on eBay or Amazon, which are constant targets of spammers and crackers. But would you believe an XSS vulnerability on the National Security Agency's site, www.nsa.gov? On Verisign.com, one of the root certificate authorities for the Web? Visa.com? JPMorganChase.com? Nyse.com? Amex.com? They happened.

How Web sites can avoid XSS vulnerabilities

The original CERT advisory offered this advice to Web developers, as true today as it was in 2000: "Web Page Developers Should Recode Dynamically Generated Pages to Validate Output." The article goes on to explain that it isn't enough just to filter out "<", "&"="&" and="and" "=" /> " characters: CERT encourages developers to "restrict variables used in the construction of pages to those characters that are explicitly allowed and to check those variables during the generation of the output page. In addition, Web pages should explicitly set a character set to an appropriate value in all dynamically generated pages."

In support of this, because it's such as complicated subject, CERT offers a document full of guidelines for malicious code mitigation, which offers sample filtering code in C++, JavaScript, and Perl, plus sample HTML for setting the character set.

CERT also advised Web server administrators to apply a patch from their vendor. The singular "a patch" seems wildly funny in hindsight: I have lost track of the many patches to XSS vulnerabilities that have been issued over the years to every Web server and operating system. To paraphrase Jefferson, the price of site security is constant vigilance.

How consumers can repel XSS attacks

The original CERT advisory said that users should either disable scripting in their browser, or, if unwilling to do that, "Not Engage in Promiscuous Browsing." That sounds wildly funny in hindsight, but the additional information given at the time still holds. The emphases are mine:

"Since the most significant variations of this vulnerability involve cross-site scripting (the insertion of tags into another site's Web page), users can gain some protection by being selective about how they initially visit a Web site. Typing addresses directly into the browser (or using securely stored local bookmarks) is likely to be the safest way of connecting to a site.

"Users should be aware that even links to unimportant sites may expose other local systems on the network if the client's system resides behind a firewall, or if the client has cached credentials to access other Web servers (e.g., for an intranet). For this reason, cautious Web browsing is not a comparable substitute for disabling scripting.

"With scripting enabled, visual inspection of links does not protect users from following malicious links, since the attacker's Web site may use a script to misrepresent the links in the user's window. For example, the contents of the Goto and Status bars in Netscape are controllable by JavaScript."

In the intervening years, a number of products have attempted to help protect users from XSS attacks. I have tried and discarded half a dozen anti-phishing toolbars: so far, every one I have tried had more false positives than true warnings. Krebs recommends the Netcraft Anti-Phishing Toolbar, which is available free for Internet Explorer and Firefox. It appears to be useful, but I have no idea whether it will turn out to be any better than the toolbars I have already dumped.

Krebs also recommends the NoScript extension for Firefox. According to the download site, this tool "allows JavaScript, Java and other executable content only for trusted domains of your choice, e.g. your home-banking Web site." In principle, a whitelist approach to scripting should give you fairly good protection against unknown threats, but if your trusted home-banking Web site is compromised by a cross-site scripting attack after you've whitelisted it, all bets are off.

Judicious use of security zones can accomplish much the same results. If you set your browser's security policy to only turn on scripting for trusted sites, and truly screen your trusted sites, you get accomplish most of what the NoScript extension for Firefox can give you, even on Internet Explorer.

Ultimately, the best approach to any security threat is to defense in depth. By all means, turn off scripting for unknown sites. By all means, run a toolbar that warns you about phishing, if you can put up with the boy who cries wolf. At the same time, however, try to type in site addresses yourself rather than indiscriminately clicking on links sent to you in e-mails, even if they come from well-meaning friends.

Etc

Society

Groupthink : Two Party System as Polyarchy : Corruption of Regulators : Bureaucracies : Understanding Micromanagers and Control Freaks : Toxic Managers :   Harvard Mafia : Diplomatic Communication : Surviving a Bad Performance Review : Insufficient Retirement Funds as Immanent Problem of Neoliberal Regime : PseudoScience : Who Rules America : Neoliberalism  : The Iron Law of Oligarchy : Libertarian Philosophy

Quotes

War and Peace : Skeptical Finance : John Kenneth Galbraith :Talleyrand : Oscar Wilde : Otto Von Bismarck : Keynes : George Carlin : Skeptics : Propaganda  : SE quotes : Language Design and Programming Quotes : Random IT-related quotes :  Somerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose Bierce :  Bernard Shaw : Mark Twain Quotes

Bulletin:

Vol 25, No.12 (December, 2013) Rational Fools vs. Efficient Crooks The efficient markets hypothesis : Political Skeptic Bulletin, 2013 : Unemployment Bulletin, 2010 :  Vol 23, No.10 (October, 2011) An observation about corporate security departments : Slightly Skeptical Euromaydan Chronicles, June 2014 : Greenspan legacy bulletin, 2008 : Vol 25, No.10 (October, 2013) Cryptolocker Trojan (Win32/Crilock.A) : Vol 25, No.08 (August, 2013) Cloud providers as intelligence collection hubs : Financial Humor Bulletin, 2010 : Inequality Bulletin, 2009 : Financial Humor Bulletin, 2008 : Copyleft Problems Bulletin, 2004 : Financial Humor Bulletin, 2011 : Energy Bulletin, 2010 : Malware Protection Bulletin, 2010 : Vol 26, No.1 (January, 2013) Object-Oriented Cult : Political Skeptic Bulletin, 2011 : Vol 23, No.11 (November, 2011) Softpanorama classification of sysadmin horror stories : Vol 25, No.05 (May, 2013) Corporate bullshit as a communication method  : Vol 25, No.06 (June, 2013) A Note on the Relationship of Brooks Law and Conway Law

History:

Fifty glorious years (1950-2000): the triumph of the US computer engineering : Donald Knuth : TAoCP and its Influence of Computer Science : Richard Stallman : Linus Torvalds  : Larry Wall  : John K. Ousterhout : CTSS : Multix OS Unix History : Unix shell history : VI editor : History of pipes concept : Solaris : MS DOS :  Programming Languages History : PL/1 : Simula 67 : C : History of GCC development :  Scripting Languages : Perl history   : OS History : Mail : DNS : SSH : CPU Instruction Sets : SPARC systems 1987-2006 : Norton Commander : Norton Utilities : Norton Ghost : Frontpage history : Malware Defense History : GNU Screen : OSS early history

Classic books:

The Peter Principle : Parkinson Law : 1984 : The Mythical Man-Month :  How to Solve It by George Polya : The Art of Computer Programming : The Elements of Programming Style : The Unix Hater’s Handbook : The Jargon file : The True Believer : Programming Pearls : The Good Soldier Svejk : The Power Elite

Most popular humor pages:

Manifest of the Softpanorama IT Slacker Society : Ten Commandments of the IT Slackers Society : Computer Humor Collection : BSD Logo Story : The Cuckoo's Egg : IT Slang : C++ Humor : ARE YOU A BBS ADDICT? : The Perl Purity Test : Object oriented programmers of all nations : Financial Humor : Financial Humor Bulletin, 2008 : Financial Humor Bulletin, 2010 : The Most Comprehensive Collection of Editor-related Humor : Programming Language Humor : Goldman Sachs related humor : Greenspan humor : C Humor : Scripting Humor : Real Programmers Humor : Web Humor : GPL-related Humor : OFM Humor : Politically Incorrect Humor : IDS Humor : "Linux Sucks" Humor : Russian Musical Humor : Best Russian Programmer Humor : Microsoft plans to buy Catholic Church : Richard Stallman Related Humor : Admin Humor : Perl-related Humor : Linus Torvalds Related humor : PseudoScience Related Humor : Networking Humor : Shell Humor : Financial Humor Bulletin, 2011 : Financial Humor Bulletin, 2012 : Financial Humor Bulletin, 2013 : Java Humor : Software Engineering Humor : Sun Solaris Related Humor : Education Humor : IBM Humor : Assembler-related Humor : VIM Humor : Computer Viruses Humor : Bright tomorrow is rescheduled to a day after tomorrow : Classic Computer Humor

The Last but not Least Technology is dominated by two types of people: those who understand what they do not manage and those who manage what they do not understand ~Archibald Putt. Ph.D

The statements, views and opinions presented on this web page are those of the author (or referenced source) and are not endorsed by, nor do they necessarily reflect, the opinions of the Softpanorama society. We do not warrant the correctness of the information provided or its fitness for any purpose. The site uses AdSense so you need to be aware of Google privacy policy. You you do not want to be tracked by Google please disable Javascript for this site. This site is perfectly usable without Javascript.

Last modified: March, 12, 2019