O

About OWASP
Foreword
Insecure software is undermining our financial,
healthcare, defense, energy, and other critical
infrastructure. As our digital infrastructure gets
increasingly complex and interconnected, the
dificulty of achieving application security
increases exponentially. We can no longer afford
to tolerate relatively simple security problems
like those presented in this OWA! "op #$.
"he goal of the "op #$ pro%ect is to raise
awareness about application security by
identifying some of the most critical risks
facing organi&ations. "he "op #$ pro%ect is
referenced
by many standards, books, tools, and
organi&ations, including 'I"(), !*I +, +IA,
,"*, and m a n y mor e . "his release of the OWA!
"op #$ marks this pro%ect-s tenth anniversary of
raising awareness of the importance of
application security risks. "he OWA! "op #$ was
first released in .$$/, with minor updates in
.$$0 and .$$1. "he .$#$ version was revamped
to prioriti&e by risk, not %ust prevalence. "his
.$#/ edition follows the same approach.
We encourage you to use the "op #$ to get your
organi&ation s ta rted with application security.
+evelopers can learn from the mistakes of other
organi&ations. )xecutives should start thinking
about how to manage the risk that software
applications create in their enterprise.
In the long term, we encourage you to create an
application security program that is compatible
with your culture and technology. "hese
programs come in all shapes and si&es,
and you should avoid attempting to do
everything prescribed by some process model.
Instead, leverage your
organi&ation-s existing strengths to do and
measure what
works for you.
We hope that the OWA! "op #$ is useful to your
application security eforts. !lease don-t hesitate
to contact OWA! with your 2uestions,
comments, and ideas, either publicly to
o w as p 3top te n 4 lis ts .o w asp.org or
privately to d a ve .w icher s 4o w asp.o r g .
About OWASP
"he Open Web Application ecurity !ro%ect
5OWA!6 is an open community dedicated to
enabling organi&ations to develop, purchase,
and maintain applications that can be
trusted. At OWA! you-ll find free and open
7
Application security tools and standards
*omplete books on application security
testing, secure
code development, and secure code review
tandard security controls and libraries
8o cal ch ap ters world wid e
*utting edge research
) xten sive conferen ces world wide
'ailin g lists
8earn more at9 h ttp s 9::www .o w asp.o rg
All of the OWA! tools, documents, forums, and
chapters are free and open to anyone
interested in improving application security. We
advocate approaching application security as a
people, process, and technology problem,
because the most efective approaches to
application security re2uire improvements in all
of these areas.
OWA! is a new kind of organi&ation. Our freedom
from commercial pressures allows us to provide
unbiased, practical, cost3efective information
about application security. OWA!
is not affiliated with any technology company,
although we support the informed use of
commercial security technology. imilar to many
open source software pro%ects, OWA! produces
many types of materials in a collaborative, open
way.
"he OWA! ,oundation is the non3profit entity
that ensures the pro%ect-s long3term success.
Almost everyone associated with OWA! is a
volunteer, including the OWA! ;oard, <lobal
*ommittees, *hapter 8eaders, !ro%ect 8eaders,
and pro%ect members. We support innovative
security research with grants and infrastructure.
*ome %oin us=
Copyright and License
*opyright > .$$/ ? .$#/ "he OWA! ,oundation
"his document is released under the *reative *ommons Attribution hareAlike /.$
license. ,or any reuse
or distribution, you must make it clear to others the license terms of this work.
I
Introduction
Welcome
Welcome to the OWA! "op #$ .$#/= "his update broadens one of the categories from the .$#$
version to be more inclusive of common, important vulnerabilities, and reorders some of the others
based on changing prevalence data. It also brings component security into the spotlight by creating a
specific category for this risk, pulling it out of the obscurity of the fine print of the .$#$ risk A@9 ecurity
'isconfiguration.
"he OWA! "op #$ for .$#/ is based on A datasets from 1 firms that speciali&e in application
security, including 0 consulting companies and / tool:aa vendors 5# static, # dynamic, and # with
both6. "his data spans over B$$,$$$ vulnerabilities across hundreds of organi&ations and thousands
of applications. "he "op #$ items are selected and prioriti&ed according to this prevalence data, in
combination with consensus estimates of exploitability, detectability, and impact estimates.
"he primary aim of the OWA! "op #$ is to educate developers, designers, architects, managers,
and organi&ations about the conse2uences of the most important web application security
weaknesses. "he "op #$ provides basic techni2ues to protect against these high risk problem areas
? and also provides guidance on where to go from here.
Warnings
Dont stop at !. "here are hundreds of issues
that could affect the overall security of a web
application as discussed in the OW A ! + eve lop
e r-s < u ide and the OW A ! * h e at h ee t e ri es .
"hese are essential reading for anyone
developing
web applications. <uidance on how to
efectively find vulnerabilities in web
applications is provided in the OWA! "es ti n g
< u id e and the OWA! *o d e (e v ie w < u ide .
Constant change. "his "op #$ will continue to
change. )ven without changing a single line of
your application-s code, you may become
vulnerable as new Caws are discovered and
attack methods are refined. !lease review the
advice at the end of the "op #$ in DWhat-s Eext
,or +evelopers, Ferifiers, and Organi&ationsG for
more information.
"hin# positi$e. When you-re ready to stop
chasing vulnerabilities and focus on
establishing strong application security
controls, OWA! has produced the A pp lica t ion
e c u rity F e ri ficati o n t and ard 5A F6 as a
guide to organi&ations and application
reviewers on what to verify.
%se tools wisely. ecurity vulnerabilities can
be 2uite complex and buried in mountains of
code. In many cases, the most cost3efective
approach for finding and eliminating these
weaknesses is human experts armed with good
tools.
Push le&t. ,ocus on making security an integral
part of your culture throughout your development
organi&ation. ,ind out more in the O p e n o ftware
A ss u ra n ce 'a tu rity ' od e l 5 A ''6 and the
( u gg e d H a ndb oo k .
Attribution
"hanks to A s p e ct e c u rity for initiating,
leading, and updating the OWA! "op #$ since
its inception in .$$/, and to its primary authors9
Ieff Williams and +ave Wichers.
We-d like to thank those organi&ations that
contributed their vulnerability prevalence data
to support the .$#/ update9
A s p e ct e c u rity ? t a ti s tics
H ! ? ta tistics from both ,ortify and
WebInspect
'ind ed ecu rity ? ta tistics
ofttek ? ta tistics
"rustwave, pider8ab s ? tatistics 5ee
page B$6
Feracod e ? ta tistics
Wh iteHa t ecu rity In c. ? ta tistics
We would like to thank everyone who contributed
to previous versions of the "op #$. Without these
contributions, it
wouldn-t be what it is today. We-d also like to
thank those who contributed significant
constructive comments and time reviewing this
update to the "op #$9
Adam ;aso 5Wikimedia ,oundation6
'ike ;oberski 5;oo& Allen Hamilton6
"orsten <igler
Eeil mithline ? 5'orpho"rust JA6 ,or
producing the
wiki version of the "op #$, and also providing
feedback
And finally, we-d like to thank in advance all the
translators out there that will translate this release
of the "op #$ into numerous diferent languages,
helping to make the OWA!
"op #$ more accessible to the entire planet.
'(
'elease (otes
What Changed From )!! to )!*+
"he threat landscape for applications security constantly changes. Key factors in this evolution are
advances made by attackers, the release of new technologies with new weaknesses as well as more
built in defenses, and the deployment of increasingly complex systems. "o keep pace, we periodically
update the OWA! "op #$. In this .$#/ release, we made the following changes9
#6 ;roken Authentication and ession 'anagement moved up in prevalence based on our data set.
We believe this is probably because this area is being looked at harder, not because these issues
are actually more prevalent. "his caused (isks A. and A/ to switch places.
.6 *ross3ite (e2uest ,orgery 5*(,6 moved down in prevalence based on our data set from .$#$3
AB to .$#/3AA. We believe this is because *(, has been in the OWA! "op #$ for @ years, and
organi&ations and framework developers have focused on it enough to signiLcantly reduce the
number of *(, vulnerabilities in real world applications.
/6 We broadened ,ailure to (estrict J(8 Access from the .$#$ OWA! "op #$ to be more inclusive9
M .$#$3AA9 ,ailure to (estrict J(8 Access is now .$#/ 3A19 'i ss in g , un ction 8 eve l Acc es s *o n tr o l ?
to cover all of function level access control. "here are many ways to specify which function is
being accessed, not %ust the J(8.
06 We merged and broadened .$#$3A1 N .$#$3AO to *()A")9 .$#/ 3A@9 e n s iti v e +a t a ) x p o s u r e 9
? "his new category was created by merging .$#$3A1 ? Insecure *ryptographic torage N .$#$3
AO 3 Insuficient "ransport
8ayer !rotection, plus adding browser side sensitive data risks as well. "his new category covers
sensitive data
protection 5other than access control which is covered by .$#/3A0 and .$#/3A16 from the
moment sensitive data is
provided by the user, sent to and stored within the application, and then sent back to the browser
again.
B6 We added9 .$#/ 3AO9 Js in g K n o w n F u ln e ra b le *o m p o n e n ts 9
M "his issue was mentioned as part of .$#$3A@ ? ecurity 'isconfiguration, but now has a
category of its own as the growth and depth of component based development has
signiLcantly increased the risk of using known vulnerable components.
OWASP "op ! , )!! -Pre$ious. OWASP "op
! , )!* -(ew.
A , In/ection A , In/ection
A* , 0ro#en Authentication and Session 1anagement A) , 0ro#en Authentication
and Session 1anagement
A) , Cross2Site Scripting -3SS. A* , Cross2Site
Scripting -3SS.
A4 , Insecure Direct Ob/ect 'e&erences A4 , Insecure Direct
Ob/ect 'e&erences
A5 , Security 1iscon&iguration A6 , Security
1iscon&iguration
A7 , Insecure Cryptographic Storage , 1erged with A8 A5 , Sensiti$e Data 9:posure
A; , Failure to 'estrict %'L Access , 0roadened into A7 , 1issing Function Le$el
Access Control
A6 , Cross2Site 'e<uest Forgery -CS'F. A; , Cross2Site 'e<uest
Forgery -CS'F.
=buried in A5> Security 1iscon&iguration? A8 , %sing @nown
Aulnerable Components
A! , %n$alidated 'edirects and Forwards A! , %n$alidated
'edirects and Forwards
A8 , Insu&Bcient "ransport Layer Protection 1erged with )!!2A7 into
new )!*2A5
'is
#
pplication Security
'is#s
What Are Application Security 'is#s+
Attackers can potentially use many diferent paths through your application to do harm to your business
or organi&ation. )ach of these paths represents a risk that may, or may not, be serious enough to
warrant attention.
"hreat Attac# Security Securi
ty
"echnical 0usin
ess
Agents Aectors Wea#ness
es
Contro
ls
Impacts Impac
ts
Attac#
Wea#ne
ss
Contr
ol
Impact
Attac#
Attac#
Wea#ne
ss
Wea#ne
ss
Contr
ol
Asse
t
Functi
on
Asse
t
Impact
Impact
Wea#ness
ontro
ometimes, these paths are trivial to find and exploit and sometimes they are extremely dificult.
imilarly, the harm that is caused may be of no conse2uence, or it may put you out of business. "o
determine the risk to your organi&ation, you can evaluate the likelihood associated with each threat
agent, attack vector, and security weakness and combine it with an estimate of the technical and
business impact to your organi&ation. "ogether, these factors determine the overall risk.
l
C
Whats 1y 'is#+
"he OWA! " op #$ focuses on identifying the most serious risks for
a broad array of organi&ations. ,or each of these risks, we provide
generic information about likelihood and technical impact using the
following simple ratings scheme, which is based on the OWA! (i s k
(a t in g 'et h o d olog y .
'e&erences
OWASP
OWA! (i s k (a t in g
' e th o d o logy
Article o n "hr e a t :(i s k ' od e ling
9:ternal
,AI( In forma t ion (i s k ,ram ew o rk
'icro s o ft " h r e at 'o d e ling 5 " (I+)
an d +() A+6
O n ly y ou know the specifics of your environment and your
business. ,or any given application, there may not be a threat
agent that can perform the relevant attack, or the technical
impact may not make any diference to your business. "herefore,
you should evaluate each risk for y o u r se lf , focusing on the threat
agents, security controls, and business impacts in your enterprise.
We list "hreat Agents as Application pecific, and ;usiness
Impacts as Application : ;usiness pecific to indicate these are
clearly dependent on the details about your application in your
enterprise.
"he names of the risks in the "op #$ stem from the type of
attack, the type of weakness, or the type of impact they cause.
We chose names that accurately
reflect the risks and, where possible, align with common
terminology most likely to raise awareness.
"
!
OWASP "op !
Application
ecurity 'is#s ,
)!*
A ,
In/ection
In%ection Caws, such as P8, O, and 8+A! in%ection occur when untrusted
data is sent to an interpreter as part of a command or 2uery. "he attacker-s
hostile data can trick the interpreter into executing unintended commands or
accessing data without proper authori&ation.
A) , 0ro#en
Authenticatio
n and Session
1anagement
Application functions related to authentication and session management are
often not implemented correctly, allowing attackers to compromise passwords,
keys, or session tokens, or to exploit other implementation Caws to assume
other users- identities.
A* , Cross2
Site
Scripting
-3SS.
Q flaws occur whenever an application takes untrusted data and sends it to
a web browser without proper validation or escaping. Q allows attackers to
execute scripts in the victim-s browser which can hi%ack user sessions, deface
web sites, or redirect the user to malicious sites.
A4 , Insecure Direct Ob/ect 'e&erences
"hreat
Agents
Attac#
Aectors
Wea#nes
s
Pre$alenc
Wea#nes
s
Detectabil
"echnica
l
Impacts
0usines
s
Impacts
App
Speci&
ic
)asy Widesprea
d
)asy evere
App C
0usine
ss
Speci&i
Average *ommon Average 'oderate
+iRcult Jncommon +iRcult 'inor
A
A direct ob%ect
reference occurs
when a developer
exposes a reference to an internal implementation ob%ect, such as a file,
directory, or database key. Without an access control check or other protection,
attackers can manipulate these references to access unauthori&ed data.
A6 ,
Security
1isconBgura
tion
<ood security re2uires having a secure configuration defined and deployed
for the application, frameworks, application server, web server, database
server, and platform. ecure settings should be defined, implemented, and
maintained, as defaults are often insecure. Additionally, software should be
kept up to date.
A5 , Sensiti$e
Data
9:posu
re
'any web applications do not properly protect sensitive data, such as credit
cards, tax I+s, and authentication credentials. Attackers may steal or modify
such weakly protected data to conduct credit card fraud, identity theft, or other
crimes. ensitive data deserves extra protection such as encryption at rest or
in transit, as well as special precautions when exchanged with the browser.
A7 ,
1issing
Function
Le$el
Access
Control
'ost web applications verify function level access rights before making that
functionality visible in the JI. However, applications need to perform the same
access control checks on the server when each function is accessed. If
re2uests are not verified, attackers will be able to forge re2uests in order to
access functionality without proper authori&ation.
A; 2 Cross2
Site
'e<uest
Forgery
-CS'F.
A *(, attack forces a logged3on victim-s browser to send a forged H""!
re2uest, including the victim-s session cookie and any other automatically
included authentication information, to a vulnerable web application. "his
allows the attacker to force the victim-s browser to generate re2uests the
vulnerable application thinks are legitimate re2uests from the victim.
A8 2 %sing
Components
with @nown
Aulnerabilitie
s
*omponents, such as libraries, frameworks, and other software modules,
almost always run with full privileges. If a vulnerable component is exploited,
such an attack can facilitate serious data loss or server takeover. Applications
using components with known vulnerabilities may undermine application
defenses and enable a range of possible attacks and impacts.
A! ,
%n$alidated
'edirects and
Forwards
Web applications fre2uently redirect and forward users to other pages and
websites, and use untrusted data to determine the destination pages.
Without proper validation, attackers can redirect victims to phishing or
malware sites, or use forwards to access unauthori&ed pages.
S
A
In/ection
"hre
at
Agen
ts
Attac
#
Aecto
rs
Securi
ty
Wea#ne
ss
"echnic
al
Impac
ts
0usiness
Impacts
Application Speci&ic
9:ploitability
9ASD
Pre$ale
nce
CO11O
(
Detectabi
lity
AA9'A
E9
Impa
ct
S9A9
'9
Applicatio
n C 0usiness
Speci&ic
*onsider
anyone who
can send
untrusted
data to the
system,
including
external
users, internal
users, and
administrators
.
Attacker sends
simple text3
based attacks
that exploit the
syntax of the
targeted
interpreter.
Almost any
source of data
can be an
in%ection
vector,
including
internal
sources.
In %e c ti o n Ca w s occur when an
application sends untrusted data
to an interpreter. In%ection Caws
are very prevalent, particularly in
legacy code. "hey are often
found in P8, 8+A!, Qpath, or
EoP8 2ueriesS O commandsS
Q'8 parsers,
'"! Headers, program
arguments, etc. In%ection Caws
are easy to discover when
examining code, but fre2uently
hard to discover via testing.
canners and fu&&ers can help
attackers Lnd in%ection Caws.
In%ection can
result in data
loss or
corruption, lack
of
accountability,
or denial of
access.
In%ection can
sometimes
lead to
complete host
takeover.
*onsider the
business value
of the afected
data and the
platform
running the
interpreter. All
data could be
stolen,
modified, or
deleted. *ould
your
reputation be
harmedT
Am I Aulnerable "o
In/ection+
"he best way to find out if an application is
vulnerable to in%ection is to verify that all use
of interpreters clearly separates untrusted data
from the command or 2uery. ,or P8 calls, this
means using bind variables in all prepared
statements and stored procedures, and
avoiding dynamic 2ueries.
*hecking the code is a fast and accurate way to
see if the application uses interpreters safely.
*ode analysis tools can help a security analyst
find the use of interpreters and trace the data
flow through the application. !enetration testers
can validate these issues by crafting exploits that
confirm the vulnerability.
Automated dynamic scanning which exercises
the application may provide insight into whether
some exploitable in%ection flaws exist. canners
cannot always reach interpreters and have
dificulty detecting whether an attack was
successful. !oor error handling makes in%ection
flaws easier to discover.
Fow Do I Pre$ent In/ection+
!reventing in%ection re2uires keeping
untrusted data separate from commands
and 2ueries.
#. "he preferred option is to use a safe A!I which
avoids the use of the interpreter entirely or
provides a parameteri&ed interface. ;e
careful with A!Is, such as stored procedures,
that are parameteri&ed, but can still introduce
in%ection under the hood.
.. If a parameteri&ed A!I is not available,
you should carefully escape special
characters using the specific escape
syntax for that interpreter. OWA!- s )
A!I provides many of these es ca p in g
r ou ti n e s .
/. !ositive or Dwhite listG input validation is also
recommended, but is n ot a complete defense
as many applications re2uire special
characters in their input. If special characters
are re2uired, only approaches #. and .. above
will make their use safe. OWA!- s ) A!I
has an extensible library of w h ite li s t inpu t
v ali d a t ion r ou ti n e s .
9:ample Attac# Scenarios
c e n ario U # 9 "he application uses untrusted
data in the construction of the following
v u ln e ra b le P8 call9
String <uery G HS9L9C" I F'O1 accounts
WF9'9
custIDGJH K re<uestLgetParameter-HidH. K
HJHM
c e n ario U . 9 imilarly, an application-s blind
trust in frameworks may result in 2ueries that
are still vulnerable, 5e.g., Hibernate Puery
8anguage 5HP8669
Nuery FNLNuery G
sessionLcreateNuery-OF'O1 accounts
WF9'9 custIDGJO K
re<uestLgetParameter-HidH. K HJH.M
In both cases, the attacker modifies the Vid-
parameter value
in her browser to send9 J or JJGJ. ,or example9
h t tp >CC e:a mp leLc omC a pp Ca c c o un tA iew+idGJ
or JJGJ
"his changes the meaning of both 2ueries to
return all the records from the accounts table.
'ore dangerous attacks could modify data or
even invoke stored procedures.
'e&erences
OWASP
OWA! P8 In %e c ti o n !re ve n ti o n *heat h ee t
OWA! P u e ry ! aram e teri& a ti o n * h e at h ee t
OWA! *o mm a n d In %e c ti o n Article
OWA! Q'8 e Qtern a l )n ti t y 5Q Q ) 6 ( efe r e n ce
Article
AF 9 O u tpu t )n co d in g: ) s ca p in g ( e 2u ir eme n ts
5F @ 6
OWA! "es ti n g < u id e 9 *h ap ter on P8 In %e c ti o n
"es ti n g
9:ternal
*W) ) n try 11 on *o mm a n d In %e c ti o n
*W) ) n try AO on P8 In %e c ti o n
*W) ) n try B@0 on H ib e r n a t e In %e c ti o n
0ro#en Authentication
and
Session 1anagement
"hre
at
Agen
ts
Attac
#
Aecto
rs
Securi
ty
Wea#ne
ss
"echnic
al
Impac
ts
0usiness
Impacts
Application Speci&ic
9:ploitability
AA9'AE9
Pre$alen
ce
WID9SP'
9AD
Detectabi
lity
AA9'A
E9
Impa
ct
S9A9
'9
Applicatio
n C 0usiness
Speci&ic
*onsider
anonymous
external
attackers,
as well as users
with their own
accounts, who
may attempt
to steal
accounts from
others. Also
consider
insiders
wanting to
disguise their
actions.
Attacker uses
leaks or flaws in
the
authentication
or session
management
functions 5e.g.,
exposed
accounts,
passwords,
session I+s6 to
impersonate
users.
+evelopers fre2uently build
custom authentication and
session management schemes,
but building these correctly is
hard. As a result, these custom
schemes fre2uently have Caws in
areas such as logout, password
management, timeouts,
remember me, secret 2uestion,
account update, etc. ,inding such
Caws can sometimes be dificult,
as each implementation is
uni2ue.
uch Caws may
allow some or
even all
accounts to be
attacked. Once
successful, the
attacker can do
anything the
victim could do.
!rivileged
accounts are
fre2uently
targeted.
*onsider the
business value
of the afected
data or
application
functions.
Also consider
the business
impact of
public
exposure of
the
vulnerability.
Am I Aulnerable to
Fi/ac#ing+
Are session management assets like user
credentials and session I+s properly
protectedT Wou may be vulnerable if9
#. Jser authentication credentials aren-t
protected when
stored using hashing or encryption.
ee A@.
.. *redentials can be guessed or overwritten
through weak account management
functions 5e.g., account creation, change
password, recover password, weak session
I+s6.
/. ession I+s are exposed in the J(8 5e.g.,
J(8 rewriting6.
0. ession I+s are vulnerable to sess ion
Lxa t ion attacks.
B. ession I+s don-t timeout, or user sessions
or authentication tokens, particularly single
sign3on 5O6 tokens, aren-t properly
invalidated during logout.
@. ession I+s aren-t rotated after successful
login.
1. !asswords, session I+s, and other
credentials are sent over unencrypted
connections. ee A@.
ee the AF re2uirement areas F. and F/ for
more details.
Fow Do I Pre$ent "his+
"he primary recommendation for an
organi&ation is to make available to developers9
L A single set o& strong authentication and
session
management controls. uch controls should
strive to9
a6 meet all the authentication and session
management re2uirements defined in
OWA!-s A pp lica t ion e c u rity
F e ri ficati o n t and ard 5AF6 areas F.
5Authentication6 and F/ 5ession
'anagement6.
b6 have a simple interface for developers.
*onsider the ) A!I A u th e n tica t or a n d Jse r
A!Is as good examples to emulate, use, or
build upon.
.. trong eforts should also be made to
avoid Q flaws which can be used to steal
session I+s. ee A/.
A
9:ample Attac# Scenarios
c e n ario U # 9 Airline reservations application
supports J(8
rewriting, putting session I+s in the J(89
h t tp >CC e:a mp leLc omC sa le C sa le it em sM/session
idG
)P!OC)PS(DLPS@FCP%()PA+destGFawaii
An authenticated user of the site wants to let
his friends know about the sale. He e3mails the
above link without knowing he is also giving
away his session I+. When his friends use the
link they will use his session and credit card.
c e n ario U . 9 Application-s timeouts aren-t set
properly. Jser uses a public computer to access
site. Instead of selecting DlogoutG the user simply
closes the browser tab and walks away. Attacker
uses the same browser an hour later, and that
browser is still authenticated.
c e n ario U / 9 Insider or external attacker gains
access to the system-s password database.
Jser passwords are not properly hashed,
exposing every users- password to the attacker.
'e&erences
OWASP
,or a more complete set of re2uirements and
problems to avoid in this area, see the AF
r e 2u ir eme n ts ar e as fo r A u th e n tica t ion 5F . 6
an d ess ion 'a n age me n t 5F / 6 .
OWA! A u th e n tica t ion *heat h ee t
OWA! ,orgot ! a ssw ord * h e at h ee t
OWA! ess ion 'a n age me n t *heat h ee t
OWA! + eve lo p me n t < u id e 9 *h ap ter o n
A u th e n tica t ion
OWA! "es ti n g < u id e 9 *h ap ter on A u th e n tica t ion
9:ternal
*W) ) n try .A1 on Impr op e r A u th e n tica t ion
*W) ) n try /A0 on ess ion ,ixa t ion
A*
Cross2Site Scripting
-3SS.
"hre
at
Agen
ts
Attac
#
Aecto
rs
Securi
ty
Wea#ne
ss
"echnic
al
Impac
ts
0usiness
Impacts
Application SpeciBc
9:ploitability
AA9'AE9
Pre$alen
ce
A9'D
WID9SP'9AD
Detectabi
lity
9AS
D
Impa
ct
1OD9'A
"9
Applicatio
n C
0usiness
Speci&ic
*onsider
anyone who
can send
untrusted
data to the
system,
including
external
users, internal
users, and
administrators
.
Attacker sends
text3 based
attack scripts
that exploit the
interpreter in
the browser.
Almost
any source of
data
can be an
attack
vector,
including
internal sources
such as data
from
the database.
Q is the most prevalent web
application security Caw. Q
flaws occur when an application
includes user supplied data in a
page sent to the browser without
properly validating or escaping
that content. "here are three
known types of Q flaws9 #6
tor e d , .6 ( ef le cte d , and /6 +O'
b as e d Q .
+etection of most Q flaws is
fairly easy
via testing or code analysis.
Attackers can
execute scripts
in a victim-s
browser to
hi%ack user
sessions, deface
web sites, insert
hostile content,
redirect users,
hi%ack the user-s
browser
using malware,
etc.
*onsider the
business value
of the afected
system and all
the data it
processes.
Also consider
the business
impact of
public
exposure of
the
vulnerability.
Am I Aulnerable to 3SS+
Wou are vulnerable if you do not ensure that all
user supplied input is properly escaped, or you do
not verify it to be safe via input validation, before
including that input in the output page. Without
proper output escaping or validation, such input
will be treated as active content in the browser. If
A%ax
is being used to dynamically update the page,
are you using s afe Ia v acri p t A!Is T ,or unsafe
Iavacript A!Is, encoding or
validation must also be used.
Automated tools can Lnd some Q problems
automatically. However, each application builds
output pages diferently and uses diferent
browser side interpreters such as Iavacript,
ActiveQ, ,lash, and ilverlight, making
automated detection dificult. "herefore,
complete coverage re2uires a combination of
manual code review and penetration testing, in
addition to automated approaches.
Web ..$ technologies, such as A%ax, make Q
much more dificult to detect via automated
tools.
Fow Do I Pre$ent 3SS+
!reventing Q re2uires separation of
untrusted data from active browser content.
#. "he preferred option is to properly escape all
untrusted data based on the H"'8 context
5body, attribute, Iavacript, *, or J(86 that
the data will be placed into. ee the OWA!
Q !re ve n ti o n * h e at h ee t for details on
the re2uired data escaping techni2ues.
.. !ositive or DwhitelistG input validation is also
recommended as it helps protect against Q,
but is n ot a compl e te d efe n s e as many
applications re2uire special characters in their
input. uch validation should, as much as
possible, validate the length, characters,
format, and business rules on that data before
accepting the input.
/. ,or rich content, consider auto3saniti&ation
libraries like
OWA!-s An tiamy or the Iava H "'8 an iti&er
!ro %ect .
0. *onsider *o n tent e c u rity ! o licy 5* !6 to
defend against
Q across your entire site.
9:ample Attac# Scenario
"he application uses untrusted data in the
construction of the following H"'8 snippet
without validation or escaping9
-String. page KG H=input
nameGJcreditcardJ typeGJ"93"Q
$alueGJH K re<uestLgetParameter-HCCH. K
HJ?HM
"he attacker modifies the V**- parameter in his
browser to9
J?=script?documentLlocationG
Jh ttp >CC ww wLatt ac #er LcomC cgi 2
b inCcoo #ieLcgi+
&ooGJKdocumentLcoo#ie=Cscript?J.
"his causes the victim-s session I+ to be sent to
the attacker-s website, allowing the attacker to
hi%ack the user-s current session.
Eote that attackers can also use Q to defeat
any automated *(, defense the application
might employ. ee AA for info on *(,.
'e&erences
OWASP
OWA! Q !re ve n ti o n *heat h ee t
OWA! +O' b as e d Q !re ve n ti o n *heat h ee t
OWA! *ro ss 3ite cri p ti n g Article
) A!I )n co d e r A!I
AF 9 O u tpu t )n co d in g: ) s ca p in g ( e 2u ir eme n ts
5F @ 6
OWA! A n tia m y 9 a n iti& a ti o n 8i b ra ry
"es ti n g < u ide9 # s t / * h a p te rs on +ata Fal id ation
"es ti n g
OWA! *o d e ( ev ie w < u id e 9 *h ap ter o n Q
( ev ie w
OWA! Q ,ilter ) v as ion *heat h ee t
9:ternal
*W) ) n try 1O on *ro s s 3ite cri p ti n g
A4
nsecure Direct
Ob/ect 'e&erences
"hre
at
Agen
ts
Attac
#
Aecto
rs
Securi
ty
Wea#ne
ss
"echnic
al
Impac
ts
0usiness
Impacts
Application Speci&ic
9:ploitability
9ASD
Pre$ale
nce
CO11O
(
Detectabi
lity
9AS
D
Impa
ct
1OD9'A
"9
Applicatio
n C 0usiness
Speci&ic
*onsider the
types of users
of your
system. +o
any users have
only partial
access to
certain types
of system
dataT
Attacker, who
is an
authori&ed
system user,
simply changes
a parameter
value that
directly refers
to a system
ob%ect to
another ob%ect
the user isn-t
authori&ed for.
Is access
grantedT
Applications fre2uently use the
actual name or key of an ob%ect
when generating web pages.
Applications don-t always verify
the user is authori&ed for the
target ob%ect. "his results in an
insecure direct ob%ect reference
flaw. "esters can easily
manipulate parameter values to
detect such Caws. *ode analysis
2uickly shows whether
authori&ation is properly verified.
uch Caws can
compromise all
the data that
can be
referenced by
the parameter.
Jnless ob%ect
references are
unpredictable,
it-s easy for an
attacker to
access all
available data
of that type.
*onsider the
business value
of the exposed
data.
Also consider
the business
impact of
public
exposure of
the
vulnerability.
Am I Aulnerable+
"he best way to find out if an application is
vulnerable to insecure direct ob%ect references
is to verify that all ob%ect references have
appropriate defenses. "o achieve this,
consider9
#. ,or direct references to restricted
resources, does the application fail to verify
the user is authori&ed to access the exact
resource they have re2uestedT
.. If the reference is an indirect reference,
does the mapping to the direct reference fail
to limit the values to those authori&ed for the
current userT
*ode review of the application can 2uickly verify
whether either approach is implemented safely.
"esting is also efective for identifying direct
ob%ect references and whether they are safe.
Automated tools typically do not look for such
flaws because they cannot recogni&e what
re2uires protection or what is safe or unsafe.
Fow Do I Pre$ent "his+
!reventing insecure direct ob%ect references
re2uires selecting an approach for protecting
each user accessible ob%ect 5e.g., ob%ect
number, Llename69
L %se per user or session indirect ob/ect
re&erences. "his prevents attackers from
directly targeting unauthori&ed resources.
,or example, instead of using the resource-s
database key, a drop down list of six
resources authori&ed for the current user
could use the numbers # to @ to indicate
which value the user selected. "he
application has to map the per3user indirect
reference back to the actual database key on
the server. OWA!-s ) A!I includes both
se2uential and random access reference
maps that developers can use to eliminate
direct ob%ect references.
)L Chec# access. )ach use of a direct ob%ect
reference from an untrusted source must
include an access control check to ensure the
user is authori&ed for the re2uested ob%ect.
9:ample Attac# Scenario
"he application uses unverified data in a
P8 call that is accessing account
information9
String <uery G HS9L9C" I F'O1 accts
WF9'9 account G +HM PreparedStatement
pstmt G
connectionLprepareStatement-<uery R S .M
pstmtLsetString- R
re<uestLgetParameter-HacctH..M
'esultSet results G
pstmtLe:ecuteNuery- .M
"he attacker simply modifies the Vacct- parameter
in her browser to send whatever account number
she wants. If not properly verified, the attacker
can access any user-s account, instead of only
the intended customer-s account.
h t tp >CC e:a mp leLc omC a p pC a c c ou n tI n &o+
acctGnotmyacct
I
'e&erences
OWASP
OWA! " op # $ 3.$$1 on In se c u re +ir O b %e c t
( efe r e n c e s
) A!I Acc es s ( efe r e n ce 'ap A!I
) A!I Acc es s *o n tr o l A!I -See
isAuthoriTedForData-.R
isAuthoriTedForFile-.R
isAuthoriTedForFunction-. .
,or additional access control re2uirements, see
the AF
re2u iremen ts area for Access *on tro l 5F06 .
9:ternal
*W) ) n try @/O on In se c u re +ir e ct O b %e c t
( efe r e n c e s
*W) ) n try .. on ! a th " ra ve r s al -an e:ample o& a
Direct Ob/ect
'e&erence attac#.
A6
Security
1iscon&iguration
"hre
at
Agen
ts
Attac
#
Aecto
rs
Securi
ty
Wea#ne
ss
"echnic
al
Impac
ts
0usiness
Impacts
Application Speci&ic
9:ploitability
9ASD
Pre$ale
nce
CO11O
(
Detectabi
lity
9AS
D
Impa
ct
1OD9'A
"9
Applicatio
n C 0usiness
Speci&ic
*onsider
anonymous
external
attackers
as well as users
with their own
accounts that
may attempt to
compromise the
system. Also
consider
insiders wanting
to disguise their
actions.
Attacker
accesses
default
accounts,
unused pages,
unpatched
flaws,
unprotected
files and
directories, etc.
to gain
unauthori&ed
access
to or knowledge
of
the system.
ecurity misconfiguration can
happen at any level of an
application stack, including the
platform, web server, application
server, database, framework, and
custom code. +evelopers and
system administrators need to
work together to ensure that the
entire stack is configured
properly. Automated scanners are
useful for detecting missing
patches, misconfigurations, use
of default
accounts, unnecessary services,
etc.
uch Caws
fre2uently give
attackers
unauthori&ed
access to some
system
data or
functionality.
Occasionally,
such
flaws result in a
complete
system
compromise.
"he system
could be
completely
compromised
without you
knowing it. All
of your data
could be stolen
or modified
slowly over
time.
(ecovery costs
could be
expensive.
Am I Aulnerable to Attac#+
Is your application missing the proper
security hardening across any part of the
application stackT Including9
#. Is any of your software out of dateT "his
includes the O, Web:App erver, +;',
applications, and all code libraries -see
new A8..
.. Are any unnecessary features enabled or
installed 5e.g., ports, services, pages,
accounts, privileges6T
/. Are default accounts and their passwords
still enabled and unchangedT
0. +oes your error handling reveal stack
traces or other overly informative error
messages to usersT
B. Are the security settings in your development
frameworks 5e.g., truts, pring, A!.E)"6 and
libraries not set to secure valuesT
Without a concerted, repeatable
application security configuration process,
systems are at a higher risk.
Fow Do I Pre$ent "his+
"he primary recommendations are to
establish all of the following9
#. A repeatable hardening process that makes
it fast and easy to deploy another
environment that is properly locked down.
+evelopment, PA, and production
environments should all be configured
identically 5with diferent passwords used in
each environment6. "his process should be
automated to minimi&e the efort re2uired
to setup a new secure environment.
.. A process for keeping abreast of and
deploying all new software updates and
patches in a timely manner to each deployed
environment. "his needs to include all code
libraries as well -see new A8..
/. A strong application architecture that
provides efective, secure separation
between components.
0. *onsider running scans and doing audits
periodically to help detect future
misconfigurations or missing patches.
9:ample Attac# Scenarios
c e n ario U # 9 "he app server admin console is
automatically installed and not removed. +efault
accounts aren-t changed. Attacker discovers the
standard admin pages are on your server, logs
in with default passwords, and takes over.
c e n ario U . 9 +irectory listing is not disabled on
your server. Attacker discovers she can simply list
directories to Lnd any file. Attacker finds and
downloads all your compiled Iava classes, which
she decompiles and reverse engineers to get all
your custom code. he then Lnds a serious
access control
flaw in your application.
ce n ario U / 9 App server configuration allows
stack traces to be returned to users, potentially
exposing underlying flaws. Attackers love the
extra information error messages provide.
c e n ario U 0 9 App server comes with sample
applications that are not removed from your
production server. aid sample applications have
well known security flaws attackers can use to
compromise your server.
'e&erences
OWASP
OWA! + eve lo p me n t < u id e 9 *h ap ter o n
*o n figu r a t ion
OWA! *o d e ( ev ie w < u id e 9 *h ap ter o n ) rr o r
H a nd ling
OWA! "es ti n g < u id e 9 *o n figu r a t ion 'a n age me n t
OWA! "es ti n g < u id e 9 "es ti n g f or ) rr o r *o d e s
OWA! " op #$ .$$0 3 In se c u re *o n figu r a t ion
'a n age me n t
,or additional re2uirements in this area, see the
AF
re2u iremen ts area for ecurity *onfigu ratio n
5F#.6 .
9:ternal
!* ' a ga & in e Ar t icle o n W e b er ve r H ar d e n in g
*W) ) n try . o n )n v iro n me n ta l e c u rity ,la w s
*I e c u rity *o n figu r a t ion < u id es :; e n c h m ar ks
A5
Sensiti$e Data
9:posure
"hre
at
Agen
ts
Attac
#
Aecto
rs
Securi
ty
Wea#ne
ss
"echnic
al
Impac
ts
0usiness
Impacts
Application Speci&ic
9:ploitability
DIFFIC%L"
Pre$alen
ce
%(CO11
O(
Detectabi
lity
AA9'A
E9
Impa
ct
S9A9
'9
Applicatio
n C
0usiness
Speci&ic
*onsider who
can gain access
to your
sensitive data
and any
backups of that
data. "his
includes the
data at rest, in
transit, and
even in your
customers-
browsers.
Include both
external and
internal threats.
Attackers
typically don-t
break crypto
directly. "hey
break
something else,
such as steal
keys, do man3
in3the3 middle
attacks, or steal
clear text data
off the server,
while
in transit, or
from
the user-s
browser.
"he most common flaw is simply
not encrypting sensitive data.
When crypto is employed, weak
key generation and
management, and weak
algorithm usage is common,
particularly weak password
hashing techni2ues. ;rowser
weaknesses are very common
and easy to detect, but hard to
exploit on a large scale. )xternal
attackers have dificulty
detecting server side Caws due
to limited access and they are
also usually hard to exploit.
,ailure
fre2uently
compromises
all data that
should have
been
protected.
"ypically, this
information
includes
sensitive data
such as health
records,
credentials,
personal data,
credit cards,
etc.
*onsider the
business value
of the lost data
and impact to
your
reputation.
What is your
legal liability if
this data is
exposedT Also
consider the
damage to your
reputation.
Am I Aulnerable to Data
9:posure+
"he first thing you have to determine is which
data is sensitive enough to re2uire extra
protection. ,or example, passwords, credit card
numbers, health records, and personal
Fow Do I Pre$ent "his+
"he full perils of unsafe cryptography, 8 usage,
and data protection are well beyond the scope of
the "op #$. "hat said, for all sensitive data, do all
of the following, at a minimum9
information should be protected. ,or all such data9
#. Is any of this data stored in clear text long
term, including backups of this dataT
.. Is any of this data transmitted in clear text,
internally or externallyT Internet trafic is
especially dangerous.
#.
*onsidering the threats you plan to protect
this data from 5e.g., insider attack, external
user6, make sure you encrypt all sensitive
data at rest and in transit in a manner that
defends against these threats.
.. +on-t store sensitive data unnecessarily.
+iscard it as soon as possible. +ata you
don-t have can-t be stolen.
/. Are any old : weak cryptographic algorithms
usedT
/. )nsure strong standard algorithms and
strong keys are
0. Are weak crypto keys generated, or is
proper key management or rotation
missingT
B. Are any browser security directives or headers
missing when sensitive data is provided by :
sent to the browserT
And more 7 ,or a more complete set of problems
to avoid,
see AF areas *ryp to 5F16, +at a !ro t. 5FO6, an d
8 5F#$6 .
9:ample Attac# Scenarios
c e n ario U # 9 An application encrypts credit card
numbers in a database using automatic database
encryption. However, this means it also decrypts
this data automatically when retrieved, allowing
an P8 in%ection Caw to retrieve credit card
numbers in clear text. "he system should have
encrypted the credit
card numbers using a public key, and only
allowed back3end
applications to decrypt them with the private
key.
c e n ario U . 9 A site simply doesn-t use 8 for
all authenticated pages. Attacker simply
monitors network trafic 5like an open wireless
network6, and steals the user-s session cookie.
Attacker then replays this cookie and hi%acks the
user-s session, accessing the user-s private
data.
c e n ario U / 9 "he password database uses
unsalted hashes to store everyone-s passwords.
A Lle upload flaw allows an attacker to retrieve
the password Lle. All of the unsalted hashes can
be exposed with a rainbow table of precalculated
hashes.
used, and proper key management is in place.
*onsider
using ,I! #0$ valid at ed
cryp to graph ic modu les .
0. )nsure passwords are stored with an
algorithm specifically designed for
password protection, such as b cr ypt ,
!;K+, . , or s cr ypt .
B. +isable autocomplete on forms collecting
sensitive data and disable caching for pages
that contain sensitive data.
'e&erences
OWASP 2 ,or a more complete set of
re2uirements, see
AF re2 - ts o n *ryp to grap h y 5F16, +at a
!ro tection 5FO6 and
*ommun ication s ecu rity 5F#$6
OWA! *ry p to gra ph ic t o rage *heat h ee t
OWA! ! a ssw ord torage *heat h ee t
OWA! " ra n s p ort 8 ay e r !r o tection * h e at h ee t
OWA! "es ti n g < u id e 9 *h ap ter on 8: " 8
"es ti n g
9:ternal
*W) ) n try /#$ on *ry p to gra ph ic Iss u e s
*W) ) n try /#. on * le artext torage of ens iti v e
In forma t ion
*W) )n try /#O on * le artext " ra n sm iss ion o f
ens iti v e
In format ion
*W) ) n try /.@ on Weak )n cr yp ti o n
1issing Function Le$el
Access
Control
"hre
at
Agen
ts
Attac
#
Aecto
rs
Securi
ty
Wea#ne
ss
"echnic
al
Impac
ts
0usiness
Impacts
Application Speci&ic
9:ploitability
9ASD
Pre$ale
nce
CO11O
(
Detectabi
lity
AA9'A
E9
Impa
ct
1OD9'A
"9
Applicatio
n C 0usiness
Speci&ic
Anyone with
network access
can send your
application a
re2uest. *ould
anonymous
users access
private
functionality or
regular users a
privileged
functionT
Attacker, who
is an authori&ed
system user,
simply changes
the J(8 or a
parameter to a
privileged
function. Is
access
grantedT
Anonymous
users
could access
private
functions that
aren-t
protected.
Applications do not always
protect application functions
properly. ometimes, function
level protection is managed via
configuration, and the system is
misconfigured. ometimes,
developers must include the
proper code checks, and they
forget.
+etecting such Caws is easy. "he
hardest part is identifying which
pages 5J(8s6 or functions exist
to attack.
uch Caws
allow attackers
to access
unauthori&ed
functionality.
Administrative
functions are
key targets for
this type of
attack.
*onsider the
business value
of the exposed
functions and
the data they
process.
Also consider
the impact to
your
reputation if
this
vulnerability
became
public.
Am I Aulnerable to
Forced Access+
"he best way to find out if an application
has failed to properly restrict function level
access is to verify e$ery application
function9
Fow Do I Pre$ent
Forced Access+
Wour application should have a consistent and
easy to analy&e authori&ation module that is
invoked from all of your business functions.
,re2uently, such protection is provided by one or
y
A
#. +oes the JI show navigation to unauthori&ed
functionsT
more components external to the application
code.
.. Are server side authentication or
authori&ation checks missingT
#. "hink about the process for managing
entitlements and
ensure you can update and audit easily. +on-t
/. Are server side checks done that solely rely on
.. "he enforcement mechanism5s6 should deny
all access by
information provided by the attackerT
default, re2uiring explicit grants to specific
Jsing a proxy, browse your application with a
privileged role.
"hen revisit restricted pages using a less
privileged role. If the
server responses are alike, youXre probably
vulnerable. ome
testing proxies directly support this type of
analysis.
Wou can also check the access control
implementation in the code. "ry following a
single privileged re2uest through the code and
verifying the authori&ation pattern. "hen search
the codebase to find where that pattern is not
being followed.
Automated tools are unlikely to find these
problems.
9:ample Attac# Scenarios
c e n ario U # 9 "he attacker simply force browses
to target
J(8s. "he following J(8s re2uire authentication.
Admin rights
are also re2uired for access to the
DadminYgetappInfoG page.
h t tp >CC e:a mp leLc omC a p p C g eta p p I
n &o
h t tp >CC e:a mp leLc omC a p p C a dm in Ug
eta p p In &o
If an unauthenticated user can access either
page, that-s a flaw. If an authenticated, non3
admin, user is allowed to access the
DadminYgetappInfoG page, this is also a flaw, and
may
lead the attacker to more improperly protected
admin pages.
c e n ario U . 9 A page provides an Vaction
Vparameter to specify the function being invoked,
and diferent actions re2uire diferent roles. If
these roles aren-t enforced, that-s a flaw.
access to every function.
/. If the function is involved in a workflow,
check to make sure the conditions are in the
proper state to allow access.
EO")9 'ost web applications don-t display links
and buttons to unauthori&ed functions, but this
Dpresentation layer access controlG doesn-t
actually provide protection. Wou must al s o
implement checks in the controller or business
logic.
'e&erences
OWASP
OWA! " op # $ 3.$$1 on ,ail u re t o (e s trict J (8
Acc es s
) A ! I Ac c ess * o n tr o l A ! I
OWA! + eve lo p me n t < u id e 9 *h ap ter o n
A u th ori& a ti o n
OWA! "es ti n g < u id e 9 "es ti n g f or ! a th " ra ve r s al
OWA! Article o n , o rc e d ;row s in g
,or additional access control re2uirements, see
the AF
re2u iremen ts area for Access *on trol 5F06 .
9:ternal
*W) ) n try .AB on Impr op e r Acc es s *o n tr o l
5A u th ori& a ti on 6
Cross2Site 'e<uest
Forgery
-CS'F.
"hre
at
Agen
ts
Attac
#
Aecto
rs
Securi
ty
Wea#ne
ss
"echnic
al
Impac
ts
0usiness
Impacts
Application Speci&ic
9:ploitability
AA9'AE9
Pre$ale
nce
CO11O
(
Detectabi
lity
9AS
D
Impa
ct
1OD9'A
"9
Applicatio
n C 0usiness
Speci&ic
*onsider
anyone who
can load
content into
your users-
browsers,
and thus force
them to submit
a re2uest
to your
website. Any
website or
other H"'8
feed that
your users
access could do
this.
Attacker
creates forged
H""! re2uests
and tricks a
victim into
submitting
them via image
tags, Q, or
numerous
other
techni2ues. If
th e u se r is
a u th e n tica t e d ,
the attack
succeeds.
* (, takes advantage of the fact
that most web apps allow
attackers to predict all the
details of a particular action.
;ecause browsers send
credentials like session cookies
automatically, attackers can
create malicious web pages
which generate forged re2uests
that are indistinguishable from
legitimate ones.
+etection of *(, flaws is fairly
easy via penetration testing or
code analysis.
Attackers can
trick victims
into
performing
any state
changing
operation the
victim is
authori&ed to
perform, e.g.,
updating
account
details,
making
purchases,
logout and
even login.
*onsider the
business value
of the afected
data or
application
functions.
Imagine not
being sure if
users intended
to take these
actions.
*onsider the
impact to your
reputation.
Am I Aulnerable to CS'F+
"o check whether an application is vulnerable,
see if any links and forms lack an unpredictable
*(, token. Without such a token, attackers can
forge malicious re2uests. An alternate defense is
to re2uire the user to prove they intended to
submit the re2uest, either through
reauthentication, or some other proof they are a
real user 5e.g., a *A!"*HA6.
,ocus on the links and forms that invoke state3
changing functions, since those are the most
important *(, targets.
Wou should check multistep transactions, as
they are not inherently immune. Attackers
can easily forge a series of re2uests by using
multiple tags or possibly Iavacript.
Eote that session cookies, source I! addresses,
and other information automatically sent by the
browser don-t provide any defense against *(,
since this information is also included in forged
re2uests.
OWA!-s * (, "es ter tool can help generate
test cases to demonstrate the dangers of
*(, flaws.
Fow Do I Pre$ent CS'F+
!reventing *(, usually re2uires the
inclusion of an unpredictable token in each
H""! re2uest. uch tokens should, at a
minimum, be uni2ue per user session.
#. "he preferred option is to include the uni2ue
token in a hidden field. "his causes the value
to be sent in the body of the H""! re2uest,
avoiding its inclusion in the J(8, which is
more prone to exposure.
.. "he uni2ue token can also be included in the
J(8 itself, or a J(8 parameter. However,
such placement runs a greater risk that the
J(8 will be exposed to an attacker, thus
compromising the secret token.
OWA!-s * (, < u ard can automatically include
such tokens in Iava )), .E)", or !H! apps.
OWA!-s ) A!I includes methods developers
can use to prevent *(, vulnerabilities.
/. (e2uiring the user to reauthenticate, or
prove they are a user 5e.g., via a *A!"*HA6
can also protect against *(,.
9:ample Attac# Scenario
"he application allows a user to submit a state
changing re2uest that does not include
anything secret. ,or example9
h t tp >CC e:a mp leLc omC a p p C t r a n s & e r F und s+
amountG6!!
VdestinationAccountG457*)4*)4*
o, the attacker constructs a re2uest that will
transfer money from the victim-s account to the
attacker-s account, and then embeds this attack
in an image re2uest or iframe stored on various
sites under the attacker-s control9
=img
srcGH h t tp >CC e:a mp leLc omC a pp Ct r a n s & e r
F und s+
amountG6!!VdestinationAccountGat
tac#ersAcctWO widthGH!H heightGH!H
C?
A
If the victim visits any of the attacker-s sites
while already authenticated to example.com,
these forged re2uests will automatically include
the user-s session info, authori&ing the
attacker-s re2uest.
'e&erences
OWASP
OWA! * (, Article
OWA! * (, !re ve n ti o n *heat h ee t
OWA! * (, < u ard 3 * (, + efe n s e " oo l
) A!I !r o %e c t H o m e ! a ge
) A!I H "" !Jtilities * lass w ith A n ti* ( , " oke n s
OWA! "es ti n g < u id e 9 *h ap ter on * (, "es ti n g
OWA! * (, " es ter 3 * (, "es ti n g " oo l
9:ternal
*W) ) n try /B. on * (,
%sing Components
with @nown
Aulnerabilities
"hre
at
Agen
ts
Attac
#
Aecto
rs
Securi
ty
Wea#ne
ss
"echnic
al
Impac
ts
0usiness
Impacts
Application Speci&ic
9:ploitability
AA9'AE9
Pre$alen
ce
WID9SP'
9AD
Detectabi
lity
DIFFIC%
L"
Impa
ct
1OD9'A
"9
Applicatio
n C 0usiness
Speci&ic
ome
vulnerable
components
5e.g., framework
libraries6 can be
identified
and exploited
with
automated
tools,
expanding the
threat agent
pool beyond
targeted
attackers to
include chaotic
actors.
Attacker
identifies a
weak
component
through
scanning or
manual
analysis. He
customi&es the
exploit as
needed and
executes the
attack. It gets
more dificult if
the used
component is
deep in the
application.
Firtually every application has
these issues because most
development teams don-t focus
on ensuring their
components:libraries are up to
date. In many cases, the
developers don-t even know all
the components they are using,
never mind their versions.
*omponent dependencies make
things even worse.
"he full range
of weaknesses
is possible,
including
in%ection,
broken access
control, Q,
etc. "he impact
could range
from minimal to
complete host
takeover and
data
compromise.
*onsider what
each
vulnerability
might mean for
the business
controlled by
the afected
application. It
could be trivial
or it could mean
complete
compromise.
Am I Aulnerable to @nown
Aulns+
In theory, it ought to be easy to figure out if you
are currently using any vulnerable components
or libraries. Jnfortunately, vulnerability reports
for commercial or open source software do not
always specify exactly which versions of a
component are vulnerable in a standard,
searchable way. ,urther, not all libraries use an
understandable version numbering system.
Worst of all, not all vulnerabilities are reported to
a central clearinghouse that is easy to search,
although sites like * F ) and E F+ are becoming
easier to search.
+etermining if you are vulnerable re2uires
searching these databases, as well as keeping
abreast of pro%ect mailing lists and
announcements for anything that might be a
vulnerability. If one of your components does
have a vulnerability, you should carefully
evaluate whether you are actually vulnerable by
checking to see if your code uses the
part of the component with the vulnerability and
whether the
flaw could result in an impact you care about.
Fow Do I Pre$ent "his+
One option is not to use components that you
didn-t write. ;ut that-s not very realistic.
'ost component pro%ects do not create
vulnerability patches for old versions. Instead,
most simply fix the problem in the next version.
o upgrading to these new versions is critical.
oftware pro%ects should have a process in place
to9
#6 Identify all components and the versions
you are using, including all dependencies.
5e.g., the ve r s io n s plugin6.
.6 'onitor the security of these components in
public databases, pro%ect mailing lists, and
security mailing lists, and keep them up to
date.
/6 )stablish security policies governing
component use, such as re2uiring certain
software development practices, passing
security tests, and acceptable licenses.
06 Where appropriate, consider adding security
wrappers around components to disable
unused functionality and: or secure weak or
vulnerable aspects of the component.
9:ample Attac# Scenarios
*omponent vulnerabilities can cause almost any
type of risk imaginable, ranging from the trivial
to sophisticated malware designed to target a
specific organi&ation. *omponents almost always
run with the full privilege of the application, so
flaws in a n y component can be serious, "he
following two
vulnerable components were downloaded ..m
times in .$##.
A p ac h e *Q, A u th e n tica t ion ;y p ass ? ;y failing
to provide an identity token, attackers could
invoke any web service with full permission.
5Apache *Q, is a services framework, not to
be confused with the Apache Application
erver.6
pring ( em ote * o d e ) x e cution ? Abuse of the
)xpression 8anguage implementation in
pring allowed attackers to execute arbitrary
code, efectively taking over the server.
A
)very application using either of these vulnerable
libraries is vulnerable to attack as both of these
components are directly accessible by application
users. Other vulnerable libraries, used deeper in
an application, may be harder to exploit.
'e&erences
OWASP
OWA! + e p e nd e n cy *he c k 5for Ia v a lib r ari es 6
OWA! af e Eu <e t 5for .E) " li b rari e s th ru Eu <e t 6
< ood *o m p o n e n t !r a ctic e s ! r o %e c t
9:ternal
" h e J n fort un a t e ( e ali t y of In se c u re 8i b rari e s
O p e n ou rce oft w are e c u rity
A dd r ess in g e c u rity *o n c e r n s in Op e n ou rce
*o m p o n e n ts
'I " () *o mm on Ful n e ra b ilities a n d ) x p o s u r e s
) x a m p le 'ass A ss ignm e n t Ful n e ra b ility th at was
Lx e d in
Active(ecord , a (ub y on (a ils <) '
A
!
%n$alidated
'edirects and
orwards
"hre
at
Agen
ts
Attac
#
Aecto
rs
Securi
ty
Wea#n
ess
"echni
cal
Impac
ts
0usiness
Impacts
Application Speci&ic
9:ploitability
AA9'AE9
Pre$alen
ce
%(CO11
O(
Detectabi
lity
9AS
D
Impa
ct
1OD9'A
"9
Applicatio
n C 0usiness
Speci&ic
*onsider
anyone who
can trick your
users into
submitting a
re2uest to
your website.
Any website or
other H"'8
feed that your
users use
could do this.
Attacker links to
unvalidated
redirect and
tricks victims
into clicking it.
Fictims are
more likely to
click on it, since
the link is to a
valid site.
Attacker targets
unsafe forward
to bypass
security checks.
Applications fre2uently redirect
users to other pages, or use
internal forwards in a similar
manner. ometimes the target
page is specified in an
unvalidated parameter, allowing
attackers to choose the
destination page.
+etecting unchecked redirects is
easy. 8ook for redirects where
you can set the full J(8.
Jnchecked forwards are harder,
because they target internal
pages.
uch redirects
may attempt to
install malware
or trick victims
into disclosing
passwords or
other sensitive
information.
Jnsafe
forwards may
allow
access control
bypass.
*onsider the
business
value of
retaining your
users- trust.
What if they get
owned by
malwareT
What if
attackers can
access internal
only functionsT
Am I Aulnerable to
'edirection+
"he best way to find out if an application has any
unvalidated redirects or forwards is to9
#. (eview the code for all uses of redirect or
forward 5called a transfer in .E)"6. ,or each
use, identify if the target J(8 is included in
any parameter values. If so, if the target
J(8 isn-t validated against a whitelist, you are
vulnerable.
.. Also, spider the site to see if it generates
any redirects 5H""! response codes /$$3
/$1, typically /$.6. 8ook at the parameters
supplied prior to the redirect to see if
they appear to be a target J(8 or a piece of
such a J(8. If
so, change the J(8 target and observe
whether the site
redirects to the new target.
/. If code is unavailable, check all parameters to
see if they look like part of a redirect or
forward J(8 destination and test those that
do.
F
Fow Do I Pre$ent "his+
afe use of redirects and forwards can be done
in a number of ways9
#. imply avoid using redirects and forwards.
.. If used, don-t involve user parameters in
calculating the
destination. "his can usually be done.
/. If destination parameters can-t be avoided,
ensure that
the supplied value is $alid, and authoriTed
for the user.
It is recommended that any such destination
parameters be a mapping value, rather than
the actual J(8 or portion of the J(8, and that
server side code translate this mapping to
the target J(8.
Applications can use )A!I to override the
se nd ( e d ir e ct56
method to make sure all redirect destinations
are safe.
Avoiding such Caws is extremely important as they
are a
favorite target of phishers trying to gain the user-s
trust.
9:ample Attac# Scenarios
c e n ario U # 9 "he application has a page called
Dredirect.%spG which takes a single parameter
named DurlG. "he attacker crafts a malicious
J(8 that redirects users to a malicious site that
performs phishing and installs malware.
h t tp >CC w w wLe:a mp leLc omCr e d ir e ctL/sp+
urlGe$ilLcom
c e n ario U . 9 "he application uses forwards to
route re2uests between diferent parts of the
site. "o facilitate this, some pages use a
parameter to indicate where the user should be
sent if a transaction is successful. In this case,
the attacker crafts a J(8 that will pass the
application-s access control check and then
forwards the attacker to administrative
functionality for which the attacker isn-t
authori&ed.
h t tp >CC w w wLe:a mp leLc omCbor in g L/sp+
&wdGadminL/sp
'e&erences
OWASP
OWA! Article o n Op e n (edir e cts
) A!I e c u rit y Wr app e r( es p o n s e se nd ( e d ir e ct56
me th o d
9:ternal
*W) ) n try @$# on O p e n (edir e cts
WA* Article o n J (8 ( e d ir e ct o r A bu s e
< oogle b log article o n th e d a n g e rs of o p e n
r e d ir e cts
OWA! " op #$ for .E) " a rticle o n J n v ali d a t e d
( e d ir e cts a n d
,orward s
KD
Whats (e:t &or
De$elopers
9stablish V %se 'epeatable Security Processes and
Standard Security Controls
Whether you are new to web application security or are already very familiar with these risks, the task
of producing a secure web application or fixing an existing one can be dificult. If you have to manage a
large application portfolio, this can be daun ting.
"o help organi&ations and developers reduce their application security risks in a cost efective manner,
OWA! has produced numerous fr e e a n d o p e n resources that you can use to address application
security in your organi&ation. "he following are some of the many resources OWA! has produced to
help organi&ations produce secure web applications. On the next page, we present additional OWA!
resources that can assist organi&ations in verifying the security of their applications.
Applicatio
n Security
'e<uirem
ents
"o produce a se c u re web application, you must define what secure means for
that application. OWA! recommends you use the OWA! A pp lica t ion
e c u rity F e ri ficati o n t and ard 5A F 6 , as a guide for setting the security
re2uirements for your application5s6. If you-re outsourcing, consider the
OWA! e c u re oft w are *o n tr a ct A nn e x .
Applicati
on
Security
Architect
ure
(ather than retrofitting security into your applications, it is far more cost
efective to design the security in from the start. OWA! recommends the
OWA! + eve lop e r- s < u id e , and the OWA! !re ve n ti o n *heat h ee ts as
good starting points for guidance on how to design security in from the
beginning.
Stand
ard
Securi
ty
Contr
ols
;uilding strong and usable security controls is exceptionally dificult. A set of
standard security controls radically simplifies the development of secure
applications. OWA! recommends the OWA! )n ter p ri s e e c u rity A ! I 5)A!I6
p r o %e c t as a model for the security A!Is needed to produce secure web
applications. )A!I provides reference implementations in Ia v a , .E) " , ! H ! ,
* las s ic
A!, !y th on , and *old ,u sion .
Secure
De$elopm
ent
Li&ecycle
"o improve the process your organi&ation follows when building such
applications, OWA! recommends the OWA! oft w are A ss u ra n ce
'at u rity ' od e l 5A'' 6 . "his model helps organi&ations formulate and
implement a strategy for software security that is tailored to the specific
risks facing their organi&ation.
Applicat
ion
Security
9ducatio
n
"he OWA! )du ca t ion !r o %e c t provides training materials to help educate
developers on web application security and has compiled a large list of OWA!
)du ca t io n al !re se n ta ti on s . ,or hands3 on learning about vulnerabilities, try
OWA! Web<o at , Web<o a t. E) " , or the OWA! ;ro k e n Web A pp lica t io n s
!r o %e c t . "o stay current, come to an OWA! A pp e c *o n fe r e n c e , OWA!
*onference "raining, or local OWA! *h ap ter mee ti n gs .
"here are numerous additional OWA! resources available for your use. !lease visit the OW A !
!ro%e c ts p age , which lists all of the OWA! pro%ects, organi&ed by the release 2uality of the pro%ects in
2uestion 5(elease Puality, ;eta, or Alpha6. 'ost OWA! resources are available on our w iki , and many
OWA! documents can be ordered in h ar d co p y or as e ;ook s .
KA
Whats (e:t &or
Aeri&iers
Eet OrganiTed
"o verify the security of a web application you have developed, or one you are considering purchasing,
OWA! recommends that you review the application-s code 5if available6, and test the application as
well. OWA! recommends a combination of secure code review and application penetration testing
whenever possible, as that allows you to leverage the strengths of both techni2ues, and the two
approaches complement each other. "ools for assisting the verification process can improve the
eficiency and efectiveness of an expert analyst. OWA!-s assessment tools are focused on helping an
expert become more efective, rather than trying to automate the analysis process itself.
tandardi&ing How Wou Ferify Web Application ecurity9 "o help organi&ations develop consistency
and a defined level of rigor when assessing the security of web applications, OWA! has produced
the OWA! A pp lica t ion e c u rity Feri ficati o n t a nd ar d 5A F 6. "his document defines a minimum
verification standard for performing web application security assessments. OWA! recommends that
you use the AF as guidance for not only what to look for when verifying the security of a web
application, but also which techni2ues are most appropriate to use, and to help you define and select
a level of rigor when verifying the security of a web application. OWA! also recommends you use
the AF to help define and select any web application assessment services you might procure from
a third party provider.
Assessment "ools uite9 "he OWA! 8i v e *+ !r o %e c t has pulled together some of the best open source
security tools into a single bootable environment or virtual machine 5F'6. Web developers, testers, and
security professionals can boot from this 8ive *+,
or run the F', and immediately have access to a full security testing suite. Eo installation or
configuration is re2uired to use the tools provided on this *+.
Code 'e$iew
ecure code review is particularly suited to
verifying that an application contains strong
security mechanisms as well as finding issues
that are hard to identify by examining the
application-s output. "esting is particularly suited
to proving that flaws are actually exploitable.
"hat said, the approaches are complementary
and in fact overlap in some areas.
(eviewing the *ode9 As a companion to the
OWA!
+evelop er-s <u ide , and the OWA! "estin g
<u ide , OWA! has
produced the OWA! *od e (eview <u id e to help
developers
and application security specialists understand
how to
eficiently and efectively review a web application
for security
by reviewing the code. "here are numerous web
application
security issues, such as In%ection ,laws, that are
far easier to
find through code review, than external testing.
*ode (eview "ools9 OWA! has been doing some
promising work in the area of assisting experts in
performing code analysis, but these tools are still
in their early stages. "he authors of these tools
use them every day when performing their
secure code reviews, but non3experts may find
these tools a bit dificult to use. "hese include
*o d e *ra w le r , Ori& on , and O.. Only O. has been
under active development since the last release
of the "op #$ in .$#$.
"here are other free, open source, code
review tools. "he most promising is ,in d ;ug s ,
and its new security focused plugin called9
,in d e c u rit y ;ugs , both of which are for Iava.
Security and Penetration
"esting
"esting the Application9 OWA! produced the
"es ti n g < u id e to help developers, testers, and
application security specialists understand how to
eficiently and efectively test the security of web
applications. "his enormous guide, which had
do&ens of contributors, provides wide coverage
on many web application security testing topics.
Iust as code review
has its strengths, so does security testing. It-s
very compelling when you can prove that an
application is insecure by demonstrating the
exploit. "here are also many security issues,
particularly all the security provided by the
application infrastructure, that simply cannot
be seen by a code review, since the application
is not providing all of the security itself.
Application !enetration "esting "ools9
Webcara b , which was one of the most widely
used of all OWA! pro%ects, and the new ZA ! ,
which now is far more popular, are both web
application testing proxies. uch tools allow
security analysts and developers to intercept
web application re2uests, so they can figure out
how the application works, and then submit test
re2uests to see if the application responds
securely to such re2uests. "hese tools are
particularly efective at assisting in identifying
Q flaws, Authentication flaws, and Access
*ontrol flaws. ZA! even has an ac t iv e s ca nn e r
built in, and best of all it-s ,())=
KO
Whats (e:t &or
OrganiTations
Start Dour Application Security Program (ow
Application security is no longer optional. ;etween increasing attacks and regulatory pressures,
organi&ations must establish an efective capability for securing their applications. <iven the
staggering number of applications and lines of code already in production, many organi&ations are
struggling to get a handle on the enormous volume of vulnerabilities. OWA! recommends that
organi&ations establish an application security program to gain insight and improve security across
their application portfolio. Achieving application security re2uires many diferent parts of an
organi&ation to work together eficiently, including security and audit, software development, and
business and executive management. It re2uires security to be visible, so that all the diferent players
can see and understand the organi&ation-s application security posture. It also re2uires focus on the
activities and outcomes that actually help improve enterprise security by reducing risk in the most cost
efective manner. ome of the key activities in efective application security programs include9
Eet
Started
[)stablish an a pp lica t ion se c u rity p r o gram and drive adoption.
[*onduct a ca p a b ility g a p an al y s is c o m p ari n g y o u r orga n i& a ti o n t o y o u r
p ee rs to define key improvement areas and an execution plan.
[<ain management approval and establish an a pp lica t io n se c u rity aware n es s
camp a ign for the entire
I" organi&ation.
'is#
0ased
Port&oli
o
Approa
ch
[Identify and p riori t i&e y o u r a pp lica t ion p ortfolio from an inherent risk perspective.
[*reate an application risk profiling model to measure and prioriti&e the applications
in your portfolio.
[)stablish assurance guidelines to properly define coverage and level of rigor
re2uired.
[)stablish a com m on ri s k rati n g m o d e l with a consistent set of likelihood and
impact factors reflective of your organi&ationXs tolerance for risk.
9nable
with a
Strong
Foundatio
n
[)stablish a set of focused p olici e s a n d sta nd ar d s that provide an application
security baseline for all development teams to adhere to.
[+efine a com m on se t of r e u s a b le se c u rity co n tr o ls that complement these
policies and standards and provide design and development guidance on their
use.
[)stablish an a pp lica t ion se c u rity tr a in in g c u rric u lu m that is re2uired and
targeted to diferent development roles and topics.
Integrate
Security
into
9:isting
Processes
[+efine and integrate se curity im p leme n tation and ve ri fic ation activities into
existing development and operational processes. Activities include " h r e at
' od e lin g , ecure +esign N ( ev iew , ecure *oding N *o d e (e v ie w ,
!enetr a ti o n "es ti ng , and (emediation.
[!rovide sub%ect matter experts and s upp ort se r v ic e s for d eve lo p me n t a n d
p r o %e c t teams to be successful.
Pro$ide 1anagement Aisibility
['anage
with
metrics.
+rive
improvem
ent and
funding
decisions based on the metrics and analysis data captured. 'etrics include
adherence to security practices : activities, vulnerabilities introduced,
vulnerabilities mitigated, application coverage, defect density by type and
instance counts, etc.
[Analy&e data from the implementation and verification activities to look
for root cause and vulnerability patterns to drive strategic and systemic
improvements across the enterprise.
K'
(ote About 'is#s
Its About 'is#sR (ot Wea#nesses
Although the .$$1 and earlier versions of the OWA! " op #$ focused on identifying the most common
Dvulnerabilities,G the OWA! "op #$ has always been organi&ed around risks. "his has caused some
understandable confusion on the part of people searching for an airtight weakness taxonomy. "he
OWA! " op #$ for .$#$ clarified the risk3focus in the "op #$ by being very explicit about how threat
agents, attack vectors, weaknesses, technical impacts, and business impacts combine to produce risk
s. "his version of the OWA! "op #$ follows the same methodology.
"he (isk (ating methodology for the "op #$ is based on the OWA! (i s k (a t in g 'et h o d olog y . ,or each
"op #$ item, we
estimated the typical risk that each weakness introduces to a typical web application by looking at
common likelihood factors and
impact factors for each common weakness. We then rank ordered the "op #$ according to those
weaknesses that typically
introduce the most signiLcant risk to an application.
"he OWA! (i s k (a t in g ' e th o d ology defines numerous factors to help calculate the risk of an
identified vulnerability. However, the "op #$ must talk about generalities, rather than specific
vulnerabilities in real applications. *onse2uently, we can never be as precise as system owners can be
when calculating risks for their application5s6. Wou are best e2uipped to %udge the importance of your
applications and data, what your threat agents are, and how your system has been built and is being
operated.
Our methodology includes three likelihood factors for each weakness 5prevalence, detectability, and
ease of exploit6 and one impact factor 5technical impact6. "he prevalence of a weakness is a factor that
you typically don-t have to calculate. ,or prevalence data, we have been supplied prevalence statistics
from a number of diferent organi&ations 5as referenced in the Acknowledgements section on page /6
and we have averaged their data together to come up with a "op #$ likelihood of existence list by
prevalence. "his data was then combined with the other two likelihood factors 5detectability and ease
of exploit6 to calculate a likelihood rating for each weakness. "his was then multiplied by our estimated
average technical impact for each item to come up with an overall risk ranking for each item in the "op
#$.
Eote that this approach does not take the likelihood of the threat agent into account. Eor does it
account for any of the var ious technical details associated with your particular application. Any of these
factors could significantly affect the overall likelihood of an attacker finding and exploiting a particular
vulnerability. "his rating also does not take into account the actual impact on your business. W o u r
orga n i& a ti o n will have to decide how much security risk from applications th e o rga n i& a ti o n is willing to
accept
given your culture, industry, and regulatory environment. "he purpose of the OWA! "op #$ is not to do
this risk analysis for you.
"he following illustrates our calculation of the risk for A/9 *ross3ite cripting, as an example. Q is so
prevalent it warranted the
only VF)(W WI+)!()A+- prevalence value of $. All other risks ranged from widespread to uncommon
5value # to /6.
"hre
at
Agen
ts
Attac
#
Aecto
rs
Securi
ty
Wea#ne
ss
"echnic
al
Impac
ts
0usiness
Impacts
App Speci&ic
9:ploitability
Pre$alen
ce
A9'D
WID9SP'9AD
Detectabi
lity
9AS
D
Impa
ct
1OD9'A
"9
)
App C
0usiness
Speci
Bc
)
AA9'A
E9
) !

I
)
KF
Details About 'is#
Factors
"op ! 'is# Factor Summary
"he following table presents a summary of the .$#/ "op #$ Application ecurity (isks, and the risk
factors we have assigned to each risk. "hese factors were determined based on the available
statistics and the experience of the OWA! "op #$ team. "o understand these risks for a particular
application or organi&ation, y ou m u s t co n s id e r y o u r o w n s p e ci fic th r e at a g e n ts a n d bu s in es s impac t s .
)ven egregious software weaknesses may not present a serious risk if there are no threat agents in a
position to perform the necessary attack or the business impact is negligible for the assets involved.
(I
K
"hre
at
Agen
ts
Attac
#
Aecto
rs
9:ploitabi
lity
Securi
ty
Wea#ne
ss
Pre$alence
Detectability
"echnic
al
Impac
ts
Impa
ct
0usiness
Impacts
Additional 'is#s to Consider
"he "op #$ cover a lot of ground, but there are many other risks you should consider and evaluate in
your organi&ation. ome of these have appeared in previous versions of the "op #$, and others have
not, including new attack techni2ues that are being identified all the time. Other important application
security risks 5in alphabetical order6 that you should also consider in clude9
* lick% a cki n g
*on cu rren cy ,laws
+en ial of ervice 5Was .$$0 "op #$ ? )ntry .$$03AO6
A2In/ection App
Speci&ic
9AS
D
CO11O( AA9'AE9 S9A9'9 App
Speci&ic
A)2
Authentication
App
Speci&ic
AA9'AE9 WID9SP'9A
D
AA9'AE9 S9A9'9 App
Speci&ic
A*23SS App
Speci&ic
AA9'AE9 A9'D
WID9SP'9AD
9AS
D
1OD9'A"9 App
Speci&ic
A42Insecure
DO'
App
Speci&ic
9AS
D
CO11O( 9AS
D
1OD9'A"9 App
Speci&ic
A621iscon&ig App
Speci&ic
9AS
D
CO11O( 9AS
D
1OD9'A"9 App
Speci&ic
A52SensL
Data
App
Speci&ic
DIFFIC%L" %(CO11O( AA9'AE9 S9A9'9 App
Speci&ic
A72Function
AccL
App
Speci&ic
9AS
D
CO11O( AA9'AE9 1OD9'A"9 App
Speci&ic
A;2CS'F App
Speci&ic
AA9'AE9 CO11O( 9AS
D
1OD9'A"9 App
Speci&ic
A82
Components
App
SpeciBc
AA9'AE9 WID9SP'9A
D
DIFFIC%L" 1OD9'A"9 App
SpeciBc
A!2
'edirects
App
Speci&ic
AA9'AE9 %(CO11O( 9AS
D
1OD9'A"9 App
Speci&ic
) xp ression 8 an gu age In %ectio n 5*W) 3O#16
In format ion 8eakage and Improp er ) rro r H and ling 5Was part of .$$1 "op #$ ? )n try .$$13A@6
In su ficien t An ti 3au to mat ion 5*W) 31OO6
Insuficient 8ogging and Accountability 5(elated to .$$1 "op #$ ? )n try .$$13A@6
8ack of In tru sion +etection an d (esp on se
'aliciou s ,ile ) xecu tio n 5Was .$$1 "op #$ ? )n try .$$13A/6
'ass Assignmen t 5*W) 3O#B6
Jser !rivacy