A variant of cross-site scripting called "reflected" cross-site scripting,
the HTTP Query Strings attack consists of passing a malicious script inside
an otherwise valid HTTP request query string. This is of significant concern
for sites that rely on dynamic, user-generated content such as bulletin
boards, news sites, blogs, and web enabled administration GUIs. The
malicious script may steal session data, browse history, probe files, or
otherwise execute attacks on the client side. Once the attacker has prepared
the malicious HTTP query it is sent to a victim user (perhaps by email, IM,
or posted on an online forum), who clicks on a normal looking link that
contains a poison query string. This technique can be made more effective
through the use of services like http://tinyurl.com/, which makes very small
URLs that will redirect to very large, complex ones. The victim will not
know what he is really clicking on.
Attack Execution Flow
Explore
Spider:
Using a browser or an automated tool, an attacker
follows all public links on a web site. He records
all the links he finds.
Attack Step Techniques
ID
Attack Step Technique Description
Environments
1
Use a spidering tool to follow and record
all links. Make special note of any links that
include parameters in the URL.
env-Web
2
Use a proxy tool to record all links visited
during a manual traversal of the web application.
Make special note of any links that include
parameters in the URL. Manual traversal of this
type is frequently necessary to identify forms
that are GET method forms rather than POST
forms.
env-Web
3
Use a browser to manually explore the
website and analyze how it is constructed. Many
browser's plugins are available to facilitate the
analysis or automate the URL discovery.
env-Web
Indicators
ID
type
Indicator Description
Environments
1
Positive
URL parameters are used by the application
or the browser (DOM)
env-Web
2
Inconclusive
Using URL rewriting, parameters may be part
of the URL path.
env-Web
3
Inconclusive
No parameters appear on the URL. Even though
none appear, the web application may still use
them if they are provided.
env-Web
4
Inconclusive
Application could use POST variable as GET
inside the application. Therefore, looking for
POST parameters and adding them to the query
string.
env-Web
5
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 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
Attempt variations on input
parameters:
Possibly using an automated tool, an attacker
requests variations on the URLs he spidered before.
He sends parameters that include variations of
payloads. He records all the responses from the
server that include unmodified versions of his
script.
Attack Step Techniques
ID
Attack Step Technique Description
Environments
1
Use a list of XSS probe strings to inject in
parameters of known URLs. If possible, the probe
strings contain a unique identifier.
env-Web
2
Use a proxy tool to record results of manual
input of XSS probes in known URLs.
env-Web
Indicators
ID
type
Indicator Description
Environments
1
Positive
The output of pages includes some form of a
URL parameter. E.g., ?error="File not Found"
becomes "File not Found" in the title of the web
page.
env-Web
2
Positive
Input parameters become part of JavaScript,
VBScript, or other script in a web page.
env-Web
3
Inconclusive
Nothing is returned to the web page. It may
be a stored XSS. The unique identifier from the
probe helps to trace the flow of the possible
XSS.
env-Web
Outcomes
ID
type
Outcome Description
1
Success
The attacker's cross-site
scripting string is repeated back 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, script, etc.)
2
Failure
All HTML-sensitive characters
are consistently re-encoded before being sent to
the web browser.
3
Inconclusive
Some sensitive characters are
consistently encoded, but others are
not.
Security Controls
ID
type
Security Control Description
1
Detective
Monitor input to web
servers, 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 generated HTTP
headers
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.
1
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.
2
Preventative
Apply appropriate
input validation to filter all user-controllable
input of scripting
syntax
3
Preventative
Appropriately encode
all browser output to avoid scripting
syntax
4
Preventative
Actively monitor the
application and either deny or redirect requests
from origins that appear to be generating XSS
probes.
Attack Prerequisites
Target client software must allow scripting such as Javascript. Server
software must allow display of remote generated HTML without sufficient
input or output validation.
Web applications that accept name value pairs in a HTTP Query string
are inherently at risk to any value (or name for that matter) that an
attacker would like to enter in the query string. This can be done
manually via web browser or trivially scripted to post the query string
to multiple sites. In the latter case, in the instance of many sites
using similar infrastructure with predictable http queries being
accepted and operated on (such as blogging software, Google
applications, and so on), a single malicious payload can be scritped to
target a wide variety of sites.
Web 2.0 type sites like Technorati and del.icio.us rely on user
generated content like tags to build http links that are displayed to
other users. del.icio.us allows users to identify sites, tag them with
metadata and provide URL, descriptions and more data. This data is then
echoed back to any other web browser that is interested in the link. If
the data is not validated by the del.icio.us site properly then an
abritrary code can be added into the standard http string sent to
del.icio.us by the attacker, for example formatted as normal content
with a URL and description and tagged as Java, and available to be
clicked on (and executed by) any user browsing for Java content that
clicks on this trojaned content.
Attacker Skills or Knowledge Required
Skill or Knowledge Level: Low
To place malicious payload on server via HTTP
Skill or Knowledge Level: High
Exploiting any information gathered by HTTP Query on script
host
Resources Required
Ability to send HTTP post to scripting host and collect output
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, including
remote and user-generated 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
Information Leakage
Run Arbitrary Code
Injection Vector
Script delivered through standard web server, such as a web server with
user-generated content.
Payload
HTTP Request Query String
Activation Zone
Client web browser where script is executed
Payload Activation Impact
Client web browser may be used to steal session data, passwords, cookies, and
other tokens.
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.