An attack of this type exploits a programs' vulnerabilities that are
brought on by allowing remote hosts to execute scripts. The attacker
leverages this capability to execute scripts to execute his/her own script
by embedding it within other scripts that the target software is likely to
execute. The attacker must have the ability to inject script into script
that is likely to be executed. If this is done, then the attacker can
potentially launch a variety of probes and attacks against the web server's
local environment, in many cases the so-called DMZ, back end resources the
web server can communicate with, and other hosts.
With the proliferation of intermediaries, such as Web App Firewalls,
network devices, and even printers having JVMs and Web servers, there are
many locales where an attacker can inject malicious scripts. Since this
attack pattern defines scripts within scripts, there are likely privileges
to execute said attack on the host.
Of course, these attacks are not solely limited to the server side, client
side scripts like Ajax and client side Javascript can contain malicious
scripts as well. In general all that is required is for there to be
sufficient privileges to execute a script, but not protected against
writing.
Attack Execution Flow
Explore
Spider:
Using a browser or an automated tool, an attacker
records all entry points for inputs that happen to
be reflected in a client-side script element. These
script elements can be located in the HTML content
(head, body, comments), in an HTML tag, XML, CSS,
etc.
Attack Step Techniques
ID
Attack Step Technique Description
Environments
1
Use a spidering tool to follow and record
all non static links that are likely to have input
parameters (through forms, URL, fragments, etc.)
actively used by the Web application.
env-Web
2
Use a proxy tool to record all links visited
during a manual traversal of the web
application.
env-Web
3
Use a browser to manually explore the
website and analyze how it is constructed. Many
browsers' plugins are available to facilitate the
analysis or automate the discovery.
env-Web
Indicators
ID
type
Indicator Description
Environments
1
Positive
Inputs are used in a script element (script
tag, DOM, etc.) and not in another type of
element.
env-Web
2
Inconclusive
Using URL rewriting, parameters may be part
of the URL path or the URL fragment.
env-Web
3
Inconclusive
No parameters appear to be used on the
current page. Even though none appear, the web
application may still use them if they are
provided.
env-Web
4
Negative
Applications that have only static pages or
that simply present information without accepting
input are unlikely to be susceptible.
env-Web
Outcomes
ID
type
Outcome Description
1
Success
A list of URLs, with their
corresponding parameters (POST, GET, COOKIE, etc.)
is created by the attacker. These parameters are
possibly used in client-side scripts
elements.
2
Success
A list of application user
interface entry fields is created by the
attacker.
3
Success
A list of resources accessed by
the application is created by the
attacker.
Security Controls
ID
type
Security Control Description
1
Detective
Monitor velocity of
page fetching in web logs. Humans who view a page
and select a link from it will click far slower
and far less regularly than tools. Tools make
requests very quickly and the requests are
typically spaced apart regularly (e.g. 0.8 seconds
between them).
2
Detective
Create links on some
pages that are visually hidden from web browsers.
Using IFRAMES, images, or other HTML techniques,
the links can be hidden from web browsing humans,
but visible to spiders and programs. A request for
the page, then, becomes a good predictor of an
automated tool probing the
application.
3
Preventative
Use CAPTCHA to prevent
the use of the application by an automated
tool.
4
Preventative
Actively monitor the
application and either deny or redirect requests
from origins that appear to be
automated.
Experiment
Probe identified potential entry points
for XSS vulnerability:
The attacker uses the entry points gathered in the
"Explore" phase as a target list and injects various
common script payloads to determine if an entry
point actually represents a vulnerability and to
characterize the extent to which the vulnerability
can be exploited.
Attack Step Techniques
ID
Attack Step Technique Description
Environments
1
Manually inject various script payloads into
each identified entry point using a list of common
script injection probes that typically work in a
client-side script elements context and observe
system behavior to determine if script was
executed.
env-Web
2
Manually inject various script payloads into
each identified entry point using a list of common
script injection probes that typically work in a
server-side script elements context and observe
system behavior to determine if script was
executed.
env-Web
3
Use an automated injection attack tool to
inject various script payloads into each
identified entry point using a list of common
script injection probes that typically work in a
client-side script elements context and observe
system behavior to determine if script was
executed.
env-Web
4
Use an automated injection attack tool to
inject various script payloads into each
identified entry point using a list of common
script injection probes that typically work in a
server-side script elements context and observe
system behavior to determine if script was
executed.
env-Web
5
Use a proxy tool to record results of the
created requests.
env-Web
Indicators
ID
type
Indicator Description
Environments
1
Positive
User-controllable input is output back to
the browser
env-Web
2
Positive
User-controllable input is embedded as part
of script elements
env-Web
3
Positive
Output to the browser is not encoded to
remove executable scripting syntax
env-Web
4
Positive
Server-side components execute script
elements containing user-controllable input
env-Web
Outcomes
ID
type
Outcome Description
1
Success
The attacker's script string is
being reflected verbatim at some point in the web
site (if not on the same page). Note that
sometimes, the payload might be well encoded in
the page, but wouldn't be encoded at all in some
other section of the same web page (title,
etc.)
2
Success
The attacker's script string is
executed by the server-side
component.
3
Failure
All context-sensitive
characters are consistently re-encoded before
being sent to the web
browser.
4
Inconclusive
Some sensitive characters are
consistently encoded, but others are not.
Depending on which type of non-script element the
payload is injected in, it may be possible to
evade the encodings.
Security Controls
ID
type
Security Control Description
1
Detective
Monitor input to web
servers (not only GET, but all potential inputs
like COOKIES, POST, HEADER), application servers,
and other HTTP infrastructure (e.g., load
balancers). Alert on standard XSS probes. The
majority of attackers use well known strings to
check for vulnerabilities. Use the same
vulnerability catalogs that hackers
use.
2
Preventative
Apply appropriate
input validation to filter all user-controllable
input of scripting
syntax
3
Preventative
Do not embed
user-controllable input in script
elements.
4
Preventative
Actively monitor the
application and either deny or redirect requests
from origins that appear to be generating XSS
probes.
As the attacker succeeds in exploiting the
vulnerability, he can choose to steal user's
credentials in order to reuse or to analyze them
later on.
Attack Step Techniques
ID
Attack Step Technique Description
Environments
1
Develop malicious JavaScript that is
injected through vectors identified during the
Experiment Phase and loaded by the victim's
browser and sends document information to the
attacker.
env-Web
2
Develop malicious JavaScript that injected
through vectors identified during the Experiment
Phase and takes commands from an attacker's server
and then causes the browser to execute
appropriately.
env-Web
Outcomes
ID
type
Outcome Description
1
Success
The attacker gets the user's
cookies or other session
identifiers.
2
Success
The attacker gets the content
of the page the user is
viewing.
3
Success
The attacker causes the user's
browser to visit a page with malicious
content.
Security Controls
ID
type
Security Control Description
1
Detective
Monitor server logs
for scripting
parameters.
2
Detective
Monitor server logs
for referrers. If users are being tricked into
clicking XSS links through forums or other web
postings, their web browsers will be providing
Referrer headers most of the time. These can help
indicate that the actual request is
illegitimate.
3
Preventative
Apply appropriate
input validation to filter all user-controllable
input of scripting
syntax
4
Preventative
Appropriately encode
all browser output to avoid scripting
syntax
5
Preventative
Actively monitor the
application and either deny or redirect requests
from origins that appear to be generating XSS
probes.
Forceful browsing:
When the attacker targets the current application
or another one (through CSRF vulnerabilities), the
user will then be the one who perform the attacks
without being aware of it. These attacks are mostly
targeting application logic flaws, but it can also
be used to create a widespread attack against a
particular website on the user's current network
(Internet or not).
Attack Step Techniques
ID
Attack Step Technique Description
Environments
1
Develop malicious JavaScript that is
injected through vectors identified during the
Experiment Phase and loaded by the victim's
browser and performs actions on the same web
site
env-Web
2
Develop malicious JavaScript that injected
through vectors identified during the Experiment
Phase and takes commands from an attacker's server
and then causes the browser to execute request to
other web sites (especially the web applications
that have CSRF vulnerabilities).
env-Web
Outcomes
ID
type
Outcome Description
1
Success
The attacker indirectly
controls the user's browser and makes it
performing actions exploiting
CSRF.
2
Success
The attacker manipulates the
browser through the steps that he designed in his
attack. The user, identified on a website, is now
performing actions he is not aware
of.
Security Controls
ID
type
Security Control Description
1
Detective
Monitor server logs
for scripting
parameters.
2
Detective
Monitor server logs
for referrers. If users are being tricked into
clicking XSS links through forums or other web
postings, their web browsers will be providing
Referrer headers most of the time. These can help
indicate that the actual request is
illegitimate.
3
Preventative
Apply appropriate
input validation to filter all user-controllable
input of scripting
syntax
4
Preventative
Appropriately encode
all browser output to avoid scripting
syntax
5
Preventative
Actively monitor the
application and either deny or redirect requests
from origins that appear to be generating XSS
probes.
Content spoofing:
By manipulating the content, the attacker targets
the information that the user would like to get from
the website.
Attack Step Techniques
ID
Attack Step Technique Description
Environments
1
Develop malicious JavaScript that is
injected through vectors identified during the
Experiment Phase and loaded by the victim's
browser and exposes attacker-modified invalid
information to the user on the current web
page.
env-Web
Outcomes
ID
type
Outcome Description
1
Success
The user sees a page containing
wrong information
Security Controls
ID
type
Security Control Description
1
Detective
Monitor server logs
for scripting
parameters.
2
Detective
Monitor server logs
for referrers. If users are being tricked into
clicking XSS links through forums or other web
postings, their web browsers will be providing
Referrer headers most of the time. These can help
indicate that the actual request is
illegitimate.
3
Preventative
Apply appropriate
input validation to filter all user-controllable
input of scripting
syntax
4
Preventative
Appropriately encode
all browser output to avoid scripting
syntax
5
Preventative
Actively monitor the
application and either deny or redirect requests
from origins that appear to be generating XSS
probes.
Attack Prerequisites
Target software must be able to execute scripts, and also allow attacker
to write/upload script
Typical Likelihood of Exploit
Likelihood: High
Methods of Attack
Injection
API Abuse
Examples-Instances
Description
Ajax applications enable rich functionality for browser based web
applications. Applications like Google Maps deliver unprecedented
ability to zoom in and out, scroll graphics, and change grapic
presentation through Ajax. The security issues that an attacker may
exploit in this instance are the relative lack of security features in
Javascript and the various browser's implementation of Javascript, these
security gaps are what XSS and a host of other client side
vulnerabilities are based on. While Ajax may not open up new security
holes, per se, due to the conversational aspects between client and
server of Ajax communication, attacks can be optimized. A single zoom in
or zoom out on a graphic in an Ajax application may round trip to the
server dozens of times. One of the first steps many attackers take is
frequently footprinting an environment, this can include scanning local
addresses like 192.*.*.* IP addresses, checking local directories,
files, and settings for known vulnerabilities, and so on.
<IMG SRC=javascript:alert('XSS')>
The XSS script that is embeded in a given IMG tag can be manipulated
to probe a different address on every click of the mouse or other
motions that the Ajax application is aware of.
In addition the enumerations allow for the attacker to nest sequential
logic in the attacks. While Ajax applications do not open up brand new
attack vectors, the existing attack vectors are more than adequate to
execute attacks, and now these attacks can be optimized to sequentially
execute and enumerate host environments.
Attacker Skills or Knowledge Required
Skill or Knowledge Level: Low
To load malicious script into open, e.g. world writable
directory
Skill or Knowledge Level: Medium
Executing remote scripts on host and collecting output
Resources Required
Ability to deploy a custom script on host
Solutions and Mitigations
Design: Use browser technologies that do not allow client side
scripting.
Design: Utilize strict type, character, and encoding enforcement
Design: Server side developers should not proxy content via XHR or other
means, if a http proxy for remote content is setup on the server side, the
client's browser has no way of discerning where the data is originating
from.
Implementation: Ensure all content that is delivered to client is
sanitized against an acceptable content specification.
Implementation: Perform input validation for all remote content.
Implementation: Perform output validation for all remote content.
Implementation: Disable scripting languages such as Javascript in
browser
Implementation: Session tokens for specific host
Implementation: Patching software. There are many attack vectors for XSS
on the client side and the server side. Many vulnerabilities are fixed in
service packs for browser, web servers, and plug in technologies, staying
current on patch release that deal with XSS countermeasures mitigates
this.
Implementation: Privileges are constrained, if a script is loaded, ensure
system runs in chroot jail or other limited authority mode
Attack Motivation-Consequences
Run Arbitrary Code
Privilege Escalation
Injection Vector
Malicious input delivered through standard script page, e.g. ASP web
page
Payload
Varies with instantiation of attack pattern. MAy contain network probe or
attacks that run against or on host using host account permissions
Activation Zone
Web server scripting host
Payload Activation Impact
Enables attacker to execute scripts on remote host
Vision and Technical Leadership provided by Cigital, Inc.
This Web site is hosted by The MITRE Corporation.
Copyright 2009, The MITRE Corporation. CAPEC and the CAPEC logo are trademarks of The MITRE Corporation.
Description
