Penyerangan XSS ( Cross-Site Scripting )

Cross-site scripting vulnerabilities date back to 1996 during the early days of the World
Wide Web (Web). A time when e-commerce began to take off, the bubble days of
Netscape,Yahoo, and the obnoxious blink tag. When thousands of Web pages were
under construction, littered with the little yellow street signs, and the “cool”Web sites
used Hypertext Markup Language (HTML) Frames.The JavaScript programming language
hit the scene, an unknown harbinger of cross-site scripting, which changed the
Web application security landscape forever. JavaScript enabled Web developers to create
interactive Web page effects including image rollovers, floating menus, and the despised
pop-up window. Unimpressive by today’s Asynchronous JavaScript and XML (AJAX) application
standards, but hackers soon discovered a new unexplored world of possibility.
Hackers found that when unsuspecting users visited their Web pages they could forcibly
load any Web site (bank, auction, store,Web mail, and so on) into an HTML Frame within
the same browser window.Then using JavaScript, they could cross the boundary between
the two Web sites, and read from one frame into the other.They were able to pilfer usernames
and passwords typed into HTML Forms, steal cookies, or compromise any confidential
information on the screen.The media reported the problem as a Web browser
vulnerability. Netscape Communications, the dominant browser vendor, fought back by
implementing the ”same-origin policy,” a policy restricting JavaScript on one Web site from
accessing data from another. Browser hackers took this as a challenge and began uncovering
many clever ways to circumvent the restriction.
In December 1999, David Ross was working on security response for Internet Explorer
at Microsoft. He was inspired by the work of Georgi Guninski who was at the time finding
flaws in Internet Explorer’s security model. David demonstrated that Web content could
expose “Script Injection” effectively bypassing the same security guarantees bypassed by
Georgi’s Internet Explorer code flaws, but where the fault seemed to exist on the server side
instead of the client side Internet Explorer code. David described this in a Microsoft-internal
paper entitled “Script Injection.”The paper described the issue, how it’s exploited, how the
attack can be persisted using cookies, how a cross-site scripting (XSS) virus might work, and
Input/Output (I/O) filtering solutions.
Eventually this concept was shared with CERT.The goal of this was to inform the
public so that the issue would be brought to light in a responsible way and sites would get
fixed, not just at Microsoft, but also across the industry. In a discussion around mid-January,
the cross organization team chose “Cross Site Scripting” from a rather humorous list of proposals:

• Unauthorized Site Scripting
• Unofficial Site Scripting
• Uniform Resource Locator (URL) Parameter Script Insertion
• Cross-site Scripting
• Synthesized Scripting
• Fraudulent Scripting

On January 25, 2000, Microsoft met with the Computer Emergency Response Team

(CERT), various vendors (e.g., Apache, and so forth) and other interested parties at a hotel

in Bellevue,WA to discuss the concept.

David re-wrote the internal paper with the help of Ivan Brugiolo, John Coates, and

Michael Roe, so that it was suitable for public release. In coordination with CERT,

Microsoft released this paper and other materials on February 2, 2000. Sometime during the

past few years the paper was removed from Microsoft.com; however, nothing ever dies on

the Internet. It can now be found at http://ha.ckers.org/cross-site-scripting.html

During the same time, hackers of another sort made a playground of HTML chat

rooms, message boards, guest books, and Web mail providers; any place where they could

submit text laced with HTML/JavaScript into a Web site for infecting Web users.This is

where the attack name “HTML Injection” comes from.The hackers created a rudimentary

form of JavaScript malicious software (malware) that they submitted into HTML forms to

change screen names, spoof derogatory messages, steal cookies, adjust the Web page’s colors,

proclaim virus launch warnings, and other vaguely malicious digital mischief. Shortly thereafter

another variant of the same attack surfaced.With some social engineering, it was found

that by tricking a user to click on a specially crafted malicious link would yield the same

results as HTML Injection.Web users would have no means of self-defense other than to

switch off JavaScript.

Over the years what was originally considered to be cross-site scripting, became simply

known as a Web browser vulnerability with no special name. What was HTML Injection

and malicious linking are what’s now referred to as variants of cross-site scripting, or “persistent”

and “non-persistent” cross-site scripting, respectively. Unfortunately this is a big reason

why so many people are confused by the muddled terminology. Making matters worse, the

acronym “CSS” was regularly confused with another newly born browser technology already

claiming the three-letter convention, Cascading Style Sheets. Finally in the early 2000’s, a

brilliant person suggested changing the cross-site scripting acronym to “XSS” to avoid confusion.

And just like that, it stuck. XSS had its own identity. Dozens of freshly minted white

papers and a sea of vulnerability advisories flooded the space describing its potentially devastating

impact. Few would listen.

Prior to 2005, the vast majority of security experts and developers paid little attention to

XSS.The focus transfixed on buffer overflows, botnets, viruses, worms, spyware, and others.

Meanwhile a million new Web servers appear globally each month turning perimeter firewalls

into swiss cheese and rendering Secure Sockets Layer (SSL) as quaint. Most believed

JavaScript, the enabler of XSS, to be a toy programming language. “It can’t root an operating

system or exploit a database, so why should I care? How dangerous could clicking on a link

or visiting a Web page really be?” In October of 2005, we got the answer. Literally overnight

the Samy Worm, the first major XSS worm, managed to shut down the popular social networking

Web site MySpace.The payload being relatively benign, the Samy Worm was

designed to spread from a single MySpace user profile page to another, finally infecting more

than a million users in only 24 hours. Suddenly the security world was wide-awake and

research into JavaScript malware exploded.

A few short months later in early 2006, JavaScript port scanners, intranet hacks,

keystroke recorders, trojan horses, and browser history stealers arrived to make a lasting

impression. Hundreds of XSS vulnerabilities were being disclosed in major Web sites and

criminals began combining in phishing scams for an effective fraud cocktail. Unsurprising

since according to WhiteHat Security more than 70 percent of Web sites are currently vulnerable.

Mitre’s Common Vulnerabilities and Exposures (CVE) project, a dictionary of publicly

known vulnerabilities in commercial and open source software products, stated XSS had

overtaken buffer overflows to become the number 1 most discovered vulnerability. XSS

arguably stands as the most potentially devastating vulnerability facing information security

and business online.Today, when audiences are asked if they’ve heard of XSS, the hands of

nearly everyone will rise.

Dikutip Dari : XSS Attack