This section describes the status of this document at the
time of its publication. Other documents may supersede this
document. A list of current W3C publications and the latest
revision of this technical report can be found in the W3C technical reports index at
http://www.w3.org/TR/.
This document is published as a companion document to
[WSC-USECASES], to make some of
the group's analysis available to a larger public.
This document was developed by the Web Security Context Working
Group.
The content of this document is mostly analytic. This
document is published as a snapshot, and may be updated and
changed as needed when the Working Group's analysis develops
further.
Please send comments about this document to
public-usable-authentication@w3.org (with
public archive).
Publication as a Working Group Note does not imply
endorsement by the W3C Membership. This is a draft document and
may be updated, replaced or obsoleted by other documents at any
time. It is inappropriate to cite this document as other than
work in progress.
This document was produced by a group operating under the
5
February 2004 W3C Patent Policy. W3C maintains a public list of
any patent disclosures made in connection with the
deliverables of the group; that page also includes instructions
for disclosing a patent. An individual who has actual knowledge
of a patent which the individual believes contains
Essential Claim(s) must disclose the information in
accordance with
section 6 of the W3C Patent Policy.
This document includes a high-level analysis of threats
faced in common Web usage scenarios.
In the analysis, high-level threats are decomposed into
the vulnerabilities that can be used by an attacker to
realize that threat. These vulnerabilities can be met by
countermeasures, which can in turn have vulnerabilities of
their own, and so on.
For example, to lure a user to a site that is controlled
by an attacker, the attacker might use DNS spoofing (or
similar techniques) to divert the user to a site of the
attacker's choice. As a countermeasure, TLS could be
deployed. If that countermeasure is in place, an attacker can
try to obtain a certification authority to issue a
certificate that can be used as part of an attack.
For a more extensive introduction of the process, see
chapter 4, Threat Modeling, of [SECURECODE].
-
Luring Attacks - luring a user to the wrong
site so that he connects to address not owned by party
he believes it to be owned by
- Attacker registers domain names similar to that
of the legitimate domain and waits for users to
mistype or mis-remember a URL.
- Attacker convinces user to bookmark the
impersonated site's address with misleading
information
- Attacker constructs misleading page title
which the browser will automatically copy into
the default bookmark name.
- Attacker lures victim using a link in another
application
- Email
- IM
- VOIP
- Voice (e.g. calls purporting to be from
site's security department)
- Attacker inserts or replaces links provided by
other sites users trust (e.g. search engines)
- After user initiates a connection to the correct
address, the attacker attacker intercepts
communications to that address and forges responses
from that address
- Compromise a DNS server on route from root to
requested domain
- Intercept DNS request and replace query
response with forged response
- Insert data into user's hosts file so that
DNS query is not required (out of
scope---attacker this powerful easily insert
spyware)
-
Countermeasure: HTTPS - See 2.4 HTTPS
Branch of threat tree
- Intercept and replace communications between
client and the address of the legitimate site
- Take control of a system through which
communications is routed
- Create a wifi access point and lure users to
it
- Attack the infrastructure through which
routes are established (BGP-based attacks)
-
Site Impersonation Attacks - an attack in
which the attacker attempts to mimic someone else's
website. Potential goals include credential theft (e.g.
password theft), theft of other private information
from user (bank account and routing numbers), or
forging information sent to user (e.g. fake news story
that will cause user to buy or sell stock).
- Address spoofing
- Attacker registers confusing domain name
- semantic attacks
(e.g.,"ebay-security.com")
- syntax attacks (e.g., "paypai.com", use
of non-ASCII characters)
- Attacker takes advantage of browser
vulnerabilities
- Page Spoofing
- attacker copies content and indicators from
legitimate website content into the content of an
attack page (may add, remove or replace security
indicators)
- attacker uses pop-up windows that mimic
legitimate site
- attacker presents warning or error messages
(e.g., to confuse user, to justify why security
indicators/information is missing)
- Chrome Spoofing
- attacker copies chrome elements (e.g., green
EV address bar), entire chrome window or dialog
boxes into the content of a website (also known
as Picture in Picture Attacks)
- attacker mimics customized chrome content
(when customization is used as an anti-spoofing
technique, the attacker may use an educated guess
to replicate customization
- attacker exploits flaws in GUI logic to
control what is displayed in chrome elements
(e.g. in the title bar, status bar or address
bar)
-
Cross-site request forgery - (see [CSRF])- causing a user to unwittingly
send, to a legitimate site, a request containing data
that he/she would not otherwise intend to send (e.g. to
perform an action that he/she did not intend to
take).
- Attacker may first convince user to login to the
target legitimate website (possibly in a separate
window or tab).
- [Sequential first step] Attacker constructs a
link or form with field values that replicate
those that would be sent if user legitimately
wanted to perform this action.
- [Sequential second step] Attacker causes the
browser to send this link to the legitimate
website.
- Induce user to submit form data
- Lure user to click on link to cause GET
request with attacker-specified parameters
- Lure user to click on form that will send
HTTP POST request with attacker-specified
parameters
- Uses javascript to automatically send the
form (form.submit())
- If user is not already logged in, attacker
may rely on the user login when reaching the
site. Many sites will then process the form data
from the initial request.
-
Cross-site scripting- the injection of code
into vulnerable web applications, which copy this code
into web content in a form that would allow it to be
executed when read by another user. An exploited
cross-site scripting vulnerability can be used by
attackers to bypass access controls such as the same
origin policy. (This definition borrows heavily from
that of [XSS].) Potential goals
include session hijacking (e.g. stealing a session
cookie), credential theft (e.g. password theft), theft
of other private information from user (bank account
and routing numbers), or forging information sent to
user (e.g. fake news story that will cause user to buy
or sell stock).
- [First sequential step] Construct content to
appear on legitimate site
- Create an attack script to execute in other
users' browsers
- Use the script to instruct other user's
browsers to send script-accessible
credentials (e.g. cookies) or other data to
the attacker
-
Use the script, which will execute in
other user's browsers within the site's
domain context, in order to execute actions
as that user or to gather additional data.
(For example, adding the attacker as a
trusted user/friend/administrator as was
the case with the [MSPWORM].)
- Use the content or script to exploit a
vulnerability in the browser
- Create content intended to appear to the user
as if is content generated entirely by the
legitimate site (and not a rendering of other
user's input).
- Create HTML for a fake login form or
information request form which, when
submitted, directs data to attacker.
- Create HTML content with other misleading
information that might affect user behavior
(e.g. a fake news story that could cause a
stock's price to rise or fall).
- [Second sequential step] Inject content into
pages served by legitimate site
- Use a cross-site request forgery attack (see
above)
- Cross-site scripting attacks that use
this approach are known as type 1
attacks.
- Insert the script yourself into content that
the site will serve to other users (e.g. a
discussion group posting).
- Cross-site scripting attacks that use
this approach are known as type 2
attacks
-
Network-based eavesdropping- a passive
attack in which the attacker collects network traffic
and reads the data sent between the client and the
website. Potential goals include session hijacking
(e.g. stealing a session cookie), credential theft
(e.g. password theft), theft of other private
information from user (bank account and routing
numbers)
- Attacker gains physical access to network and
installs monitoring hardware/software
-
Attacker establishes rogue network (e.g. public
WiFi access point) and waits for victims to join
it
- Browser Exploits
- Man in the Middle (MITM) attacks
- Malware/Spyware Attacks
- keyloggers
- screen loggers
- altering the users local DNS hostfile (sometimes
referred to as "pharming")
- "transaction generator" - malware that hijacks a
legitimate login session to send requests or
transactions
- Credential database compromise
- Browser credential store
- Server store
- insider attacks
- external breach
- Masquerading attack
- reuse of credentials to masquerade as user
- Dictionary Attacks
- online
- offline
- Web timing attacks - using the time it takes a
website to respond to determine information about the
user (e.g., if they have an account at a particular
website)
This section serves as a repository for attacks that
have not yet been folded into the structure above.
- Iframe attacks- are these covered by cross site
scripting above?
- attacker forces arbitrary URL to be displayed on
a visible iframe at legitimate page
- attacker uses hidden iframe to inject content
into legitimate page, capture user input, etc
- DNS attacks
- cache poisoning
- Cryptographic attacks
- Attacks on the protocol (SSL/TLS)
- Attacks on the encryption methods
- system take-over attacks (install something on the
system the user agent is running on which could be used
later)
- Social Engineering Attacks (not covered above, but
these are within scope)
- Re-enrollment attack- convince user to re-enroll
their account or machine (e.g., to answer challenge
questions in sitekey)
- Convince users they are already logged in
- Get certification authority to issue you a cert
- Break public key in existing valid cert
- Break SSL/TLS protocol
- Prevent HTTPS from activating in the first place
- Intercept connections initiated via HTTP and
prevent redirect to HTTPS
The material in this note was created by Tyler Close,
Rachna Dhamija, Johnathan Nightingale, and Stuart
Schechter.
- CSRF
-
Cross-Site Request Forgery, Wikipedia entry,
retrieved on 15 October 2007. Available at
http://en.wikipedia.org/wiki/Cross-site_request_forgery.
- MSPWORM
- Technical
explanation of the MySpace Worm, anonymous,
retrieved on 15 October 2007. Available at
http://namb.la/popular/tech.html .
- SECURECODE
- Writing Secure Code, M. Howard, D.
LeBlanc. 2nd edition, Microsoft Press 2003.
- WSC-USECASES
-
Web Security Experience, Indicators and Trust: Scope and
Use Cases, T. Close, Editor, W3C Working Draft
(work in progress), 1 November 2007. This version is
http://www.w3.org/TR/2007/WD-wsc-usecases-20071101/. The
latest
version is available at
http://www.w3.org/TR/wsc-usecases/ .
- WSC-XIT
- Web
Security Context: Experience, Indicators, and
Trust, T. Roessler, A. Saldhana, Editors, W3C
Working Draft (work in progress), 1 November 2007. This
version is http://www.w3.org/TR/2007/WD-wsc-xit-20071101/.
The latest
version is available at http://www.w3.org/TR/wsc-xit/
.
- XSS
- Cross
Site Scripting, Wikipedia entry, retrieved on 15
October 2007. Available at
http://en.wikipedia.org/wiki/Cross_site_scripting.