Chapter 1- Web Application Security Fundamentals

Improving Web Application Security: Threats and Countermeasures

J.D. Meier, Alex Mackman, Michael Dunner, Srinath Vasireddy, Ray Escamilla and Anandha Murukan
Microsoft Corporation
u!lished" June #$$%
See the &patterns ' practices Security (uidance for Applications )ndex& for links to additional security resources.
See the *andin+ a+e for the startin+ point and a complete o,er,ie- of Improving Web Application Security:
Threats and Countermeasures.
Summary: .his chapter introduces /e! application security, explains common security terminolo+y and presents a
set of pro,en security principles upon -hich many of the recommendations throu+hout this +uide are !ased. )t
presents an o,er,ie- of the security process and explains -hy a holistic approach to security that co,ers multiple
layers includin+ the net-ork, host and application, is re0uired to achie,e the +oal of hack1resilient /e!
applications. .his chapter also introduces and defines host confi+uration cate+ories and application ,ulnera!ility
cate+ories, -hich are used throu+hout the remainder of this +uide.
Contents
/e Are Secure 11 /e 2a,e a 3ire-all
/hat Do /e Mean 4y Security5
.hreats, Vulnera!ilities, and Attacks Defined
2o- Do 6ou 4uild a Secure /e! Application5
Secure 6our 7et-ork, 2ost, and Application
Securin+ 6our 7et-ork
Securin+ 6our 2ost
Securin+ 6our Application
Security rinciples
Summary
Additional Resources
/hen you hear talk a!out /e! application security, there is a tendency to immediately think a!out attackers
defacin+ /e! sites, stealin+ credit card num!ers, and !om!ardin+ /e! sites -ith denial of ser,ice attacks. 6ou
mi+ht also think a!out ,iruses, .ro8an horses, and -orms. .hese are the types of pro!lems that recei,e the most
press !ecause they represent some of the most si+nificant threats faced !y today9s /e! applications.
.hese are only some of the pro!lems. :ther si+nificant pro!lems are fre0uently o,erlooked. )nternal threats posed
!y ro+ue administrators, dis+runtled employees, and the casual user -ho mistakenly stum!les across sensiti,e
data pose si+nificant risk. .he !i++est pro!lem of all may !e i+norance.
.he solution to /e! application security is more than technolo+y. )t is an on+oin+ process in,ol,in+ people and
practices.
We Are Secure We Have a Firewall
.his is a common misconception; it depends on the threat. 3or example, a fire-all may not detect malicious input
sent to your /e! application. Also, consider the scenario -here a ro+ue administrator has direct access to your
application.
Do fire-alls ha,e their place5 :f course they do. 3ire-alls are +reat at !lockin+ ports. Some fire-all applications
examine communications and can pro,ide ,ery ad,anced protection. 3ire-alls are an inte+ral part of your security,
!ut they are not a complete solution !y themsel,es.
.he same holds true for Secure Sockets *ayer <SS*=. SS* is +reat at encryptin+ traffic o,er the net-ork. 2o-e,er,
it does not ,alidate your application9s input or protect you from a poorly confi+ured ser,er.
What o We !ean "y Security#
Security is fundamentally a!out protectin+ assets. Assets may !e tan+i!le items, such as a /e! pa+e or your
customer data!ase > or they may !e less tan+i!le, such as your company9s reputation.
Security is a path, not a destination. As you analy?e your infrastructure and applications, you identify potential
threats and understand that each threat presents a de+ree of risk. Security is a!out risk mana+ement and
implementin+ effecti,e countermeasures.
The Foundations o$ Security
Security relies on the follo-in+ elements"

Authentication
Authentication addresses the 0uestion" -ho are you5 )t is the process of uni0uely identifyin+ the clients of
your applications and ser,ices. .hese mi+ht !e end users, other ser,ices, processes, or computers. )n
security parlance, authenticated clients are referred to as principals.

Authori%ation
Authori?ation addresses the 0uestion" -hat can you do5 )t is the process that +o,erns the resources and
operations that the authenticated client is permitted to access. Resources include files, data!ases, ta!les,
ro-s, and so on, to+ether -ith system1le,el resources such as re+istry keys and confi+uration data.
:perations include performin+ transactions such as purchasin+ a product, transferrin+ money from one
account to another, or increasin+ a customer9s credit ratin+.

Auditing
Effecti,e auditin+ and lo++in+ is the key to non1repudiation. 7on1repudiation +uarantees that a user
cannot deny performin+ an operation or initiatin+ a transaction. 3or example, in an e1commerce system,
non1repudiation mechanisms are re0uired to make sure that a consumer cannot deny orderin+ @$$ copies
of a particular !ook.

Con$identiality
Confidentiality, also referred to as privacy, is the process of makin+ sure that data remains pri,ate and
confidential, and that it cannot !e ,ie-ed !y unauthori?ed users or ea,esdroppers -ho monitor the flo- of
traffic across a net-ork. Encryption is fre0uently used to enforce confidentiality. Access control lists <AC*s=
are another means of enforcin+ confidentiality.

Integrity
)nte+rity is the +uarantee that data is protected from accidental or deli!erate <malicious= modification.
*ike pri,acy, inte+rity is a key concern, particularly for data passed across net-orks. )nte+rity for data in
transit is typically pro,ided !y usin+ hashin+ techni0ues and messa+e authentication codes.

Availability
3rom a security perspecti,e, a,aila!ility means that systems remain a,aila!le for le+itimate users. .he
+oal for many attackers -ith denial of ser,ice attacks is to crash an application or to make sure that it is
sufficiently o,er-helmed so that other users cannot access the application.
Threats& 'ulnerabilities& and Attac(s e$ined
A threat is any potential occurrence, malicious or other-ise, that could harm an asset. )n other -ords, a threat is
any !ad thin+ that can happen to your assets.
A ,ulnera!ility is a -eakness that makes a threat possi!le. .his may !e !ecause of poor desi+n, confi+uration
mistakes, or inappropriate and insecure codin+ techni0ues. /eak input ,alidation is an example of an application
layer ,ulnera!ility, -hich can result in input attacks.
An attack is an action that exploits a ,ulnera!ility or enacts a threat. Examples of attacks include sendin+ malicious
input to an application or floodin+ a net-ork in an attempt to deny ser,ice.
.o summari?e, a threat is a potential e,ent that can ad,ersely affect an asset, -hereas a successful attack exploits
,ulnera!ilities in your system.
How o )ou "uild a Secure Web Application#
)t is not possi!le to desi+n and !uild a secure /e! application until you kno- your threats. An increasin+ly
important discipline and one that is recommended to form part of your application9s desi+n phase is threat
modelin+. .he purpose of threat modelin+ is to analy?e your application9s architecture and desi+n and identify
potentially ,ulnera!le areas that may allo- a user, perhaps mistakenly, or an attacker -ith malicious intent, to
compromise your system9s security.
After you kno- your threats, desi+n -ith security in mind !y applyin+ time-orn and pro,en security principles. As
de,elopers, you must follo- secure codin+ techni0ues to de,elop secure, ro!ust, and hack1resilient solutions. .he
desi+n and de,elopment of application layer soft-are must !e supported !y a secure net-ork, host, and
application confi+uration on the ser,ers -here the application soft-are is to !e deployed.
Secure )our *etwor(& Host& and Application
"A vulnerability in a network will allow a malicious user to exploit a host or an application A vulnerability in a host
will allow a malicious user to exploit a network or an application A vulnerability in an application will allow a
malicious user to exploit a network or a host"
> Carlos !yons" Corporate Security" #icroso$t
.o !uild secure /e! applications, a holistic approach to application security is re0uired and security must !e
applied at all three layers. .his approach is sho-n in 3i+ure @.@.
Figure +,+
A holistic approach to security
Securing )our *etwor(
A secure /e! application relies upon a secure net-ork infrastructure. .he net-ork infrastructure consists of
routers, fire-alls, and s-itches. .he role of the secure net-ork is not only to protect itself from .CA)1!ased
attacks, !ut also to implement countermeasures such as secure administrati,e interfaces and stron+ pass-ords.
.he secure net-ork is also responsi!le for ensurin+ the inte+rity of the traffic that it is for-ardin+. )f you kno- at
the net-ork layer a!out ports, protocols, or communication that may !e harmful, counter those potential threats at
that layer.
*etwor( Component Categories
.his +uide di,ides net-ork security into separate component cate+ories as sho-n in .a!le @.@.
Table +,+: *etwor( Component Categories
Component escription
Router Routers are your outermost net-ork rin+. .hey channel packets to ports and protocols that
your application needs. Common .CA) ,ulnera!ilities are !locked at this rin+.
3ire-all .he fire-all !locks those protocols and ports that the application does not use. Additionally,
fire-alls enforce secure net-ork traffic !y pro,idin+ application1specific filterin+ to !lock
malicious communications.
S-itch S-itches are used to separate net-ork se+ments. .hey are fre0uently o,erlooked or
o,ertrusted.
Securing )our Host
/hen you secure a host, -hether it is your /e! ser,er, application ser,er, or data!ase ser,er, this +uide !reaks
do-n the ,arious secure confi+uration settin+s into separate cate+ories. /ith this approach, you can focus on a
specific cate+ory and re,ie- security, or apply security settin+s that relate to that specific cate+ory. /hen you
install ne- soft-are on your ser,ers -ith this approach, you can e,aluate the impact on your security settin+s. 3or
example, you may address the follo-in+ 0uestions" Does the soft-are create ne- accounts5 Does the soft-are add
any default ser,ices5 /ho are the ser,ices runnin+ as5 Are any ne- script mappin+s created5
Host Con$iguration Categories
3i+ure @.# sho-s the ,arious cate+ories used in art )V of this +uide, &Securin+ 6our 7et-ork, 2ost, and
Application.&
Figure +,-
Host security categories
/ith the frame-ork that these cate+ories pro,ide, you can systematically e,aluate or secure your ser,er9s
confi+uration instead of applyin+ security settin+s on an ad1hoc !asis. .he rationale for these particular cate+ories
is sho-n in .a!le @.#.
Table +,-: .ationale $or Host Con$iguration Categories
Category escription
atches and Bpdates Many top security risks exist !ecause of ,ulnera!ilities that are -idely pu!lished
and -ell kno-n. /hen ne- ,ulnera!ilities are disco,ered, exploit code is fre0uently
posted on )nternet !ulletin !oards -ithin hours of the first successful attack.
atchin+ and updatin+ your ser,er9s soft-are is the first step to-ard securin+ the
ser,er. )f you do not patch and update your ser,er, you are pro,idin+ more potential
opportunities for attackers and malicious code.
Ser,ices .he ser,ice set is determined !y the ser,er role and the applications it hosts. 4y
disa!lin+ unnecessary and unused ser,ices, you 0uickly and easily reduce the
attack surface area.
rotocols .o reduce the attack surface area and the a,enues open to attackers, disa!le any
unnecessary or unused net-ork protocols.
Accounts .he num!er of accounts accessi!le from a ser,er should !e restricted to the
necessary set of ser,ice and user accounts. Additionally, you should enforce
appropriate account policies, such as mandatin+ stron+ pass-ords.
3iles and Directories 3iles and directories should !e secured -ith restricted 7.3S permissions that allo-
access only to the necessary Microsoft /indo-s ser,ice and user accounts.
Shares All unnecessary file shares, includin+ the default administration shares if they are
not re0uired, should !e remo,ed. Secure the remainin+ shares -ith restricted 7.3S
permissions.
orts Ser,ices runnin+ on a ser,er listen on specific ports to ser,e incomin+ re0uests.
:pen ports on a ser,er must !e kno-n and audited re+ularly to make sure that an
insecure ser,ice is not listenin+ and a,aila!le for communication. )n the -orst1case
scenario, a listenin+ port is detected that -as not opened !y an administrator.
Auditin+ and *o++in+ Auditin+ is a ,ital aid in identifyin+ intruders or attacks in pro+ress. *o++in+ pro,es
particularly useful as forensic information -hen determinin+ ho- an intrusion or
attack -as performed.
Re+istry Many security related settin+s are maintained in the re+istry. Secure the re+istry
itself !y applyin+ restricted /indo-s AC*s and !lockin+ remote re+istry
administration.
Securing )our Application
)f you -ere to re,ie- and analy?e the top security issues across many /e! applications, you -ould see a pattern of
pro!lems. 4y or+ani?in+ these pro!lems into cate+ories, you can systematically tackle them. .hese pro!lem areas
are your application9s ,ulnera!ility cate+ories.
Application 'ulnerability Categories
/hat !etter -ay to measure the security of a system than to e,aluate its potential -eak points5 .o measure the
security resilience of your application, you can e,aluate the application ,ulnera!ility cate+ories. /hen you do this,
you can create application security profiles, and then use these profiles to determine the security stren+th of an
application.
.hese cate+ories are used as a frame-ork throu+hout this +uide. 4ecause the cate+ories represent the areas
-here security mistakes are most fre0uently made, they are used to illustrate +uidance for application de,elopers
and architects. .he cate+ories are also used as a frame-ork -hen e,aluatin+ the security of a /e! application.
/ith these cate+ories, you can focus consistently on the key desi+n and implementation choices that most affect
your application9s security. Application ,ulnera!ility cate+ories are descri!ed in .a!le @.%.
Table +,/: Application 'ulnerability Categories
Category escription
)nput Validation 2o- do you kno- that the input that your application recei,es is ,alid and safe5
)nput ,alidation refers to ho- your application filters, scru!s, or re8ects input
!efore additional processin+.
Authentication &/ho are you5& Authentication is the process -here an entity pro,es the identity
of another entity, typically throu+h credentials, such as a user name and
pass-ord.
Authori?ation &/hat can you do5& Authori?ation is ho- your application pro,ides access controls
for resources and operations.
Confi+uration Mana+ement /ho does your application run as5 /hich data!ases does it connect to5 2o- is
your application administered5 2o- are these settin+s secured5 Confi+uration
mana+ement refers to ho- your application handles these operational issues.
Sensiti,e Data Sensiti,e data refers to ho- your application handles any data that must !e
protected either in memory, o,er the -ire, or in persistent stores.
Session Mana+ement A session refers to a series of related interactions !et-een a user and your /e!
application. Session mana+ement refers to ho- your application handles and
protects these interactions.
Crypto+raphy 2o- are you keepin+ secrets, secret <confidentiality=5 2o- are you
tamperproofin+ your data or li!raries <inte+rity=5 2o- are you pro,idin+ seeds for
random ,alues that must !e crypto+raphically stron+5 Crypto+raphy refers to ho-
your application enforces confidentiality and inte+rity.
arameter Manipulation 3orm fields, 0uery strin+ ar+uments, and cookie ,alues are fre0uently used as
parameters for your application. arameter manipulation refers to !oth ho- your
application safe+uards tamperin+ of these ,alues and ho- your application
processes input parameters.
Exception Mana+ement /hen a method call in your application fails, -hat does your application do5 2o-
much do you re,eal5 Do you return friendly error information to end users5 Do
you pass ,alua!le exception information !ack to the caller5 Does your application
fail +racefully5
Auditin+ and *o++in+ /ho did -hat and -hen5 Auditin+ and lo++in+ refer to ho- your application
records security1related e,ents.
Security 0rinciples
Recommendations used throu+hout this +uide are !ased on security principles that ha,e pro,en themsel,es o,er
time. Security, like many aspects of soft-are en+ineerin+, lends itself to a principle1!ased approach, -here core
principles can !e applied re+ardless of implementation technolo+y or application scenario. .he ma8or security
principles used throu+hout this +uide are summari?ed in .a!le @.C.
Table +,1: Summary o$ Core Security 0rinciples
0rinciple Concepts
Compartmentali?e Reduce the surface area of attack. Ask yourself ho- you -ill contain a pro!lem. )f
an attacker takes o,er your application, -hat resources can he or she access5 Can
an attacker access net-ork resources5 2o- are you restrictin+ potential dama+e5
3ire-alls, least pri,ile+ed accounts, and least pri,ile+ed code are examples of
compartmentali?in+.
Bse least pri,ile+e 4y runnin+ processes usin+ accounts -ith minimal pri,ile+es and access ri+hts, you
si+nificantly reduce the capa!ilities of an attacker if the attacker mana+es to
compromise security and run code.
Apply defense in depth Bse multiple +atekeepers to keep attackers at !ay. Defense in depth means you do
not rely on a sin+le layer of security, or you consider that one of your layers may !e
!ypassed or compromised.
Do not trust user input 6our application9s user input is the attacker9s primary -eapon -hen tar+etin+ your
application. Assume all input is malicious until pro,en other-ise, and apply a
defense in depth strate+y to input ,alidation, takin+ particular precautions to make
sure that input is ,alidated -hene,er a trust !oundary in your application is
crossed.
Check at the +ate Authenticate and authori?e callers early > at the first +ate.
3ail securely )f an application fails, do not lea,e sensiti,e data accessi!le. Return friendly errors
to end users that do not expose internal system details. Do not include details that
may help an attacker exploit ,ulnera!ilities in your application.
Secure the -eakest link )s there a ,ulnera!ility at the net-ork layer that an attacker can exploit5 /hat
a!out the host5 )s your application secure5 Any -eak link in the chain is an
opportunity for !reached security.
Create secure defaults )s the default account set up -ith least pri,ile+e5 )s the default account disa!led !y
default and then explicitly ena!led -hen re0uired5 Does the confi+uration use a
pass-ord in plaintext5 /hen an error occurs, does sensiti,e information leak !ack
to the client to !e used potentially a+ainst the system5
Reduce your attack
surface
)f you do not use it, remo,e it or disa!le it. Reduce the surface area of attack !y
disa!lin+ or remo,in+ unused ser,ices, protocols, and functionality. Does your
ser,er need all those ser,ices and ports5 Does your application need all those
features5
Summary
An e,er1increasin+ num!er of attacks tar+et your application. .hey pass strai+ht throu+h your en,ironment9s front
door usin+ 2... .he con,entional fortress model and the reliance on fire-all and host defenses are not sufficient
-hen used in isolation. Securin+ your application in,ol,es applyin+ security at three layers" the net-ork layer, host
layer, and the application layer. A secure net-ork and host platform infrastructure is a must. Additionally, your
applications must !e desi+ned and !uilt usin+ secure desi+n and de,elopment +uidelines follo-in+ time-orn
security principles.
Additional .esources
3or more information, see the follo-in+ resources"

3or more information on the :pen 2ack /e! application, see the MSD7 article, &:pen 2ack" 4uildin+ and
Confi+urin+ More Secure /e! Sites,& at http"AAmsdn.microsoft.comAli!raryAen1
usAdnnetsecAhtmlAopenhack.asp.

.his is Volume )) in a series dedicated to helpin+ customers impro,e /e! application security. 3or more
information on desi+nin+ and implementin+ authentication, authori?ation, and secure communication
across the tiers of a distri!uted /e! application, see &Microsoft patterns % practices Volume ), &uilding
Secure AS'()T Applications: Authentication" Authori*ation" and Secure Communication& at
http"AAmsdn.microsoft.comAli!raryAen1usAdnnetsecAhtmlAsecnetlpMSD7.asp.
Chapter 2 Threats and Countermeasures
http://www.microsoft.com/practices http://www.microsoft.
com/practices
Improving Web Application Security: Threats and Countermeasures
J.D. Meier, Alex Macman, Michael Dunner, !rinath "asiredd#, $a# %scamilla and Anandha
Muruan
Microsoft Corporation
&u'lished: June 2(()
*ast $e+ised: Januar# 2((,
!ee the -patterns . practices !ecurit# /uidance for Applications 0ndex- for lins to additional
securit# resources.
!ee the *andin1 &a1e for the startin1 point and a complete o+er+iew of Improving Web
Application Security: Threats and Countermeasures.
Summary: This chapter identifies and explains the set of top networ, host and application la#er
threats and descri'es the countermeasures that are appropriate to address each threat. 0t also
explains common attacer methodolo1# and a series of common attacs. This chapter will help
#ou 'e1in to understand and cate1ori2e threats in preparation for performin1 threat modelin1.
Contents
0n This Chapter
3+er+iew
4ow to 5se This Chapter
Anatom# of an Attac
5nderstandin1 Threat Cate1ories
6etwor Threats and Countermeasures
4ost Threats and Countermeasures
Application Threats and Countermeasures
0nput "alidation
Authentication
Authori2ation
Confi1uration Mana1ement
!ensiti+e Data
!ession Mana1ement
Cr#pto1raph#
&arameter Manipulation
%xception Mana1ement
Auditin1 and *o11in1
!ummar#
Additional $esources
In This Chapter
An explanation of attacer methodolo1#
Descriptions of common attacs
4ow to cate1ori2e threats
4ow to identif# and counter threats at the networ, host, and application le+els
Overview
7hen #ou incorporate securit# features into #our application8s desi1n, implementation, and
deplo#ment, it helps to ha+e a 1ood understandin1 of how attacers thin. 9# thinin1 lie
attacers and 'ein1 aware of their liel# tactics, #ou can 'e more effecti+e when appl#in1
countermeasures. This chapter descri'es the classic attacer methodolo1# and profiles the
anatom# of a t#pical attac.
This chapter anal#2es 7e' application securit# from the perspecti+es of threats,
countermeasures, +ulnera'ilities, and attacs. The followin1 set of core terms are defined to
a+oid confusion and to ensure the# are used in the correct context.
Asset. A resource of +alue such as the data in a data'ase or on the file s#stem, or a s#stem
resource
Threat. A potential occurrence : malicious or otherwise : that ma# harm an asset
Vulnerability. A weaness that maes a threat possi'le
Attack or e!ploit". An action taen to harm an asset
Countermeasure. A safe1uard that addresses a threat and miti1ates ris
This chapter also identifies a set of common networ, host, and application le+el threats, and the
recommended countermeasures to address each one. The chapter does not contain an exhausti+e
list of threats, 'ut it does hi1hli1ht man# top threats. 7ith this information and nowled1e of
how an attacer wors, #ou will 'e a'le to identif# additional threats. ;ou need to now the
threats that are most liel# to impact #our s#stem to 'e a'le to 'uild effecti+e threat models.
These threat models are the su'<ect of Chapter ), -Threat Modelin1.-
#ow to $se This Chapter
The followin1 are recommendations on how to use this chapter:
%ecome &amiliar with speci&ic threats that a&&ect the network host and application. The
threats are uni=ue for the +arious parts of #our s#stem, althou1h the attacer8s 1oals ma#
'e the same.
$se the threats to identi&y risk. Then create a plan to counter those threats.
Apply countermeasures to address vulnerabilities. Countermeasures are summari2ed in
this chapter. 5se &art 000, -9uildin1 !ecure 7e' Applications,- and &art 0", -!ecurin1
;our 6etwor, 4ost, and Application,- of this 1uide for countermeasure implementation
details.
When you design' build' and secure new systems' keep the threats in this chapter in
mind. The threats exist re1ardless of the platform or technolo1ies that #ou use.
Anatomy o& an Attack
9# understandin1 the 'asic approach used '# attacers to tar1et #our 7e' application, #ou will
'e 'etter e=uipped to tae defensi+e measures 'ecause #ou will now what #ou are up a1ainst.
The 'asic steps in attacer methodolo1# are summari2ed 'elow and illustrated in >i1ure 2.?:
Survey and assess
(!ploit and penetrate
(scalate privileges
)aintain access
*eny service

+igure ,-.
Basic steps for attacking methodology
Survey and Assess
!ur+e#in1 and assessin1 the potential tar1et are done in tandem. The first step an attacer usuall#
taes is to sur+e# the potential tar1et to identif# and assess its characteristics. These
characteristics ma# include its supported ser+ices and protocols to1ether with potential
+ulnera'ilities and entr# points. The attacer uses the information 1athered in the sur+e# and
assess phase to plan an initial attac.
>or example, an attacer can detect a cross@site scriptin1 AB!!C +ulnera'ilit# '# testin1 to see if
an# controls in a 7e' pa1e echo 'ac output.
(!ploit and /enetrate
4a+in1 sur+e#ed a potential tar1et, the next step is to exploit and penetrate. 0f the networ and
host are full# secured, #our application Athe front 1ateC 'ecomes the next channel for attac.
>or an attacer, the easiest wa# into an application is throu1h the same entrance that le1itimate
users use : for example, throu1h the application8s lo1on pa1e or a pa1e that does not re=uire
authentication.
(scalate /rivileges
After attacers mana1e to compromise an application or networ, perhaps '# in<ectin1 code into
an application or creatin1 an authenticated session with the MicrosoftD 7indowsD 2(((
operatin1 s#stem, the# immediatel# attempt to escalate pri+ile1es. !pecificall#, the# loo for
administration pri+ile1es pro+ided '# accounts that are mem'ers of the Administrators 1roup.
The# also see out the hi1h le+el of pri+ile1es offered '# the local s#stem account.
5sin1 least pri+ile1ed ser+ice accounts throu1hout #our application is a primar# defense a1ainst
pri+ile1e escalation attacs. Also, man# networ le+el pri+ile1e escalation attacs re=uire an
interacti+e lo1on session.
)aintain Access
4a+in1 1ained access to a s#stem, an attacer taes steps to mae future access easier and to
co+er his or her tracs. Common approaches for main1 future access easier include plantin1
'ac@door pro1rams or usin1 an existin1 account that lacs stron1 protection. Co+erin1 tracs
t#picall# in+ol+es clearin1 lo1s and hidin1 tools. As such, audit lo1s are a primar# tar1et for the
attacer.
*o1 files should 'e secured, and the# should 'e anal#2ed on a re1ular 'asis. *o1 file anal#sis can
often unco+er the earl# si1ns of an attempted 'rea@in 'efore dama1e is done.
*eny Service
Attacers who cannot 1ain access often mount a denial of ser+ice attac to pre+ent others from
usin1 the application. >or other attacers, the denial of ser+ice option is their 1oal from the
outset. An example is the !;6 flood attac, where the attacer uses a pro1ram to send a flood of
TC& !;6 re=uests to fill the pendin1 connection =ueue on the ser+er. This pre+ents other users
from esta'lishin1 networ connections.
$nderstanding Threat Categories
7hile there are man# +ariations of specific attacs and attac techni=ues, it is useful to thin
a'out threats in terms of what the attacer is tr#in1 to achie+e. This chan1es #our focus from the
identification of e+er# specific attac : which is reall# <ust a means to an end : to focusin1 on
the end results of possi'le attacs.
ST0I*(
Threats faced '# the application can 'e cate1ori2ed 'ased on the 1oals and purposes of the
attacs. A worin1 nowled1e of these cate1ories of threats can help #ou or1ani2e a securit#
strate1# so that #ou ha+e planned responses to threats. !T$0D% is the acron#m used at Microsoft
to cate1ori2e different threat t#pes. !T$0D% stands for:
Spoo&ing. Spoofing is attemptin1 to 1ain access to a s#stem '# usin1 a false identit#. This can
'e accomplished usin1 stolen user credentials or a false 0& address. After the attacer
successfull# 1ains access as a le1itimate user or host, ele+ation of pri+ile1es or a'use
usin1 authori2ation can 'e1in.
Tampering. Tampering is the unauthori2ed modification of data, for example as it flows o+er
a networ 'etween two computers.
0epudiation. Repudiation is the a'ilit# of users Ale1itimate or otherwiseC to den# that the#
performed specific actions or transactions. 7ithout ade=uate auditin1, repudiation attacs
are difficult to pro+e.
In&ormation disclosure. Information disclosure is the unwanted exposure of pri+ate data.
>or example, a user +iews the contents of a ta'le or file he or she is not authori2ed to
open, or monitors data passed in plaintext o+er a networ. !ome examples of information
disclosure +ulnera'ilities include the use of hidden form fields, comments em'edded in
7e' pa1es that contain data'ase connection strin1s and connection details, and wea
exception handlin1 that can lead to internal s#stem le+el details 'ein1 re+ealed to the
client. An# of this information can 'e +er# useful to the attacer.
*enial o& service. Denial of service is the process of main1 a s#stem or application
una+aila'le. >or example, a denial of ser+ice attac mi1ht 'e accomplished '#
'om'ardin1 a ser+er with re=uests to consume all a+aila'le s#stem resources or '#
passin1 it malformed input data that can crash an application process.
(levation o& privilege. Elevation of privilege occurs when a user with limited pri+ile1es
assumes the identit# of a pri+ile1ed user to 1ain pri+ile1ed access to an application. >or
example, an attacer with limited pri+ile1es mi1ht ele+ate his or her pri+ile1e le+el to
compromise and tae control of a hi1hl# pri+ile1ed and trusted process or account.
ST0I*( Threats and Countermeasures
%ach threat cate1or# descri'ed '# !T$0D% has a correspondin1 set of countermeasure
techni=ues that should 'e used to reduce ris. These are summari2ed in Ta'le 2.?. The
appropriate countermeasure depends upon the specific attac. More threats, attacs, and
countermeasures that appl# at the networ, host, and application le+els are presented later in this
chapter.
Table ,-. ST0I*( Threats and Countermeasures
Threat Countermeasures
!poofin1 user identit#
5se stron1 authentication.
Do not store secrets Afor example, passwordsC in plaintext.
Do not pass credentials in plaintext o+er the wire.
&rotect authentication cooies with !ecure !ocets *a#er A!!*C.
Tamperin1 with data
5se data hashin1 and si1nin1.
5se di1ital si1natures.
5se stron1 authori2ation.
5se tamper@resistant protocols across communication lins.
!ecure communication lins with protocols that pro+ide messa1e
inte1rit#.
$epudiation
Create secure audit trails.
5se di1ital si1natures.
0nformation disclosure
5se stron1 authori2ation.
5se stron1 encr#ption.
!ecure communication lins with protocols that pro+ide messa1e
confidentialit#.
Do not store secrets Afor example, passwordsC in plaintext.
Denial of ser+ice 5se resource and 'andwidth throttlin1 techni=ues.
"alidate and filter input.
%le+ation of pri+ile1e
>ollow the principle of least pri+ile1e and use least pri+ile1ed
ser+ice accounts to run processes and access resources.
1etwork Threats and Countermeasures
The primar# components that mae up #our networ infrastructure are routers, firewalls, and
switches. The# act as the 1ateeepers 1uardin1 #our ser+ers and applications from attacs and
intrusions. An attacer ma# exploit poorl# confi1ured networ de+ices. Common +ulnera'ilities
include wea default installation settin1s, wide open access controls, and de+ices lacin1 the
latest securit# patches. Top networ le+el threats include:
In&ormation gathering
Sni&&ing
Spoo&ing
Session hi2acking
*enial o& service
In&ormation 3athering
6etwor de+ices can 'e disco+ered and profiled in much the same wa# as other t#pes of s#stems.
Attacers usuall# start with port scannin1. After the# identif# open ports, the# use 'anner
1ra''in1 and enumeration to detect de+ice t#pes and to determine operatin1 s#stem and
application +ersions. Armed with this information, an attacer can attac nown +ulnera'ilities
that ma# not 'e updated with securit# patches.
Countermeasures to pre+ent information 1atherin1 include:
Confi1ure routers to restrict their responses to footprintin1 re=uests.
Confi1ure operatin1 s#stems that host networ software Afor example, software firewallsC to
pre+ent footprintin1 '# disa'lin1 unused protocols and unnecessar# ports.
Sni&&ing
Sniffing or eavesdropping is the act of monitorin1 traffic on the networ for data such as
plaintext passwords or confi1uration information. 7ith a simple pacet sniffer, an attacer can
easil# read all plaintext traffic. Also, attacers can crac pacets encr#pted '# li1htwei1ht
hashin1 al1orithms and can decipher the pa#load that #ou considered to 'e safe. The sniffin1 of
pacets re=uires a pacet sniffer in the path of the ser+er/client communication.
Countermeasures to help pre+ent sniffin1 include:
5se stron1 ph#sical securit# and proper se1mentin1 of the networ. This is the first step in
pre+entin1 traffic from 'ein1 collected locall#.
%ncr#pt communication full#, includin1 authentication credentials. This pre+ents sniffed
pacets from 'ein1 usa'le to an attacer. !!* and 0&!ec A0nternet &rotocol !ecurit#C are
examples of encr#ption solutions.
Spoo&ing
!poofin1 is a means to hide one8s true identit# on the networ. To create a spoofed identit#, an
attacer uses a fae source address that does not represent the actual address of the pacet.
!poofin1 ma# 'e used to hide the ori1inal source of an attac or to wor around networ access
control lists AAC*sC that are in place to limit host access 'ased on source address rules.
Althou1h carefull# crafted spoofed pacets ma# ne+er 'e traced to the ori1inal sender, a
com'ination of filterin1 rules pre+ents spoofed pacets from ori1inatin1 from #our networ,
allowin1 #ou to 'loc o'+iousl# spoofed pacets.
Countermeasures to pre+ent spoofin1 include:
>ilter incomin1 pacets that appear to come from an internal 0& address at #our perimeter.
>ilter out1oin1 pacets that appear to ori1inate from an in+alid local 0& address.
Session #i2acking
Also nown as man in the middle attacs, session hi<acin1 decei+es a ser+er or a client into
acceptin1 the upstream host as the actual le1itimate host. 0nstead the upstream host is an
attacer8s host that is manipulatin1 the networ so the attacer8s host appears to 'e the desired
destination.
Countermeasures to help pre+ent session hi<acin1 include:
5se encr#pted session ne1otiation.
5se encr#pted communication channels.
!ta# informed of platform patches to fix TC&/0& +ulnera'ilities, such as predicta'le pacet
se=uences.
*enial o& Service
Denial of ser+ice denies le1itimate users access to a ser+er or ser+ices. The !;6 flood attac is a
common example of a networ le+el denial of ser+ice attac. 0t is eas# to launch and difficult to
trac. The aim of the attac is to send more re=uests to a ser+er than it can handle. The attac
exploits a potential +ulnera'ilit# in the TC&/0& connection esta'lishment mechanism and floods
the ser+er8s pendin1 connection =ueue.
Countermeasures to pre+ent denial of ser+ice include:
Appl# the latest ser+ice pacs.
4arden the TC&/0& stac '# appl#in1 the appropriate re1istr# settin1s to increase the si2e of
the TC& connection =ueue, decrease the connection esta'lishment period, and emplo#
d#namic 'aclo1 mechanisms to ensure that the connection =ueue is ne+er exhausted.
5se a networ 0ntrusion Detection !#stem A0D!C 'ecause these can automaticall# detect and
respond to !;6 attacs.
#ost Threats and Countermeasures
4ost threats are directed at the s#stem software upon which #our applications are 'uilt. This
includes 7indows 2(((, Microsoft 7indows !er+er 2((), 0nternet 0nformation !er+ices A00!C,
the .6%T >ramewor, and !E* !er+er dependin1 upon the specific ser+er role. Top host le+el
threats include:
Viruses' Tro2an horses' and worms
+ootprinting
/ro&iling
/assword cracking
*enial o& service
Arbitrary code e!ecution
$nauthori4ed access
Viruses' Tro2an #orses' and Worms
A +irus is a pro1ram that is desi1ned to perform malicious acts and cause disruption to #our
operatin1 s#stem or applications. A Tro<an horse resem'les a +irus except that the malicious code
is contained inside what appears to 'e a harmless data file or executa'le pro1ram. A worm is
similar to a Tro<an horse except that it self@replicates from one ser+er to another. 7orms are
difficult to detect 'ecause the# do not re1ularl# create files that can 'e seen. The# are often
noticed onl# when the# 'e1in to consume s#stem resources 'ecause the s#stem slows down or
the execution of other pro1rams halt. The Code $ed 7orm is one of the most notorious to afflict
00!F it relied upon a 'uffer o+erflow +ulnera'ilit# in a particular 0!A&0 filter.
Althou1h these three threats are actuall# attacs, to1ether the# pose a si1nificant threat to 7e'
applications, the hosts these applications li+e on, and the networ used to deli+er these
applications. The success of these attacs on an# s#stem is possi'le throu1h man# +ulnera'ilities
such as wea defaults, software 'u1s, user error, and inherent +ulnera'ilities in 0nternet
protocols.
Countermeasures that #ou can use a1ainst +iruses, Tro<an horses, and worms include:
!ta# current with the latest operatin1 s#stem ser+ice pacs and software patches.
9loc all unnecessar# ports at the firewall and host.
Disa'le unused functionalit# includin1 protocols and ser+ices.
4arden wea, default confi1uration settin1s.
+ootprinting
%xamples of footprintin1 are port scans, pin1 sweeps, and 6et903! enumeration that can 'e
used '# attacers to 1lean +alua'le s#stem@le+el information to help prepare for more si1nificant
attacs. The t#pe of information potentiall# re+ealed '# footprintin1 includes account details,
operatin1 s#stem and other software +ersions, ser+er names, and data'ase schema details.
Countermeasures to help pre+ent footprintin1 include:
Disa'le unnecessar# protocols.
*oc down ports with the appropriate firewall confi1uration.
5se TC&/0& and 0&!ec filters for defense in depth.
Confi1ure 00! to pre+ent information disclosure throu1h 'anner 1ra''in1.
5se an 0D! that can 'e confi1ured to pic up footprintin1 patterns and re<ect suspicious
traffic.
/assword Cracking
0f the attacer cannot esta'lish an anon#mous connection with the ser+er, he or she will tr# to
esta'lish an authenticated connection. >or this, the attacer must now a +alid username and
password com'ination. 0f #ou use default account names, #ou are 1i+in1 the attacer a head start.
Then the attacer onl# has to crac the account8s password. The use of 'lan or wea passwords
maes the attacer8s <o' e+en easier.
Countermeasures to help pre+ent password cracin1 include:
5se stron1 passwords for all account t#pes.
Appl# locout policies to end@user accounts to limit the num'er of retr# attempts that can 'e
used to 1uess the password.
Do not use default account names, and rename standard accounts such as the administrator8s
account and the anon#mous 0nternet user account used '# man# 7e' applications.
Audit failed lo1ins for patterns of password hacin1 attempts.
*enial o& Service
Denial of ser+ice can 'e attained '# man# methods aimed at se+eral tar1ets within #our
infrastructure. At the host, an attacer can disrupt ser+ice '# 'rute force a1ainst #our application,
or an attacer ma# now of a +ulnera'ilit# that exists in the ser+ice #our application is hosted in
or in the operatin1 s#stem that runs #our ser+er.
Countermeasures to help pre+ent denial of ser+ice include:
Confi1ure #our applications, ser+ices, and operatin1 s#stem with denial of ser+ice in mind.
!ta# current with patches and securit# updates.
4arden the TC&/0& stac a1ainst denial of ser+ice.
Mae sure #our account locout policies cannot 'e exploited to loc out well nown ser+ice
accounts.
Mae sure #our application is capa'le of handlin1 hi1h +olumes of traffic and that thresholds
are in place to handle a'normall# hi1h loads.
$e+iew #our application8s failo+er functionalit#.
5se an 0D! that can detect potential denial of ser+ice attacs.
Arbitrary Code (!ecution
0f an attacer can execute malicious code on #our ser+er, the attacer can either compromise
ser+er resources or mount further attacs a1ainst downstream s#stems. The riss posed '#
ar'itrar# code execution increase if the ser+er process under which the attacer8s code runs is
o+er@pri+ile1ed. Common +ulnera'ilities include wea 00! confi1uration and unpatched ser+ers
that allow path tra+ersal and 'uffer o+erflow attacs, 'oth of which can lead to ar'itrar# code
execution.
Countermeasures to help pre+ent ar'itrar# code execution include:
Confi1ure 00! to re<ect 5$*s with -../- to pre+ent path tra+ersal.
*oc down s#stem commands and utilities with restricted AC*s.
!ta# current with patches and updates to ensure that newl# disco+ered 'uffer o+erflows are
speedil# patched.
$nauthori4ed Access
0nade=uate access controls could allow an unauthori2ed user to access restricted information or
perform restricted operations. Common +ulnera'ilities include wea 00! 7e' access controls,
includin1 7e' permissions and wea 6T>! permissions.
Countermeasures to help pre+ent unauthori2ed access include:
Confi1ure secure 7e' permissions.
*oc down files and folders with restricted 6T>! permissions.
5se .6%T >ramewor access control mechanisms within #our A!&.6%T applications,
includin1 5$* authori2ation and principal permission demands.
Application Threats and Countermeasures
A 1ood wa# to anal#2e application@le+el threats is to or1ani2e them '# application +ulnera'ilit#
cate1or#. The +arious cate1ories used in the su'se=uent sections of this chapter and throu1hout
the 1uide, to1ether with the main threats to #our application, are summari2ed in Ta'le 2.2.
Table ,-, Threats by Application Vulnerability Category
Category Threats
0nput +alidation
9uffer o+erflowF cross@site scriptin1F !E* in<ectionF
canonicali2ation
Authentication
6etwor ea+esdroppin1F 'rute force attacsF
dictionar# attacsF cooie repla#F credential theft
Authori2ation
%le+ation of pri+ile1eF disclosure of confidential dataF data
tamperin1F lurin1 attacs
Confi1uration mana1ement
5nauthori2ed access to administration interfacesF unauthori2ed
access to confi1uration storesF retrie+al of clear text
confi1uration dataF lac of indi+idual accounta'ilit#F o+er@
pri+ile1ed process and ser+ice accounts
!ensiti+e data
Access sensiti+e data in stora1eF networ ea+esdroppin1F data
tamperin1
!ession mana1ement !ession hi<acin1F session repla#F man in the middle
Cr#pto1raph#
&oor e# 1eneration or e# mana1ementF wea or custom
encr#ption
&arameter manipulation
Euer# strin1 manipulationF form field manipulationF cooie
manipulationF 4TT& header manipulation
%xception mana1ement 0nformation disclosureF denial of ser+ice
Auditin1 and lo11in1
5ser denies performin1 an operationF attacer exploits an
application without traceF attacer co+ers his or her tracs
Input Validation
0nput +alidation is a securit# issue if an attacer disco+ers that #our application maes unfounded
assumptions a'out the t#pe, len1th, format, or ran1e of input data. The attacer can then suppl#
carefull# crafted input that compromises #our application.
7hen networ and host le+el entr# points are full# securedF the pu'lic interfaces exposed '#
#our application 'ecome the onl# source of attac. The input to #our application is a means to
'oth test #our s#stem and a wa# to execute code on an attacer8s 'ehalf. Does #our application
'lindl# trust inputG 0f it does, #our application ma# 'e suscepti'le to the followin1:
9uffer o+erflows
Cross@site scriptin1
!E* in<ection
Canonicali2ation
The followin1 section examines these +ulnera'ilities in detail, includin1 what maes these
+ulnera'ilities possi'le.
%u&&er Over&lows
9uffer o+erflow +ulnera'ilities can lead to denial of ser+ice attacs or code in<ection. A denial of
ser+ice attac causes a process crashF code in<ection alters the pro1ram execution address to run
an attacer8s in<ected code. The followin1 code fra1ment illustrates a common example of 'uffer
o+erflow +ulnera'ilit#.
<a+ascript:Cop#CodeA8ctl((Hrs?HmainContentContainerHctl(I8CF Cop# Code
void SomeFunction( char *pszInput )
{
char szBuffer[10];
Input is copied strai!ht into the "uffer #hen no t$pe chec%in! is
performed
strcp$(szBuffer& pszInput);
' ' '
(
Mana1ed .6%T code is not suscepti'le to this pro'lem 'ecause arra# 'ounds are automaticall#
checed whene+er an arra# is accessed. This maes the threat of 'uffer o+erflow attacs on
mana1ed code much less of an issue. 0t is still a concern, howe+er, especiall# where mana1ed
code calls unmana1ed A&0s or C3M o'<ects.
Countermeasures to help pre+ent 'uffer o+erflows include:
&erform thorou1h input +alidation. This is the first line of defense a1ainst 'uffer o+erflows.
Althou1h a 'u1 ma# exist in #our application that permits expected input to reach 'e#ond
the 'ounds of a container, unexpected input will 'e the primar# cause of this
+ulnera'ilit#. Constrain input '# +alidatin1 it for t#pe, len1th, format and ran1e.
7hen possi'le, limit #our application8s use of unmana1ed code, and thorou1hl# inspect the
unmana1ed A&0s to ensure that input is properl# +alidated.
0nspect the mana1ed code that calls the unmana1ed A&0 to ensure that onl# appropriate
+alues can 'e passed as parameters to the unmana1ed A&0.
5se the //! fla1 to compile code de+eloped with the Microsoft "isual CJJD de+elopment
s#stem. The //! fla1 causes the compiler to in<ect securit# checs into the compiled
code. This is not a fail@proof solution or a replacement for #our specific +alidation codeF
it does, howe+er, protect #our code from commonl# nown 'uffer o+erflow attacs. >or
more information, see the .6%T >ramewor &roduct documentation
http://msdn.microsoft.com/li'rar#/en@us/+ccore/html/+clrf/!9uffer!ecurit#.asp and
Microsoft Knowled1e 9ase article )2LIM) -7e'Cast: Compiler !ecurit# Checs: The
/! compiler switch.-
(!ample o& Code In2ection Through %u&&er Over&lows
An attacer can exploit a 'uffer o+erflow +ulnera'ilit# to in<ect code. 7ith this attac, a
malicious user exploits an uncheced 'uffer in a process '# suppl#in1 a carefull# constructed
input +alue that o+erwrites the pro1ram8s stac and alters a function8s return address. This causes
execution to <ump to the attacer8s in<ected code.
The attacer8s code usuall# ends up runnin1 under the process securit# context. This emphasi2es
the importance of usin1 least pri+ile1ed process accounts. 0f the current thread is impersonatin1,
the attacer8s code ends up runnin1 under the securit# context defined '# the thread
impersonation toen. The first thin1 an attacer usuall# does is call the 0evertToSel& A&0 to
re+ert to the process le+el securit# context that the attacer hopes has hi1her pri+ile1es.
Mae sure #ou +alidate input for t#pe and len1th, especiall# 'efore #ou call unmana1ed code
'ecause unmana1ed code is particularl# suscepti'le to 'uffer o+erflows.
Cross5Site Scripting
An B!! attac can cause ar'itrar# code to run in a user8s 'rowser while the 'rowser is connected
to a trusted 7e' site. The attac tar1ets #our application8s users and not the application itself, 'ut
it uses #our application as the +ehicle for the attac.
9ecause the script code is downloaded '# the 'rowser from a trusted site, the 'rowser has no
wa# of nowin1 that the code is not le1itimate. 0nternet %xplorer securit# 2ones pro+ide no
defense. !ince the attacer8s code has access to the cooies associated with the trusted site and
are stored on the user8s local computer, a user8s authentication cooies are t#picall# the tar1et of
attac.
(!ample o& Cross5Site Scripting
To initiate the attac, the attacer must con+ince the user to clic on a carefull# crafted
h#perlin, for example, '# em'eddin1 a lin in an email sent to the user or '# addin1 a malicious
lin to a news1roup postin1. The lin points to a +ulnera'le pa1e in #our application that echoes
the un+alidated input 'ac to the 'rowser in the 4TM* output stream. >or example, consider the
followin1 two lins.
4ere is a le1itimate lin:
<a+ascript:Cop#CodeA8ctl((Hrs?HmainContentContainerHctl(,8CF Cop# Code
###'$our#e"app)ication'com)o!on'asp*+username,"o"
4ere is a malicious lin:
<a+ascript:Cop#CodeA8ctl((Hrs?HmainContentContainerHctl(N8CF Cop# Code
###'$our#e"app)ication'com)o!on'asp*+username,-script.a)ert(/hac%er
code/)-script.
0f the 7e' application taes the =uer# strin1, fails to properl# +alidate it, and then returns it to
the 'rowser, the script code executes in the 'rowser. The precedin1 example displa#s a harmless
pop@up messa1e. 7ith the appropriate script, the attacer can easil# extract the user8s
authentication cooie, post it to his site, and su'se=uentl# mae a re=uest to the tar1et 7e' site
as the authenticated user.
Countermeasures to pre+ent B!! include:
&erform thorou1h input +alidation. ;our applications must ensure that input from =uer#
strin1s, form fields, and cooies are +alid for the application. Consider all user input as
possi'l# malicious, and filter or saniti2e for the context of the downstream code. "alidate
all input for nown +alid +alues and then re<ect all other input. 5se re1ular expressions to
+alidate input data recei+ed +ia 4TM* form fields, cooies, and =uer# strin1s.
5se #T)6(ncode and $06(ncode functions to encode an# output that includes user
input. This con+erts executa'le script into harmless 4TM*.
S76 In2ection
A !E* in<ection attac exploits +ulnera'ilities in input +alidation to run ar'itrar# commands in
the data'ase. 0t can occur when #our application uses input to construct d#namic !E* statements
to access the data'ase. 0t can also occur if #our code uses stored procedures that are passed
strin1s that contain unfiltered user input. 5sin1 the !E* in<ection attac, the attacer can execute
ar'itrar# commands in the data'ase. The issue is ma1nified if the application uses an o+er@
pri+ile1ed account to connect to the data'ase. 0n this instance it is possi'le to use the data'ase
ser+er to run operatin1 s#stem commands and potentiall# compromise other ser+ers, in addition
to 'ein1 a'le to retrie+e, manipulate, and destro# data.
(!ample o& S76 In2ection
;our application ma# 'e suscepti'le to !E* in<ection attacs when #ou incorporate un+alidated
user input into data'ase =ueries. &articularl# suscepti'le is code that constructs d#namic !E*
statements with unfiltered user input. Consider the followin1 code:
<a+ascript:Cop#CodeA8ctl((Hrs?HmainContentContainerHctl(M8CF Cop# Code
S0)1ata2dapter m$3ommand , ne# S0)1ata2dapter(
4S56537 * F89: ;sers
<=585 ;ser>ame ,/4 ? t*tuid'7e*t ? 4/4& conn);
Attacers can in<ect !E* '# terminatin1 the intended !E* statement with the sin1le =uote
character followed '# a semicolon character to 'e1in a new command, and then executin1 the
command of their choice. Consider the followin1 character strin1 entered into the t!tuid field.
<a+ascript:Cop#CodeA8ctl((Hrs?HmainCont
entContainerHctl(O8CF Cop# Code
/; 189@ 72B65 3ustomers A
This results in the followin1 statement 'ein1 su'mitted to the data'ase for execution.
<a+ascript:Cop#CodeA8ctl((Hrs?HmainContentContainerHctl?(8CF Cop# Code
S56537 * F89: ;sers <=585 ;ser>ame,//; 189@ 72B65 3ustomers AA/
This deletes the Customers ta'le, assumin1 that the application8s lo1in has sufficient permissions
in the data'ase Aanother reason to use a least pri+ile1ed lo1in in the data'aseC. The dou'le dash
A@@C denotes a !E* comment and is used to comment out an# other characters added '# the
pro1rammer, such as the trailin1 =uote.
6ote The semicolon is not actuall# re=uired. !E* !er+er will execute two commands
separated '# spaces.
3ther more su'tle trics can 'e performed. !uppl#in1 this input to the t!tuid field:
<a+ascript:Cop#C
odeA8ctl((Hrs?Hm
ainContentContai
nerHctl??8CF Cop#
Code
/ 98 1,1 A
'uilds this command:
<a+ascript:Cop#CodeA8ctl((Hrs?HmainContentContainerHctl?28CF Cop# Code
S56537 * F89: ;sers <=585 ;ser>ame,// 98 1,1 A
9ecause ?P? is alwa#s true, the attacer retrie+es e+er# row of data from the 5sers ta'le.
Countermeasures to pre+ent !E* in<ection include:
&erform thorou1h input +alidation. ;our application should +alidate its input prior to sendin1
a re=uest to the data'ase.
5se parameteri2ed stored procedures for data'ase access to ensure that input strin1s are not
treated as executa'le statements. 0f #ou cannot use stored procedures, use !E*
parameters when #ou 'uild !E* commands.
5se least pri+ile1ed accounts to connect to the data'ase.
Canonicali4ation
Different forms of input that resol+e to the same standard name Athe canonical nameC, is referred
to as canonicaliation. Code is particularl# suscepti'le to canonicali2ation issues if it maes
securit# decisions 'ased on the name of a resource that is passed to the pro1ram as input. >iles,
paths, and 5$*s are resource t#pes that are +ulnera'le to canonicali2ation 'ecause in each case
there are man# different wa#s to represent the same name. >ile names are also pro'lematic. >or
example, a sin1le file could 'e represented as:
<a+ascript:Cop#CodeA8ctl((Hrs?HmainContentCont
ainerHctl?)8CF Cop# Code
cBCtempCsomefi)e'dat
somefi)e'dat
cBCtempCsu"dirC''Csomefi)e'dat
cBC tempC somefi)e'dat
''Csomefi)e'dat
0deall#, #our code should not accept input file names. 0f it does, the name should 'e con+erted to
its canonical form prior to main1 securit# decisions, such as whether access should 'e 1ranted
or denied to the specified file.
Countermeasures to address canonicali2ation issues include:
A+oid usin1 file names as input where possi'le and instead use a'solute file paths that cannot
'e chan1ed '# the end user.
Mae sure that file names are well formed Aif #ou must accept file names as inputC and
+alidate them within the context of #our application. >or example, chec that the# are
within #our application8s director# hierarch#.
%nsure that the character encodin1 is set correctl# to limit how input can 'e represented.
Chec that #our application8s 7e'.confi1 has set the re8uest(ncoding and
response(ncoding attri'utes on the 9globali4ation: element.
Authentication
Dependin1 on #our re=uirements, there are se+eral a+aila'le authentication mechanisms to
choose from. 0f the# are not correctl# chosen and implemented, the authentication mechanism
can expose +ulnera'ilities that attacers can exploit to 1ain access to #our s#stem. The top
threats that exploit authentication +ulnera'ilities include:
1etwork eavesdropping
%rute &orce attacks
*ictionary attacks
Cookie replay attacks
Credential the&t
1etwork (avesdropping
0f authentication credentials are passed in plaintext from client to ser+er, an attacer armed with
rudimentar# networ monitorin1 software on a host on the same networ can capture traffic and
o'tain user names and passwords.
Countermeasures to pre+ent networ ea+esdroppin1 include:
5se authentication mechanisms that do not transmit the password o+er the networ such as
Ker'eros protocol or 7indows authentication.
Mae sure passwords are encr#pted Aif #ou must transmit passwords o+er the networC or use
an encr#pted communication channel, for example with !!*.
%rute +orce Attacks
9rute force attacs rel# on computational power to crac hashed passwords or other secrets
secured with hashin1 and encr#ption. To miti1ate the ris, use stron1 passwords. Additionall#,
use hashed passwords with saltF this slows down the attacer considera'l# and allows sufficient
time for countermeasures to 'e acti+ated.
*ictionary Attacks
This attac is used to o'tain passwords. Most password s#stems do not store plaintext passwords
or encr#pted passwords. The# a+oid encr#pted passwords 'ecause a compromised e# leads to
the compromise of all passwords in the data store. *ost e#s mean that all passwords are
in+alidated.
Most user store implementations hold password hashes Aor di1estsC. 5sers are authenticated '#
re@computin1 the hash 'ased on the user@supplied password +alue and comparin1 it a1ainst the
hash +alue stored in the data'ase. 0f an attacer mana1es to o'tain the list of hashed passwords, a
'rute force attac can 'e used to crac the password hashes.
7ith the dictionar# attac, an attacer uses a pro1ram to iterate throu1h all of the words in a
dictionar# Aor multiple dictionaries in different lan1ua1esC and computes the hash for each word.
The resultant hash is compared with the +alue in the data store. 7ea passwords such as
-;anees- Aa fa+orite teamC or -Mustan1- Aa fa+orite carC will 'e craced =uicl#. !tron1er
passwords such as -G;ou8*l6e+a>i6dMe#e&as!7erdQ-, are less liel# to 'e craced.
6ote 3nce the attacer has o'tained the list of password hashes, the dictionar# attac can
'e performed offline and does not re=uire interaction with the application.
Countermeasures to pre+ent dictionar# attacs include:
5se stron1 passwords that are complex, are not re1ular words, and contain a mixture of upper
case, lower case, numeric, and special characters.
!tore non@re+ersi'le password hashes in the user store. Also com'ine a salt +alue Aa
cr#pto1raphicall# stron1 random num'erC with the password hash.
>or more information a'out storin1 password hashes with added salt, see Chapter ?I, -9uildin1
!ecure Data Access.-
Cookie 0eplay Attacks
7ith this t#pe of attac, the attacer captures the user8s authentication cooie usin1 monitorin1
software and repla#s it to the application to 1ain access under a false identit#.
Countermeasures to pre+ent cooie repla# include:
5se an encr#pted communication channel pro+ided '# !!* whene+er an authentication
cooie is transmitted.
5se a cooie timeout to a +alue that forces authentication after a relati+el# short time
inter+al. Althou1h this doesn8t pre+ent repla# attacs, it reduces the time inter+al in which
the attacer can repla# a re=uest without 'ein1 forced to re@authenticate 'ecause the
session has timed out.
Credential The&t
0f #our application implements its own user store containin1 user account names and passwords,
compare its securit# to the credential stores pro+ided '# the platform, for example, a Microsoft
Acti+e Director#D director# ser+ice or !ecurit# Accounts Mana1er A!AMC user store. 9rowser
histor# and cache also store user lo1in information for future use. 0f the terminal is accessed '#
someone other than the user who lo11ed on, and the same pa1e is hit, the sa+ed lo1in will 'e
a+aila'le.
Countermeasures to help pre+ent credential theft include:
5se and enforce stron1 passwords.
!tore password +erifiers in the form of one wa# hashes with added salt.
%nforce account locout for end@user accounts after a set num'er of retr# attempts.
To counter the possi'ilit# of the 'rowser cache allowin1 lo1in access, create functionalit#
that either allows the user to choose to not sa+e credentials, or force this functionalit# as a
default polic#.
Authori4ation
9ased on user identit# and role mem'ership, authori2ation to a particular resource or ser+ice is
either allowed or denied. Top threats that exploit authori2ation +ulnera'ilities include:
(levation o& privilege
*isclosure o& con&idential data
*ata tampering
6uring attacks
(levation o& /rivilege
7hen #ou desi1n an authori2ation model, #ou must consider the threat of an attacer tr#in1 to
ele+ate pri+ile1es to a powerful account such as a mem'er of the local administrators 1roup or
the local s#stem account. 9# doin1 this, the attacer is a'le to tae complete control o+er the
application and local machine. >or example, with classic A!& pro1rammin1, callin1 the
0evertToSel& A&0 from a component mi1ht cause the executin1 thread to run as the local s#stem
account with the most power and pri+ile1es on the local machine.
The main countermeasure that #ou can use to pre+ent ele+ation of pri+ile1e is to use least
pri+ile1ed process, ser+ice, and user accounts.
*isclosure o& Con&idential *ata
The disclosure of confidential data can occur if sensiti+e data can 'e +iewed '# unauthori2ed
users. Confidential data includes application specific data such as credit card num'ers, emplo#ee
details, financial records and so on to1ether with application confi1uration data such as ser+ice
account credentials and data'ase connection strin1s. To pre+ent the disclosure of confidential
data #ou should secure it in persistent stores such as data'ases and confi1uration files, and durin1
transit o+er the networ. 3nl# authenticated and authori2ed users should 'e a'le to access the
data that is specific to them. Access to s#stem le+el confi1uration data should 'e restricted to
administrators.
Countermeasures to pre+ent disclosure of confidential data include:
&erform role checs 'efore allowin1 access to the operations that could potentiall# re+eal
sensiti+e data.
5se stron1 AC*s to secure 7indows resources.
5se standard encr#ption to store sensiti+e data in confi1uration files and data'ases.
*ata Tampering
Data tamperin1 refers to the unauthori2ed modification of data.
Countermeasures to pre+ent data tamperin1 include:
5se stron1 access controls to protect data in persistent stores to ensure that onl# authori2ed
users can access and modif# the data.
5se role@'ased securit# to differentiate 'etween users who can +iew data and users who can
modif# data.
6uring Attacks
A lurin1 attac occurs when an entit# with few pri+ile1es is a'le to ha+e an entit# with more
pri+ile1es perform an action on its 'ehalf.
To counter the threat, #ou must restrict access to trusted code with the appropriate authori2ation.
5sin1 .6%T >ramewor code access securit# helps in this respect '# authori2in1 callin1 code
whene+er a secure resource is accessed or a pri+ile1ed operation is performed.
Con&iguration )anagement
Man# applications support confi1uration mana1ement interfaces and functionalit# to allow
operators and administrators to chan1e confi1uration parameters, update 7e' site content, and to
perform routine maintenance. Top confi1uration mana1ement threats include:
$nauthori4ed access to administration inter&aces
$nauthori4ed access to con&iguration stores
0etrieval o& plainte!t con&iguration secrets
6ack o& individual accountability
Over5privileged process and service accounts
$nauthori4ed Access to Administration Inter&aces
Administration interfaces are often pro+ided throu1h additional 7e' pa1es or separate 7e'
applications that allow administrators, operators, and content de+elopers to mana1ed site content
and confi1uration. Administration interfaces such as these should 'e a+aila'le onl# to restricted
and authori2ed users. Malicious users a'le to access a confi1uration mana1ement function can
potentiall# deface the 7e' site, access downstream s#stems and data'ases, or tae the
application out of action alto1ether '# corruptin1 confi1uration data.
Countermeasures to pre+ent unauthori2ed access to administration interfaces include:
Minimi2e the num'er of administration interfaces.
5se stron1 authentication, for example, '# usin1 certificates.
5se stron1 authori2ation with multiple 1ateeepers.
Consider supportin1 onl# local administration. 0f remote administration is a'solutel#
essential, use encr#pted channels, for example, with "&6 technolo1# or !!*, 'ecause of
the sensiti+e nature of the data passed o+er administrati+e interfaces. To further reduce
ris, also consider usin1 0&!ec policies to limit remote administration to computers on the
internal networ.
$nauthori4ed Access to Con&iguration Stores
9ecause of the sensiti+e nature of the data maintained in confi1uration stores, #ou should ensure
that the stores are ade=uatel# secured.
Countermeasures to protect confi1uration stores include:
Confi1ure restricted AC*s on text@'ased confi1uration files such as Machine.confi1 and
7e'.confi1.
Keep custom confi1uration stores outside of the 7e' space. This remo+es the potential to
download 7e' ser+er confi1urations to exploit their +ulnera'ilities.
0etrieval o& /lainte!t Con&iguration Secrets
$estrictin1 access to the confi1uration store is a must. As an important defense in depth
mechanism, #ou should encr#pt sensiti+e data such as passwords and connection strin1s. This
helps pre+ent external attacers from o'tainin1 sensiti+e confi1uration data. 0t also pre+ents
ro1ue administrators and internal emplo#ees from o'tainin1 sensiti+e details such as data'ase
connection strin1s and account credentials that mi1ht allow them to 1ain access to other s#stems.
6ack o& Individual Accountability
*ac of auditin1 and lo11in1 of chan1es made to confi1uration information threatens the a'ilit#
to identif# when chan1es were made and who made those chan1es. 7hen a 'reain1 chan1e is
made either '# an honest operator error or '# a malicious chan1e to 1rant pri+ile1ed access,
action must first 'e taen to correct the chan1e. Then appl# pre+enti+e measures to pre+ent
'reain1 chan1es to 'e introduced in the same manner. Keep in mind that auditin1 and lo11in1
can 'e circum+ented '# a shared accountF this applies to 'oth administrati+e and
user/application/ser+ice accounts. Administrati+e accounts must not 'e shared.
5ser/application/ser+ice accounts must 'e assi1ned at a le+el that allows the identification of a
sin1le source of access usin1 the account, and that contains an# dama1e to the pri+ile1es 1ranted
that account.
Over5privileged Application and Service Accounts
0f application and ser+ice accounts are 1ranted access to chan1e confi1uration information on the
s#stem, the# ma# 'e manipulated to do so '# an attacer. The ris of this threat can 'e miti1ated
'# adoptin1 a polic# of usin1 least pri+ile1ed ser+ice and application accounts. 9e war# of
1rantin1 accounts the a'ilit# to modif# their own confi1uration information unless explicitl#
re=uired '# desi1n.
Sensitive *ata
!ensiti+e data is su'<ect to a +ariet# of threats. Attacs that attempt to +iew or modif# sensiti+e
data can tar1et persistent data stores and networs. Top threats to sensiti+e data include:
Access to sensitive data in storage
1etwork eavesdropping
*ata tampering
Access to Sensitive *ata in Storage
;ou must secure sensiti+e data in stora1e to pre+ent a user : malicious or otherwise : from
1ainin1 access to and readin1 the data.
Countermeasures to protect sensiti+e data in stora1e include:
5se restricted AC*s on the persistent data stores that contain sensiti+e data.
!tore encr#pted data.
5se identit# and role@'ased authori2ation to ensure that onl# the user or users with the
appropriate le+el of authorit# are allowed access to sensiti+e data. 5se role@'ased securit#
to differentiate 'etween users who can +iew data and users who can modif# data.
1etwork (avesdropping
The 4TT& data for 7e' application tra+els across networs in plaintext and is su'<ect to networ
ea+esdroppin1 attacs, where an attacer uses networ monitorin1 software to capture and
potentiall# modif# sensiti+e data.
Countermeasures to pre+ent networ ea+esdroppin1 and to pro+ide pri+ac# include:
%ncr#pt the data.
5se an encr#pted communication channel, for example, !!*.
*ata Tampering
Data tamperin1 refers to the unauthori2ed modification of data, often as it is passed o+er the
networ.
3ne countermeasure to pre+ent data tamperin1 is to protect sensiti+e data passed across the
networ with tamper@resistant protocols such as hashed messa1e authentication codes A4MACsC.
An 4MAC pro+ides messa1e inte1rit# in the followin1 wa#:
?. The sender uses a shared secret e# to create a hash 'ased on the messa1e pa#load.
2. The sender transmits the hash alon1 with the messa1e pa#load.
). The recei+er uses the shared e# to recalculate the hash 'ased on the recei+ed messa1e
pa#load. The recei+er then compares the new hash +alue with the transmitted hash +alue.
0f the# are the same, the messa1e cannot ha+e 'een tampered with.
Session )anagement
!ession mana1ement for 7e' applications is an application la#er responsi'ilit#. !ession securit#
is critical to the o+erall securit# of the application.
Top session mana1ement threats include:
Session hi2acking
Session replay
)an in the middle
Session #i2acking
A session hi<acin1 attac occurs when an attacer uses networ monitorin1 software to capture
the authentication toen Aoften a cooieC used to represent a user8s session with an application.
7ith the captured cooie, the attacer can spoof the user8s session and 1ain access to the
application. The attacer has the same le+el of pri+ile1es as the le1itimate user.
Countermeasures to pre+ent session hi<acin1 include:
5se !!* to create a secure communication channel and onl# pass the authentication cooie
o+er an 4TT&! connection.
0mplement lo1out functionalit# to allow a user to end a session that forces authentication if
another session is started.
Mae sure #ou limit the expiration period on the session cooie if #ou do not use !!*.
Althou1h this does not pre+ent session hi<acin1, it reduces the time window a+aila'le to
the attacer.
Session 0eplay
!ession repla# occurs when a user8s session toen is intercepted and su'mitted '# an attacer to
'#pass the authentication mechanism. >or example, if the session toen is in plaintext in a cooie
or 5$*, an attacer can sniff it. The attacer then posts a re=uest usin1 the hi<aced session
toen.
Countermeasures to help address the threat of session repla# include:
$e@authenticate when performin1 critical functions. >or example, prior to performin1 a
monetar# transfer in a 'anin1 application, mae the user suppl# the account password
a1ain.
%xpire sessions appropriatel#, includin1 all cooies and session toens.
Create a -do not remem'er me- option to allow no session data to 'e stored on the client.
)an in the )iddle Attacks
A man in the middle attac occurs when the attacer intercepts messa1es sent 'etween #ou and
#our intended recipient. The attacer then chan1es #our messa1e and sends it to the ori1inal
recipient. The recipient recei+es the messa1e, sees that it came from #ou, and acts on it. 7hen
the recipient sends a messa1e 'ac to #ou, the attacer intercepts it, alters it, and returns it to
#ou. ;ou and #our recipient ne+er now that #ou ha+e 'een attaced.
An# networ re=uest in+ol+in1 client@ser+er communication, includin1 7e' re=uests,
Distri'uted Component 3'<ect Model ADC3MC re=uests, and calls to remote components and
7e' ser+ices, are su'<ect to man in the middle attacs.
Countermeasures to pre+ent man in the middle attacs include:
5se cr#pto1raph#. 0f #ou encr#pt the data 'efore transmittin1 it, the attacer can still
intercept it 'ut cannot read it or alter it. 0f the attacer cannot read it, he or she cannot
now which parts to alter. 0f the attacer 'lindl# modifies #our encr#pted messa1e, then
the ori1inal recipient is una'le to successfull# decr#pt it and, as a result, nows that it has
'een tampered with.
5se 4ashed Messa1e Authentication Codes A4MACsC. 0f an attacer alters the messa1e, the
recalculation of the 4MAC at the recipient fails and the data can 'e re<ected as in+alid.
Cryptography
Most applications use cr#pto1raph# to protect data and to ensure it remains pri+ate and
unaltered. Top threats surroundin1 #our application8s use of cr#pto1raph# include:
/oor key generation or key management
Weak or custom encryption
Checksum spoo&ing
/oor ;ey 3eneration or ;ey )anagement
Attacers can decr#pt encr#pted data if the# ha+e access to the encr#ption e# or can deri+e the
encr#ption e#. Attacers can disco+er a e# if e#s are mana1ed poorl# or if the# were
1enerated in a non@random fashion.
Countermeasures to address the threat of poor e# 1eneration and e# mana1ement include:
5se 'uilt@in encr#ption routines that include secure e# mana1ement. Data &rotection
application pro1rammin1 interface AD&A&0C is an example of an encr#ption ser+ice
pro+ided on 7indows 2((( and later operatin1 s#stems where the operatin1 s#stem
mana1es the e#.
5se stron1 random e# 1eneration functions and store the e# in a restricted location : for
example, in a re1istr# e# secured with a restricted AC* : if #ou use an encr#ption
mechanism that re=uires #ou to 1enerate or mana1e the e#.
%ncr#pt the encr#ption e# usin1 D&A&0 for added securit#.
%xpire e#s re1ularl#.
Weak or Custom (ncryption
An encr#ption al1orithm pro+ides no securit# if the encr#ption is craced or is +ulnera'le to
'rute force cracin1. Custom al1orithms are particularl# +ulnera'le if the# ha+e not 'een tested.
0nstead, use pu'lished, well@nown encr#ption al1orithms that ha+e withstood #ears of ri1orous
attacs and scrutin#.
Countermeasures that address the +ulnera'ilities of wea or custom encr#ption include:
Do not de+elop #our own custom al1orithms.
5se the pro+en cr#pto1raphic ser+ices pro+ided '# the platform.
!ta# informed a'out craced al1orithms and the techni=ues used to crac them.
Checksum Spoo&ing
Do not rel# on hashes to pro+ide data inte1rit# for messa1es sent o+er networs. 4ashes such as
!ecure 4ash Al1orithm A!4A?C and Messa1e Di1est compression al1orithm AMDLC can 'e
intercepted and chan1ed. Consider the followin1 'ase ,I encodin1 5T>@M messa1e with an
appended Messa1e Authentication Code AMACC.
<a+ascript:Cop#CodeA8ctl((Hrs?HmainContentContainerHc
tl?L8CF Cop# Code
@)ainte*tB @)ace 10 orders'
=ashB 70m;>d5Dh1EI9Fo7ca@GFH1IJp;,
0f an attacer intercepts the messa1e '# monitorin1 the networ, the attacer could update the
messa1e and recompute the hash A1uessin1 the al1orithm that #ou usedC. >or example, the
messa1e could 'e chan1ed to:
<a+ascript:Cop#CodeA8ctl((Hrs?HmainContentContainerHc
tl?,8CF Cop# Code
@)ainte*tB @)ace 100 orders'
=ashB o51uKpvLtI;MBI11>v1M52=e2;,
7hen recipients process the messa1e, and the# run the plaintext A-&lace ?(( orders-C throu1h the
hashin1 al1orithm, and then recompute the hash, the hash the# calculate will 'e e=ual to
whate+er the attacer computed.
To counter this attac, use a MAC or 4MAC. The Messa1e Authentication Code Triple Data
%ncr#ption !tandard AMACTripleD%!C al1orithm computes a MAC, and 4MAC!4A? computes
an 4MAC. 9oth use a e# to produce a checsum. 7ith these al1orithms, an attacer needs to
now the e# to 1enerate a checsum that would compute correctl# at the recei+er.
/arameter )anipulation
&arameter manipulation attacs are a class of attac that relies on the modification of the
parameter data sent 'etween the client and 7e' application. This includes =uer# strin1s, form
fields, cooies, and 4TT& headers. Top parameter manipulation threats include:
7uery string manipulation
+orm &ield manipulation
Cookie manipulation
#TT/ header manipulation
7uery String )anipulation
5sers can easil# manipulate the =uer# strin1 +alues passed '# 4TT& /%T from client to ser+er
'ecause the# are displa#ed in the 'rowser8s 5$* address 'ar. 0f #our application relies on =uer#
strin1 +alues to mae securit# decisions, or if the +alues represent sensiti+e data such as
monetar# amounts, the application is +ulnera'le to attac.
Countermeasures to address the threat of =uer# strin1 manipulation include:
A+oid usin1 =uer# strin1 parameters that contain sensiti+e data or data that can influence the
securit# lo1ic on the ser+er. 0nstead, use a session identifier to identif# the client and store
sensiti+e items in the session store on the ser+er.
Choose 4TT& &3!T instead of /%T to su'mit forms.
%ncr#pt =uer# strin1 parameters.
+orm +ield )anipulation
The +alues of 4TM* form fields are sent in plaintext to the ser+er usin1 the 4TT& &3!T
protocol. This ma# include +isi'le and hidden form fields. >orm fields of an# t#pe can 'e easil#
modified and client@side +alidation routines '#passed. As a result, applications that rel# on form
field input +alues to mae securit# decisions on the ser+er are +ulnera'le to attac.
To counter the threat of form field manipulation, instead of usin1 hidden form fields, use session
identifiers to reference state maintained in the state store on the ser+er.
Cookie )anipulation
Cooies are suscepti'le to modification '# the client. This is true of 'oth persistent and memor#@
resident cooies. A num'er of tools are a+aila'le to help an attacer modif# the contents of a
memor#@resident cooie. Cooie manipulation is the attac that refers to the modification of a
cooie, usuall# to 1ain unauthori2ed access to a 7e' site.
7hile !!* protects cooies o+er the networ, it does not pre+ent them from 'ein1 modified on
the client computer. To counter the threat of cooie manipulation, encr#pt and use an 4MAC
with the cooie.
#TT/ #eader )anipulation
4TT& headers pass information 'etween the client and the ser+er. The client constructs re=uest
headers while the ser+er constructs response headers. 0f #our application relies on re=uest
headers to mae a decision, #our application is +ulnera'le to attac.
Do not 'ase #our securit# decisions on 4TT& headers. >or example, do not trust the 4TT&
$eferer to determine where a client came from 'ecause this is easil# falsified.
(!ception )anagement
%xceptions that are allowed to propa1ate to the client can re+eal internal implementation details
that mae no sense to the end user 'ut are useful to attacers. Applications that do not use
exception handlin1 or implement it poorl# are also su'<ect to denial of ser+ice attacs. Top
exception handlin1 threats include:
Attacker reveals implementation details
*enial o& service
Attacker 0eveals Implementation *etails
3ne of the important features of the .6%T >ramewor is that it pro+ides rich exception details
that are in+alua'le to de+elopers. 0f the same information is allowed to fall into the hands of an
attacer, it can 1reatl# help the attacer exploit potential +ulnera'ilities and plan future attacs.
The t#pe of information that could 'e returned includes platform +ersions, ser+er names, !E*
command strin1s, and data'ase connection strin1s.
Countermeasures to help pre+ent internal implementation details from 'ein1 re+ealed to the
client include:
5se exception handlin1 throu1hout #our application8s code 'ase.
4andle and lo1 exceptions that are allowed to propa1ate to the application 'oundar#.
$eturn 1eneric, harmless error messa1es to the client.
*enial o& Service
Attacers will pro'e a 7e' application, usuall# '# passin1 deli'eratel# malformed input. The#
often ha+e two 1oals in mind. The first is to cause exceptions that re+eal useful information and
the second is to crash the 7e' application process. This can occur if exceptions are not properl#
cau1ht and handled.
Countermeasures to help pre+ent application@le+el denial of ser+ice include:
Thorou1hl# +alidate all input data at the ser+er.
5se exception handlin1 throu1hout #our application8s code 'ase.
Auditing and 6ogging
Auditin1 and lo11in1 should 'e used to help detect suspicious acti+it# such as footprintin1 or
possi'le password cracin1 attempts 'efore an exploit actuall# occurs. 0t can also help deal with
the threat of repudiation. 0t is much harder for a user to den# performin1 an operation if a series
of s#nchroni2ed lo1 entries on multiple ser+ers indicate that the user performed that transaction.
Top auditin1 and lo11in1 related threats include:
$ser denies per&orming an operation
Attackers e!ploit an application without leaving a trace
Attackers cover their tracks
$ser *enies /er&orming an Operation
The issue of repudiation is concerned with a user den#in1 that he or she performed an action or
initiated a transaction. ;ou need defense mechanisms in place to ensure that all user acti+it# can
'e traced and recorded.
Countermeasures to help pre+ent repudiation threats include:
Audit and lo1 acti+it# on the 7e' ser+er and data'ase ser+er, and on the application ser+er as
well, if #ou use one.
*o1 e# e+ents such as transactions and lo1in and lo1out e+ents.
Do not use shared accounts since the ori1inal source cannot 'e determined.
Attackers (!ploit an Application Without 6eaving a Trace
!#stem and application@le+el auditin1 is re=uired to ensure that suspicious acti+it# does not 1o
undetected.
Countermeasures to detect suspicious acti+it# include:
*o1 critical application le+el operations.
5se platform@le+el auditin1 to audit lo1in and lo1out e+ents, access to the file s#stem, and
failed o'<ect access attempts.
9ac up lo1 files and re1ularl# anal#2e them for si1ns of suspicious acti+it#.
Attackers Cover Their Tracks
;our lo1 files must 'e well@protected to ensure that attacers are not a'le to co+er their tracs.
Countermeasures to help pre+ent attacers from co+erin1 their tracs include:
!ecure lo1 files '# usin1 restricted AC*s.
$elocate s#stem lo1 files awa# from their default locations.
Summary
9# 'ein1 aware of the t#pical approach used '# attacers as well as their 1oals, #ou can 'e more
effecti+e when appl#in1 countermeasures. 0t also helps to use a 1oal@'ased approach when
considerin1 and identif#in1 threats, and to use the !T$0D% model to cate1ori2e threats 'ased on
the 1oals of the attacer, for example, to spoof identit#, tamper with data, den# ser+ice, ele+ate
pri+ile1es, and so on. This allows #ou to focus more on the 1eneral approaches that should 'e
used for ris miti1ation, rather than focusin1 on the identification of e+er# possi'le attac, which
can 'e a time@consumin1 and potentiall# fruitless exercise.
This chapter has shown #ou the top threats that ha+e the potential to compromise #our networ,
host infrastructure, and applications. Knowled1e of these threats, to1ether with the appropriate
countermeasures, pro+ides essential information for the threat modelin1 process 0t ena'les #ou to
identif# the threats that are specific to #our particular scenario and prioriti2e them 'ased on the
de1ree of ris the# pose to #our s#stem. This structured process for identif#in1 and prioriti2in1
threats is referred to as threat modeling. >or more information, see Chapter ), -Threat
Modelin1.-
Additional 0esources
>or further related readin1, see the followin1 resources:
>or more information a'out networ threats and countermeasures, see Chapter ?L, -!ecurin1
;our 6etwor.-
>or more information a'out host threats and countermeasures, see Chapter ?,, -!ecurin1
;our 7e' !er+er,- Chapter ?N, -!ecurin1 ;our Application !er+er,- Chapter ?M,
-!ecurin1 ;our Data'ase !er+er,- and Chapter ?O, -!ecurin1 ;our A!&.6%T
Application.-
>or more information a'out addressin1 the application le+el threats presented in this chapter,
see the 9uildin1 chapters in &art 000, -9uildin1 !ecure 7e' Applications- of this 1uide.
Michael 4oward and Da+id *e9lanc, Writing Secure Code 2nd %dition. Microsoft &ress,
$edmond, 7A, 2((2
>or more information a'out tracin1 and fixin1 'uffer o+erruns, see the M!D6 article, ->ix
Those 9uffer 3+erruns,- at http://msdn.microsoft.com/li'rar#/en@
us/dncode/html/secure(L2(2((2.asp
Chapter ) Threat Modelin1
http://www.microsoft.com/practices http://www.microsoft.
com/practices
Improving Web Application Security: Threats and Countermeasures
J.D. Meier, Alex Macman, Michael Dunner, !rinath "asiredd#, $a# %scamilla and Anandha
Muruan
Microsoft Corporation
&u'lished: June 2(()
Applies to:
7e' Applications
!ee the -patterns . practices !ecurit# /uidance for Applications 0ndex- for lins to additional
securit# resources.
!ee the *andin1 &a1e for the startin1 point and a complete o+er+iew of Improving Web
Application Security: Threats and Countermeasures.
Summary: Threat modelin1 allows #ou to appl# a structured approach to securit# and to address
the top threats that ha+e the 1reatest potential impact to #our application first. This chapter helps
#ou to decompose #our 7e' application to identif# and rate the threats that are most liel# to
impact #our s#stem. The chapter presents a six@step threat modelin1 process.
Contents
0n This Chapter
3+er+iew
9efore ;ou 9e1in
4ow to 5se This Chapter
Threat Modelin1 &rinciples
!tep ?. 0dentif# Assets
!tep 2. Create an Architecture 3+er+iew
!tep ). Decompose the Application
!tep I. 0dentif# the Threats
!tep L. Document the Threats
!tep ,. $ate the Threats
7hat Comes After Threat Modelin1G
!ummar#
Additional $esources
In This Chapter
!teps to decompose application architecture to disco+er +ulnera'ilities
4ow to identif# and document threats that are rele+ant to #our application
Overview
Threat modelin1 allows #ou to s#stematicall# identif# and rate the threats that are most liel# to
affect #our s#stem. 9# identif#in1 and ratin1 threats 'ased on a solid understandin1 of the
architecture and implementation of #our application, #ou can address threats with appropriate
countermeasures in a lo1ical order, startin1 with the threats that present the 1reatest ris.
Threat modelin1 has a structured approach that is far more cost efficient and effecti+e than
appl#in1 securit# features in a hapha2ard manner without nowin1 precisel# what threats each
feature is supposed to address. 7ith a random, -shot1un- approach to securit#, how do #ou now
when #our application is -secure enou1h,- and how do #ou now the areas where #our
application is still +ulnera'leG 0n short, until #ou now #our threats, #ou cannot secure #our
s#stem.
6ote >or more information a'out the latest threat modelin1 process, see -Threat
Modelin1 7e' Applications.-
%e&ore <ou %egin
9efore #ou start the threat modelin1 process, it is important that #ou understand the followin1
'asic terminolo1#:
Asset. A resource of +alue, such as the data in a data'ase or on the file s#stem. A s#stem
resource.
Threat. A potential occurrence, malicious or otherwise, that mi1ht dama1e or compromise
#our assets.
Vulnerability. A weaness in some aspect or feature of a s#stem that maes a threat possi'le.
"ulnera'ilities mi1ht exist at the networ, host, or application le+els.
Attack or e!ploit". An action taen '# someone or somethin1 that harms an asset. This
could 'e someone followin1 throu1h on a threat or exploitin1 a +ulnera'ilit#.
Countermeasure. A safe1uard that addresses a threat and miti1ates ris.
Consider a simple house analo1#: an item of <ewelr# in a house is an asset and a 'ur1lar is an
attacer. A door is a feature of the house and an open door represents a +ulnera'ilit#. The 'ur1lar
can exploit the open door to 1ain access to the house and steal the <ewelr#. 0n other words, the
attacer exploits a +ulnera'ilit# to 1ain access to an asset. The appropriate countermeasure in this
case is to close and loc the door.
#ow to $se This Chapter
This chapter outlines a 1eneric process that helps #ou identif# and document threats to #our
application. The followin1 are recommendations on how to use this chapter:
(stablish a process &or threat modeling. 5se this chapter as a startin1 point for introducin1
a threat modelin1 process in #our or1ani2ation if #ou do not alread# ha+e one. 0f #ou
alread# ha+e a process, then #ou can use this as a reference for comparison.
$se the other chapters in this guide to &amiliari4e yoursel& with the most common
threats. $ead Chapter 2, -Threats and Countermeasures,- for an o+er+iew of common
threats that occur at the networ, host, and application le+els.
>or more specific threats to #our networ, see -Threats and Countermeasures- in
Chapter ?L, -!ecurin1 ;our 6etwor.-
>or more specific threats to #our 7e' ser+er, application ser+er, and data'ase ser+er,
see -Threats and Countermeasures- in Chapter ?,, -!ecurin1 ;our 7e' !er+er,-
Chapter ?N, -!ecurin1 ;our Application !er+er,- and Chapter ?M, -!ecurin1 ;our
Data'ase !er+er.-
>or more specific threats to #our assem'lies, A!&.6%T, ser+iced components,
remoted components, 7e' !er+ices, and data access, see -Threats and
Countermeasures- in Chapter N, -9uildin1 !ecure Assem'liesF- Chapter ?(,
-9uildin1 !ecure A!&.6%T &a1es and ControlsF- Chapter ??, -9uildin1 !ecure
!er+iced ComponentsF- Chapter ?2, -9uildin1 !ecure 7e' !er+icesF- Chapter ?),
-9uildin1 !ecure $emoted ComponentsF- and Chapter ?I, -9uildin1 !ecure Data
Access.-
(volve your threat model. 9uild a threat model earl# and then e+ol+e it as #ou 1o. 0t is a
wor in pro1ress. !ecurit# threats e+ol+e, and so does #our application. 4a+in1 a
document that identifies 'oth what the nown threats are and how the# ha+e 'een
addressed Aor notC puts #ou in control of the securit# of #our application.
Threat )odeling /rinciples
Threat modelin1 should not 'e a one time onl# process. 0t should 'e an iterati+e process that
starts durin1 the earl# phases of the desi1n of #our application and continues throu1hout the
application life c#cle. There are two reasons for this. >irst, it is impossi'le to identif# all of the
possi'le threats in a sin1le pass. !econd, 'ecause applications are rarel# static and need to 'e
enhanced and adapted to suit chan1in1 'usiness re=uirements, the threat modelin1 process
should 'e repeated as #our application e+ol+es.
The /rocess
>i1ure ).? shows the threat modelin1 process that #ou can perform usin1 a six@sta1e process.
6ote The followin1 process outline can 'e used for applications that are currentl# in
de+elopment and for existin1 applications.

+igure =-.
An overview of the threat modeling process
I. Identi&y assets.
0dentif# the +alua'le assets that #our s#stems must protect.
L. Create an architecture overview.
5se simple dia1rams and ta'les to document the architecture of #our application,
includin1 su's#stems, trust 'oundaries, and data flow.
,. *ecompose the application.
Decompose the architecture of #our application, includin1 the underl#in1 networ and
host infrastructure desi1n, to create a securit# profile for the application. The aim of the
securit# profile is to unco+er +ulnera'ilities in the desi1n, implementation, or deplo#ment
confi1uration of #our application.
N. Identi&y the threats.
Keepin1 the 1oals of an attacer in mind, and with nowled1e of the architecture and
potential +ulnera'ilities of #our application, identif# the threats that could affect the
application.
M. *ocument the threats.
Document each threat usin1 a common threat template that defines a core set of attri'utes
to capture for each threat.
O. 0ate the threats.
$ate the threats to prioriti2e and address the most si1nificant threats first. These threats
present the 'i11est ris. The ratin1 process wei1hs the pro'a'ilit# of the threat a1ainst
dama1e that could result should an attac occur. 0t mi1ht turn out that certain threats do
not warrant an# action when #ou compare the ris posed '# the threat with the resultin1
miti1ation costs.
The Output
The output from the threat modelin1 process is a document for the +arious mem'ers of #our
pro<ect team. 0t allows them to clearl# understand the threats that need to 'e addressed and how
to address them. Threat models consist of a definition of the architecture of #our application and
a list of threats for #our application scenario, as >i1ure ).2 shows.

+igure =-,
Components of the threat model
Step .- Identi&y Assets
0dentif# the assets that #ou need to protect. This could ran1e from confidential data, such as #our
customer or orders data'ase, to #our 7e' pa1es or 7e' site a+aila'ilit#.
Step ,- Create an Architecture Overview
At this sta1e, the 1oal is to document the function of #our application, its architecture and
ph#sical deplo#ment confi1uration, and the technolo1ies that form part of #our solution. ;ou
should 'e looin1 for potential +ulnera'ilities in the desi1n or implementation of the application.
Durin1 this step, #ou perform the followin1 tass:
Identi&y what the application does.
Create an architecture diagram.
Identi&y the technologies.
Identi&y What the Application *oes
0dentif# what the application does and how it uses and accesses assets. Document use cases to
help #ou and others understand how #our application is supposed to 'e used. This also helps #ou
wor out how it can 'e misused. 5se cases put application functionalit# in context.
4ere are some sample use cases for a self@ser+ice, emplo#ee human resources application:
%mplo#ee +iews financial data.
%mplo#ee updates personal data.
Mana1er +iews emplo#ee details.
0n the a'o+e cases #ou can loo at the implications of the 'usiness rules 'ein1 misused. >or
example, consider a user tr#in1 to modif# personal details of another user. 4e or she should not
'e authori2ed to access those details accordin1 to the defined application re=uirements.
Create an Architecture *iagram
Create a hi1h@le+el architecture dia1ram that descri'es the composition and structure of #our
application and its su's#stems as well as its ph#sical deplo#ment characteristics, such as the
dia1ram in >i1ure ).). Dependin1 on the complexit# of #our s#stem, #ou mi1ht need to create
additional dia1rams that focus on different areas, for example, a dia1ram to model the
architecture of a middle@tier application ser+er, or one to model the interaction with an external
s#stem.

+igure =-=
Sample application architecture diagram
!tart '# drawin1 a rou1h dia1ram that con+e#s the composition and structure of the application
and its su's#stems to1ether with its deplo#ment characteristics. Then, e+ol+e the dia1ram '#
addin1 details a'out the trust 'oundaries, authentication, and authori2ation mechanisms as and
when #ou disco+er them Ausuall# durin1 !tep ) when #ou decompose the applicationC.
Identi&y the Technologies
0dentif# the distinct technolo1ies that are used to implement #our solution. This helps #ou focus
on technolo1#@specific threats later in the process. 0t also helps #ou determine the correct and
most appropriate miti1ation techni=ues. The technolo1ies #ou are most liel# to identif# include
A!&.6%T, 7e' !er+ices, %nterprise !er+ices, Microsoft .6%T $emotin1, and AD3.6%T. Also
identif# an# unmana1ed code that #our application calls.
Document the technolo1ies usin1 a ta'le similar to Ta'le ).?, 'elow.
Table =-. Implementation Technologies
Technology>/lat&orm Implementation *etails
Microsoft !E* !er+er on Microsoft
7indows Ad+anced !er+er 2(((
0ncludes lo1ins, data'ase users, user defined data'ase roles,
ta'les, stored procedures, +iews, constraints, and tri11ers.
Microsoft .6%T >ramewor 5sed for >orms authentication.
!ecure !ocets *a#er A!!*C 5sed to encr#pt 4TT& traffic.
Step =- *ecompose the Application
0n this step, #ou 'rea down #our application to create a securit# profile for the application 'ased
on traditional areas of +ulnera'ilit#. ;ou also identif# trust 'oundaries, data flow, entr# points,
and pri+ile1ed code. The more #ou now a'out the mechanics of #our application, the easier it is
to unco+er threats. >i1ure ).I shows the +arious tar1ets for the decomposition process.

+igure =-?
Targets for application decomposition
Durin1 this step, #ou perform the followin1 tass:
Identi&y trust boundaries.
Identi&y data &low.
Identi&y entry points.
Identi&y privileged code.
*ocument the security pro&ile.
Identi&y Trust %oundaries
0dentif# the trust 'oundaries that surround each of the tan1i'le assets of #our application. These
assets are determined '# #our application desi1n. >or each su's#stem, consider whether the
upstream data flows or user input is trusted, and if not, consider how the data flows and input can
'e authenticated and authori2ed. Also consider whether the callin1 code is trusted, and if it is not,
consider how it can 'e authenticated and authori2ed. ;ou must 'e a'le to ensure that the
appropriate 1ateeepers 1uard all entr# points into a particular trust 'oundar# and that the
recipient entr# point full# +alidates all data passed across a trust 'oundar#.
!tart '# anal#2in1 trust 'oundaries from a code perspecti+e. The assem'l#, which represents one
form of trust 'oundar#, is a useful place to start. 7hich assem'lies trust which other assem'liesG
Does a particular assem'l# trust the code that calls it, or does it use code access securit# to
authori2e the callin1 codeG
Also consider ser+er trust relationships. Does a particular ser+er trust an upstream ser+er to
authenticate and authori2e the end users, or does the ser+er pro+ide its own 1ateeepin1
ser+icesG Also, does a ser+er trust an upstream ser+er to pass it data that is well formed and
correctG
>or example, in >i1ure ).), the 7e' application accesses the data'ase ser+er '# usin1 a fixed,
trusted identit#, which in this case is the A!&.6%T 7e' application process account. 0n this
scenario, the data'ase ser+er trusts the application to authenticate and authori2e callers and
forward onl# +alid data re=uest data on 'ehalf of authori2ed users.
6ote 0n a .6%T >ramewor application, the assem'l# defines the smallest unit of trust.
7hene+er data is passed across an assem'l# 'oundar# : which '# definition includes an
application domain, process, or machine 'oundar# : the recipient entr# point should
+alidate its input data.
Identi&y *ata +low
A simple approach is to start at the hi1hest le+el and then iterati+el# decompose the application
'# anal#2in1 the data flow 'etween indi+idual su's#stems. >or example, anal#2e the data flow
'etween a 7e' application and an %nterprise !er+ices application and then 'etween indi+idual
ser+iced components.
Data flow across trust 'oundaries is particularl# important 'ecause code that is passed data from
outside its own trust 'oundar# should assume that the data is malicious and perform thorou1h
+alidation of the data.
6ote Data flow dia1rams AD>DsC and se=uence dia1rams can help with the formal
decomposition of a s#stem. A D>D is a 1raphical representation of data flows, data
stores, and relationships 'etween data sources and destinations. A se=uence dia1ram
shows how a 1roup of o'<ects colla'orate in terms of chronolo1ical e+ents.
Identi&y (ntry /oints
The entr# points of #our application also ser+e as entr# points for attacs. %ntr# points mi1ht
include the front@end 7e' application listenin1 for 4TT& re=uests. This entr# point is intended to
'e exposed to clients. 3ther entr# points, such as internal entr# points exposed '#
su'components across the tiers of #our application, ma# onl# exist to support internal
communication with other components. 4owe+er, #ou should now where these are, and what
t#pes of input the# recei+e in case an attacer mana1es to '#pass the front door of the application
and directl# attac an internal entr# point.
>or each entr# point, #ou should 'e a'le to determine the t#pes of 1ateeepers that pro+ide
authori2ation and the de1ree of +alidation.
*o1ical application entr# points include user interfaces pro+ide '# 7e' pa1es, ser+ice interfaces
pro+ided '# 7e' ser+ices, ser+iced components, and .6%T $emotin1 components and messa1e
=ueues that pro+ide as#nchronous entr# points. &h#sical or platform entr# points include ports
and socets.
Identi&y /rivileged Code
&ri+ile1ed code accesses specific t#pes of secure resources and performs other pri+ile1ed
operations. !ecure resource t#pes include D6! ser+ers, director# ser+ices, en+ironment
+aria'les, e+ent lo1s, file s#stems, messa1e =ueues, performance counters, printers, the re1istr#,
socets, and 7e' ser+ices. !ecure operations include unmana1ed code calls, reflection,
seriali2ation, code access securit# permissions, and manipulation of code access securit# polic#,
includin1 e+idence.
&ri+ile1ed code must 'e 1ranted the appropriate code access securit# permissions '# code access
securit# polic#. &ri+ile1ed code must ensure that the resources and operations that it encapsulates
are not exposed to untrusted and potentiall# malicious code. .6%T >ramewor code access
securit# +erifies the permissions 1ranted to callin1 code '# performin1 stac wals. 4owe+er, it
is sometimes necessar# to o+erride this 'eha+ior and short@circuit the full stac wal, for
example, when #ou want to restrict pri+ile1ed code with a sand'ox or otherwise isolate
pri+ile1ed code. Doin1 so opens #our code up to lurin1 attacs, where malicious code calls #our
code throu1h trusted intermediar# code.
7hene+er #ou o+erride the default securit# 'eha+ior pro+ided '# code access securit#, do it
dili1entl# and with the appropriate safe1uards. >or more information a'out re+iewin1 code for
securit# flaws, see Chapter 2?, -Code $e+iew.- >or more information a'out code access securit#,
see Chapter M, -Code Access !ecurit# in &ractice- and Chapter O, -5sin1 Code Access !ecurit#
with A!&.6%T.-
*ocument the Security /ro&ile
6ext, #ou should identif# the desi1n and implementation approaches used for input +alidation,
authentication, authori2ation, confi1uration mana1ement, and the remainin1 areas where
applications are most suscepti'le to +ulnera'ilities. 9# doin1 this, #ou create a securit# profile
for the application.
The followin1 ta'le shows what inds of =uestions to as while anal#2in1 each aspect of the
desi1n and implementation of #our application. >or more information a'out re+iewin1
application architecture and desi1n, see Chapter L, -Architecture and Desi1n $e+iew.-
Table =-, Creating a Security /ro&ile
Category Considerations
0nput +alidation
0s all input data +alidatedG
Could an attacer in<ect commands or malicious data into the applicationG
0s data +alidated as it is passed 'etween separate trust 'oundaries A'# the
recipient entr# pointCG
Can data in the data'ase 'e trustedG
Authentication
Are credentials secured if the# are passed o+er the networG
Are stron1 account policies usedG
Are stron1 passwords enforcedG
Are #ou usin1 certificatesG
Are password +erifiers Ausin1 one@wa# hashesC used for user passwordsG
Authori2ation 7hat 1ateeepers are used at the entr# points of the applicationG
4ow is authori2ation enforced at the data'aseG
0s a defense in depth strate1# usedG
Do #ou fail securel# and onl# allow access upon successful confirmation of
credentialsG
Confi1uration
mana1ement
7hat administration interfaces does the application supportG
4ow are the# securedG
4ow is remote administration securedG
7hat confi1uration stores are used and how are the# securedG
!ensiti+e data
7hat sensiti+e data is handled '# the applicationG
4ow is it secured o+er the networ and in persistent storesG
7hat t#pe of encr#ption is used and how are encr#ption e#s securedG
!ession
mana1ement
4ow are session cooies 1eneratedG
4ow are the# secured to pre+ent session hi<acin1G
4ow is persistent session state securedG
4ow is session state secured as it crosses the networG
4ow does the application authenticate with the session storeG
Are credentials passed o+er the wire and are the# maintained '# the
applicationG 0f so, how are the# securedG
Cr#pto1raph#
7hat al1orithms and cr#pto1raphic techni=ues are usedG
4ow lon1 are encr#ption e#s and how are the# securedG
Does the application put its own encr#ption into actionG
4ow often are e#s rec#cledG
&arameter
manipulation
Does the application detect tampered parametersG
Does it +alidate all parameters in form fields, +iew state, cooie data, and
4TT& headersG
%xception
mana1ement
4ow does the application handle error conditionsG
Are exceptions e+er allowed to propa1ate 'ac to the clientG
Are 1eneric error messa1es that do not contain exploita'le information
usedG
Auditin1 and
lo11in1
Does #our application audit acti+it# across all tiers on all ser+ersG
4ow are lo1 files securedG
Step ?- Identi&y the Threats
0n this step, #ou identif# threats that mi1ht affect #our s#stem and compromise #our assets. To
conduct this identification process, 'rin1 mem'ers of the de+elopment and test teams to1ether to
conduct an informed 'rainstormin1 session in front of a white'oard. This is a simple #et
effecti+e wa# to identif# potential threats. 0deall#, the team consists of application architects,
securit# professionals, de+elopers, testers, and s#stem administrators.
;ou can use two 'asic approaches:
$se ST0I*( to identi&y threats. Consider the 'road cate1ories of threats, such as spoofin1,
tamperin1, and denial of ser+ice, and use the !T$0D% model from Chapter 2, -Threats
and Countermeasures- to as =uestions in relation to each aspect of the architecture and
desi1n of #our application. This is a 1oal@'ased approach where #ou consider the 1oals of
an attacer. >or example, could an attacer spoof an identit# to access #our ser+er or 7e'
applicationG Could someone tamper with data o+er the networ or in a storeG Could
someone den# ser+iceG
$se categori4ed threat lists. 7ith this approach, #ou start with a laundr# list of common
threats 1rouped '# networ, host, and application cate1ories. 6ext, appl# the threat list to
#our own application architecture and an# +ulnera'ilities #ou ha+e identified earlier in
the process. ;ou will 'e a'le to rule some threats out immediatel# 'ecause the# do not
appl# to #our scenario.
5se the followin1 resources to help #ou with the threat identification process:
>or a list of threats or1ani2ed '# networ, host, and application la#ers, as well as
explanations of the threats and associated countermeasures, see Chapter 2, -Threats and
Countermeasures.-
>or a list of threats '# technolo1#, see -Threats and Countermeasures- at the 'e1innin1 of
each of the -9uildin1- chapters in &art 000 of this 1uide.
Durin1 this step, #ou perform the followin1 tass:
Identi&y network threats.
Identity host threats.
Identi&y application threats.
Identi&y 1etwork Threats
This is a tas for networ desi1ners and administrators. Anal#2e the networ topolo1# and the
flow of data pacets, to1ether with router, firewall, and switch confi1urations, and loo for
potential +ulnera'ilities. Also pa# attention to +irtual pri+ate networ A"&6C endpoints. $e+iew
the networ defenses a1ainst the most common networ la#er threats identified in Chapter 2,
-Threats and Countermeasures.-
Top networ threats to consider durin1 the desi1n phase include:
5sin1 securit# mechanisms that rel# on the 0& address of the sender. 0t is relati+el# eas# to
send 0& pacets with false source 0& addresses A0& spoofin1C.
&assin1 session identifiers or cooies o+er unencr#pted networ channels. This can lead to 0&
session hi<acin1.
&assin1 clear text authentication credentials or other sensiti+e data o+er unencr#pted
communication channels. This could allow an attacer to monitor the networ, o'tain
lo1on credentials, or o'tain and possi'l# tamper with other sensiti+e data items.
;ou must also ensure that #our networ is not +ulnera'le to threats arisin1 from insecure de+ice
and ser+er confi1uration. >or example, are unnecessar# ports and protocols closed and disa'ledG
Are routin1 ta'les and D6! ser+er securedG Are the TC& networ stacs hardened on #our
ser+ersG >or more information a'out pre+entin1 this t#pe of +ulnera'ilit#, see Chapter ?L,
-!ecurin1 ;our 6etwor.-
Identi&y #ost Threats
The approach used throu1hout this 1uide when confi1urin1 host securit# Athat is, Microsoft
7indows 2((( or Microsoft 7indows !er+erR 2(() and .6%T >ramewor confi1urationC is to
di+ide the confi1uration into separate cate1ories to allow #ou to appl# securit# settin1s in a
structured and lo1ical manner. This approach is also ideall# suited for re+iewin1 securit#,
spottin1 +ulnera'ilities, and identif#in1 threats. Common confi1uration cate1ories applica'le to
all ser+er roles include patches and updates, ser+ices, protocols, accounts, files and directories,
shares, ports, and auditin1 and lo11in1. >or each cate1or#, identif# potentiall# +ulnera'le
confi1uration settin1s. >rom these, identif# threats.
Top +ulnera'ilities to consider include:
Maintainin1 unpatched ser+ers, which can 'e exploited '# +iruses, Tro<an horses, worms, and
well@nown 00! attacs.
5sin1 nonessential ports, protocols, and ser+ices, which increase the attac profile and
ena'le attacers to 1ather information a'out and exploit #our en+ironment.
Allowin1 unauthenticated anon#mous access.
5sin1 wea passwords and account policies that lead to password cracin1, identit#
spoofin1, and denial of ser+ice attacs if accounts can 'e loced out deli'eratel#.
Identi&y Application Threats
0n the pre+ious steps, #ou defined the architecture, data flow, and trust 'oundaries of #our
application. ;ou also created a securit# profile that descri'es how the application handles core
areas, such as authentication, authori2ation, confi1uration mana1ement, and other areas.
6ow use the 'road !T$0D% threat cate1ories and predefined threat lists to scrutini2e each aspect
of the securit# profile of #our application. >ocus on application threats, technolo1#@specific
threats, and code threats. Ke# +ulnera'ilities to consider include:
5sin1 poor input +alidation that leads to cross@site scriptin1 AB!!C, !E* in<ection, and 'uffer
o+erflow attacs.
&assin1 authentication credentials or authentication cooies o+er unencr#pted networ lins,
which can lead to credential capture or session hi<acin1.
5sin1 wea password and account policies, which can lead to unauthori2ed access.
>ailin1 to secure the confi1uration mana1ement aspects of #our application, includin1
administration interfaces.
!torin1 confi1uration secrets, such as connection strin1s and ser+ice account credentials, in
clear text.
5sin1 o+er@pri+ile1ed process and ser+ice accounts.
5sin1 insecure data access codin1 techni=ues, which can increase the threat posed '# !E*
in<ection.
5sin1 wea or custom encr#ption and failin1 to ade=uatel# secure encr#ption e#s.
$el#in1 on the inte1rit# of parameters that are passed from the 7e' 'rowser, for example,
form fields, =uer# strin1s, cooie data, and 4TT& headers.
5sin1 insecure exception handlin1, which can lead to denial of ser+ice attacs and the
disclosure of s#stem@le+el details that are useful to an attacer.
Doin1 inade=uate auditin1 and lo11in1, which can lead to repudiation threats.
$sing Attack Trees and Attack /atterns
Attac trees and attac patterns are the primar# tools that securit# professionals use. These are
not essential components of the threat identification phase 'ut #ou ma# find them useful. The#
allow #ou to anal#2e threats in 1reater depth, 1oin1 'e#ond what #ou alread# now to identif#
other possi'ilities.
0mportant 7hen #ou use pre+iousl# prepared cate1ori2ed lists of nown threats, it onl#
re+eals the common, nown threats. Additional approaches, such as the use of attac trees
and attac patterns, can help #ou identif# other potential threats.
An attac tree is a wa# of collectin1 and documentin1 the potential attacs on #our s#stem in a
structured and hierarchical manner. The tree structure 1i+es #ou a descripti+e 'readown of
+arious attacs that the attacer uses to compromise the s#stem. 9# creatin1 attac trees, #ou
create a reusa'le representation of securit# issues that helps focus efforts. ;our test team can
create test plans to +alidate securit# desi1n. De+elopers can mae tradeoffs durin1
implementation and architects or de+eloper leads can e+aluate the securit# cost of alternati+e
approaches.
Attac patterns are a formali2ed approach to capturin1 attac information in #our enterprise.
These patterns can help #ou identif# common attac techni=ues.
Creating Attack Trees
7hile se+eral approaches can 'e used in practice, the accepted method is to identif# 1oals and
su'@1oals of an attac, as well as what must 'e done so that the attac succeeds. ;ou can use a
hierarchical dia1ram to represent #our attac tree, or use a simple outline. 7hat is important in
the end is that #ou ha+e somethin1 that portra#s the attac profile of #our application. ;ou can
then e+aluate liel# securit# riss, which #ou can miti1ate with the appropriate countermeasures,
such as correctin1 a desi1n approach, hardenin1 a confi1uration settin1, and other solutions.
!tart 'uildin1 an attac tree '# creatin1 root nodes that represent the 1oals of the attacer. Then
add the leaf nodes, which are the attac methodolo1ies that represent uni=ue attacs. >i1ure ).L
shows a simple example.

+igure =-@
Representation of an attack tree
;ou can la'el leaf nodes with A1* and O0 la'els. >or example, in >i1ure ).L, 'oth ?.? and ?.2
must occur for the threat to result in an attac.
Attac trees lie the one shown a'o+e ha+e a tendenc# to 'ecome complex =uicl#. The# are
also time@consumin1 to create. An alternati+e approach fa+ored '# some teams is to structure
#our attac tree usin1 an outline such as the one shown 'elow.
<a+ascript:Cop#CodeA8ctl((Hrs?Hm
ainContentContainerHctl2)8CF
Cop# Code
1' Noa) 9ne
1'1 Su"A!oa) one
1'O Su"A!oa) t#o
O' Noa) 7#o
O'1 Su"A!oa) one
O'O Su"A!oa) t#o
6ote 0n addition to 1oals and su'@1oals, attac trees include methodolo1ies and re=uired
conditions.
4ere is an example of the outline approach in action:
<a+ascript:Cop#CodeA8ctl((Hrs?HmainContentContainerHctl2I8CF Cop# Code
7hreat P1 2ttac%er o"tains authentication credentia)s "$ monitorin! the
net#or%
1'1 3)ear te*t credentia)s sent over the net#or% AND
1'O 2ttac%er uses net#or%Amonitorin! too)s
1'O'1 2ttac%er reco!nizes credentia) data
>or a complete example, see -!ample Attac Trees- in the -Cheat !heets- section of this 1uide.
Attack /atterns
Attac patterns are 1eneric representations of commonl# occurrin1 attacs that can occur in a
+ariet# of different contexts. The pattern defines the 1oal of the attac as well as the conditions
that must exist for the attac to occur, the steps that are re=uired to perform the attac, and the
results of the attac. Attac patterns focus on attac techni=ues, whereas !T$0D%@'ased
approaches focus on the 1oals of the attacer.
An example of an attac pattern is the code@in<ection attac pattern that is used to descri'e code
in<ection attacs in a 1eneric wa#. Ta'le ).) descri'es the code@in<ection attac pattern.
Table =-= Code In2ection Attack /attern
/attern Code in2ection attacks
Attac 1oals Command or code execution
$e=uired conditions
7ea input +alidation
Code from the attacer has sufficient pri+ile1es on the ser+er.
Attac techni=ue
?.0dentif# pro1ram on tar1et s#stem with an input +alidation +ulnera'ilit#.
2.Create code to in<ect and run usin1 the securit# context of the tar1et
application.
).Construct input +alue to insert code into the address space of the tar1et
application and force a stac corruption that causes application execution
to <ump to the in<ected code.
Attac results Code from the attacer runs and performs malicious action.
>or more information a'out attac patterns, see the -Additional $esources- section at the end of
this chapter.
Step @- *ocument the Threats
To document the threats of #our application, use a template that shows se+eral threat attri'utes
similar to the one 'elow. The threat description and threat tar1et are essential attri'utes. *ea+e
the ris ratin1 'lan at this sta1e. This is used in the final sta1e of the threat modelin1 process
when #ou prioriti2e the identified threat list. 3ther attri'utes #ou ma# want to include are the
attac techni=ues, which can also hi1hli1ht the +ulnera'ilities exploited, and the
countermeasures that are re=uired to address the threat.
Table =-? Threat .
Threat *escription
Attacker obtains authentication credentials by monitoring the
network
Threat tar1et 7e' application user authentication process
$is
Attac techni=ues 5se of networ monitorin1 software
Countermeasures 5se !!* to pro+ide encr#pted channel
Table =-@ Threat ,
Threat *escription In2ection o& S76 commands
Threat tar1et Data access component
$is
Attac techni=ues
Attacer appends !E* commands to user name, which is used to form a
!E* =uer#
Countermeasures
5se a re1ular expression to +alidate the user name, and use a stored
procedure that uses parameters to access the data'ase.
Step A- 0ate the Threats
At this sta1e in the process, #ou ha+e a list of threats that appl# to #our particular application
scenario. 0n the final step of the process, #ou rate threats 'ased on the riss the# pose. This
allows #ou to address the threats that present the most ris first, and then resol+e the other
threats. 0n fact, it ma# not 'e economicall# +ia'le to address all of the identified threats, and #ou
ma# decide to i1nore some 'ecause of the chance of them occurrin1 is small and the dama1e that
would result if the# did is minimal.
0isk B /robability C *amage /otential
This formula indicates that the ris posed '# a particular threat is e=ual to the pro'a'ilit# of the
threat occurrin1 multiplied '# the dama1e potential, which indicates the conse=uences to #our
s#stem if an attac were to occur.
;ou can use a ??( scale for pro'a'ilit# where ? represents a threat that is +er# unliel# to occur
and ?( represents a near certaint#. !imilarl#, #ou can use a ??( scale for dama1e potential
where ? indicates minimal dama1e and ?( represents a catastrophe. 5sin1 this approach, the ris
posed '# a threat with a low lielihood of occurrin1 'ut with hi1h dama1e potential is e=ual to
the ris posed '# a threat with limited dama1e potential 'ut that is extremel# liel# to occur.
>or example, if /robabilityP?( and *amage /otentialP?, then $is P ?( S ? P ?(. 0f
/robabilityP? and *amage /otentialP?(, then $is P ? S ?( P ?(.
This approach results in a scale of ??((, and #ou can di+ide the scale into three 'ands to
1enerate a 4i1h, Medium, or *ow ris ratin1.
#igh' )edium' and 6ow 0atings
;ou can use a simple 4i1h, Medium, or *ow scale to prioriti2e threats. 0f a threat is rated as
4i1h, it poses a si1nificant ris to #our application and needs to 'e addressed as soon as possi'le.
Medium threats need to 'e addressed, 'ut with less ur1enc#. ;ou ma# decide to i1nore low
threats dependin1 upon how much effort and cost is re=uired to address the threat.
*0(A*
The pro'lem with a simplistic ratin1 s#stem is that team mem'ers usuall# will not a1ree on
ratin1s. To help sol+e this, add new dimensions that help determine what the impact of a securit#
threat reall# means. At Microsoft, the D$%AD model is used to help calculate ris. 9# usin1 the
D$%AD model, #ou arri+e at the ris ratin1 for a 1i+en threat '# asin1 the followin1 =uestions:
*ama1e potential: 4ow 1reat is the dama1e if the +ulnera'ilit# is exploitedG
0eproduci'ilit#: 4ow eas# is it to reproduce the attacG
(xploita'ilit#: 4ow eas# is it to launch an attacG
Affected users: As a rou1h percenta1e, how man# users are affectedG
*isco+era'ilit#: 4ow eas# is it to find the +ulnera'ilit#G
;ou can use a'o+e items to rate each threat. ;ou can also extend the a'o+e =uestions to meet
#our needs. >or example, #ou could add a =uestion a'out potential reputation dama1e:
0eputation: 4ow hi1h are the staesG 0s there a ris to reputation, which could lead to the loss
of customer trustG
$atin1s do not ha+e to use a lar1e scale 'ecause this maes it difficult to rate threats consistentl#
alon1side one another. ;ou can use a simple scheme such as 4i1h A?C, Medium A2C, and *ow A)C.
7hen #ou clearl# define what each +alue represents for #our ratin1 s#stem, it helps a+oids
confusion. Ta'le )., shows a t#pical example of a ratin1 ta'le that can 'e used '# team mem'ers
when prioriti2in1 threats.
Table =-A Thread 0ating Table
0ating #igh =" )edium ," 6ow ."
D
Dama1e
potential
The attacer can su'+ert
the securit# s#stemF 1et
full trust authori2ationF
run as administratorF
upload content.
*eain1 sensiti+e
information
*eain1 tri+ial
information
$ $eproduci'ilit#
The attac can 'e
reproduced e+er# time
and does not re=uire a
timin1 window.
The attac can 'e
reproduced, 'ut onl#
with a timin1 window
and a particular race
situation.
The attac is +er#
difficult to reproduce,
e+en with nowled1e of
the securit# hole.
% %xploita'ilit#
A no+ice pro1rammer
could mae the attac in a
short time.
A silled pro1rammer
could mae the attac,
then repeat the steps.
The attac re=uires an
extremel# silled person
and in@depth nowled1e
e+er# time to exploit.
A Affected users
All users, default
confi1uration, e#
customers
!ome users, non@default
confi1uration
"er# small percenta1e of
users, o'scure featureF
affects anon#mous users
D Disco+era'ilit# &u'lished information
explains the attac. The
+ulnera'ilit# is found in
the most commonl# used
feature and is +er#
noticea'le.
The +ulnera'ilit# is in a
seldom@used part of the
product, and onl# a few
users should come
across it. 0t would tae
some thinin1 to see
The 'u1 is o'scure, and
it is unliel# that users
will wor out dama1e
potential.
malicious use.
After #ou as the a'o+e =uestions, count the +alues A?)C for a 1i+en threat. The result can fall in
the ran1e of L?L. Then #ou can treat threats with o+erall ratin1s of ?2?L as 4i1h ris, M?? as
Medium ris, and LN as *ow ris.
>or example, consider the two threats descri'ed earlier:
Attacer o'tains authentication credentials '# monitorin1 the networ.
!E* commands in<ected into application.
Ta'le ).N shows an example D$%AD ratin1 for 'oth threats:
Table =-D *0(A* rating
Threat * 0 ( A * Total 0ating
Attacer o'tains authentication
credentials '# monitorin1 the networ.
) ) 2 2 2 ?2 4i1h
!E* commands in<ected into application. ) ) ) ) 2 ?I 4i1h
3nce #ou ha+e o'tained the ris ratin1, #ou update the documented threats and add the
disco+ered ratin1 le+el, which is 4i1h for 'oth of the a'o+e threats. Ta'le ).M shows an example.
Table =-E Threat .
Threat *escription
Attacker obtains authentication credentials by monitoring the
network
Threat tar1et 7e' application user authentication process
$is ratin1 4i1h
Attac techni=ues 5se of networ monitorin1 software
Countermeasures 5se !!* to pro+ide encr#pted channel
What Comes A&ter Threat )odelingF
The output of the threat modelin1 process includes documentation of the securit# aspects of the
architecture of #our application and a list of rated threats. The threat model helps #ou orchestrate
de+elopment team mem'ers and focus on the most potent threats.
0mportant Threat modelin1 is an iterati+e process. The threat model is a document that
e+ol+es and that +arious team mem'ers can wor from.
The threat model can 'e used '# the followin1 1roups of people:
Desi1ners can use it to mae secure desi1n choices a'out technolo1ies and functionalit#.
De+elopers who write code can use it to miti1ate riss.
Testers can write test cases to test if the application is +ulnera'le to the threats identified '#
the anal#sis.
3enerating a Work Item 0eport
>rom the initial threat model, #ou can create a more formali2ed wor item report that can include
additional attri'utes, such as a 9u1 0D, which can 'e used to tie the threat in with #our fa+orite
'u1 tracin1 s#stem. 0n fact, #ou ma# choose to enter the identified threats in #our 'u1 tracin1
s#stem and use its reportin1 facilities to 1enerate the report. ;ou can also include a status column
to indicate whether or not the 'u1 has 'een fixed. ;ou should mae sure the report includes the
ori1inal threat num'er to tie it 'ac to the threat model document.
3r1ani2e the threats in the report '# networ, host, and application cate1ories. This maes the
report easier to consume for different team mem'ers in different roles. 7ithin each cate1or#,
present the threats in prioriti2ed order startin1 with the ones 1i+en a hi1h ris ratin1 followed '#
the threats that present less ris.
Summary
7hile #ou can miti1ate the ris of an attac, #ou do not miti1ate or eliminate the actual threat.
Threats still exist re1ardless of the securit# actions #ou tae and the countermeasures #ou appl#.
The realit# in the securit# world is that #ou acnowled1e the presence of threats and #ou mana1e
#our riss. Threat modelin1 can help #ou mana1e and communicate securit# riss across #our
team.
Treat threat modelin1 as an iterati+e process. ;our threat model should 'e a d#namic item that
chan1es o+er time to cater to new t#pes of threats and attacs as the# are disco+ered. 0t should
also 'e capa'le of adaptin1 to follow the natural e+olution of #our application as it is enhanced
and modified to accommodate chan1in1 'usiness re=uirements.
Additional 0esources
>or additional related readin1, see the followin1 resources:
>or more information a'out the latest threat modelin1 process, see -Threat Modelin1 7e'
Applications-
>or information on attac patterns, see -Attac Modelin1 for 0nformation !ecurit# and
!ur+i+a'ilit#,- '# Andrew &. Moore, $o'ert J. %llison, and $ichard C. *in1er at
http://www.cert.or1/archi+e/pdf/(?tn((?.pdf
>or information on e+aluatin1 threats, assets and +ulnera'ilities, see -3perationall# Critical
Threat, Asset, and "ulnera'ilit# %+aluation A3CTA"%C >ramewor, "ersion ?.(- on the
Carne1ie Mellon !oftware %n1ineerin1 0nstitute 7e' site at
http://www.sei.cmu.edu/pu'lications/documents/OO.reports/OOtr(?N/OOtr(?Nfi1ures.html
>or a walthrou1h of threat modelin1, see -Architect 7e'Cast: 5sin1 Threat Models to
Desi1n !ecure !olutions- at http://www.microsoft.com/usa/we'casts/ondemand/?,?N.asp
>or more information on creatin1 D>Ds, see Writing Secure Code! Second Edition, '#
Michael 4oward, Da+id C. *e9lanc.