RobustDefensesforCross-SiteRequestForgery
AdamBarth
StanfordUniversity
abarth@cs.stanford.edu
CollinJackson
StanfordUniversity
collinj@cs.stanford.edu
JohnC.Mitchell
StanfordUniversity
mitchell@cs.stanford.edu
ABSTRACT
Cross-Site Request t Forgery (CSRF) is a a widely y exploited
websitevulnerability.Inthispaper,wepresentanewvari-
ation onCSRFattacks,login CSRF,inwhich theattacker
forgesacross-siterequesttotheloginform,loggingthevic-
timintothe honestweb siteas theattacker. . Theseverity
ofaloginCSRFvulnerabilityvaries by site,but it can be
as severeas across-site scripting g vulnerability. . We e detail
threemajorCSRFdefensetechniquesandfindshortcomings
witheachtechnique. Although h the HTTPRefererheader
couldprovidean effectivedefense,ourexperimentalobser-
vation of 283,945advertisementimpressions indicates that
theheaderiswidelyblockedatthenetworklayerduetopri-
vacyconcerns. Ourobservationsdosuggest,however,that
the header can be used today as a reliable CSRFdefense
overHTTPS,makingitparticularlywell-suitedfordefend-
ingagainstloginCSRF.Forthelongterm,weproposethat
browsersimplementtheOriginheader,whichprovidesthe
securitybenefitsoftheRefererheaderwhilerespondingto
privacyconcerns.
CategoriesandSubjectDescriptors
K.6.5 [Management t of Computing g and Information
Systems]: SecurityandProtection
GeneralTerms
Security,Design,Experimentation
Keywords
Cross-SiteRequestForgery,WebApplicationFirewall,HTTP
RefererHeader,Same-OriginPolicy
1. INTRODUCTION
Cross-SiteRequestForgery(CSRF)is amongthetwenty
most-exploited security vulnerabilities of 2007 [10], along
withCross-SiteScripting(XSS)andSQLInjection. Incon-
trasttocross-sitescripting,whichhasreceivedagreatdeal
Permissiontomakedigitalorhard copiesofallorpartofthisworkfor
personalorclassroomuseisgrantedwithoutfeeprovidedthatcopiesare
notmadeordistributedforprofitorcommercialadvantageandthatcopies
bearthisnoticeandthefullcitationonthefirstpage.Tocopyotherwise,to
republish,topostonserversortoredistributetolists,requirespriorspecific
permissionand/orafee.
CCS’08,October27–31,2008,Alexandria,Virginia,USA.
Copyright2008ACM978-1-59593-810-7/08/10...$5.00.
ofattention[14],andtheeffectivemitigation ofSQLinjec-
tion through parameterized SQL L queries s [8], , cross-site e re-
questforgeryhasreceivedcomparativelylittleattention. In
aCSRFattack,amalicioussiteinstructsavictim’sbrowser
tosend arequest toan honest site, as if therequest were
part ofthevictim’s interactionwith the honestsite,lever-
agingthe victim’s network connectivity and the browser’s
state, such as s cookies, , to o disrupt the integrity of f the vic-
tim’ssessionwiththehonestsite.
For example, in late 2007[42], Gmailhad a a CSRFvul-
nerability. WhenaGmailuservisited d amalicious site,the
malicioussitecouldgeneratearequesttoGmailthatGmail
treated as part of its s ongoingsession n with the victim. . In
November 2007, , aweb attacker exploited this s CSRFvul-
nerabilitytoinjectanemailfilterintoDavidAirey’sGmail
account[1].
1
ThisfilterforwardedallofDavidAirey’semail
totheattacker’semailaddress,whichallowedtheattackerto
assumecontrolofdavidairey.combecauseAirey’s domain
registrarusedemailauthentication,leadingtosignificantin-
convenienceandfinancialloss.
Inthispaper,weexaminethescopeanddiversityofCSRF
vulnerabilities,study existingdefenses, and describeincre-
mental andnewdefenses basedonheadersand web appli-
cation firewall rules. . We e introduce login cross-site request
forgery attacks, which h are currently widely possible, dam-
aging, and under-appreciated. . Inlogin n CSRF,an attacker
usesthevictim’sbrowsertoforgeacross-siterequesttothe
honestsite’sloginURL,supplyingtheattacker’susername
and password. . Avulnerablesitewillinterpretthis s request
and logthevictimintothesiteastheattacker. . Manyweb
sites,includingYahoo,PayPal,andGoogle,arevulnerable
tologinCSRF.Theimpactoflogin CSRFattacks varyby
site,rangingfromallowingtheattackertomountXSSat-
tacksonGoogletoallowingtheattackertoobtainsensitive
financialinformationfromPayPal.
Therearethreewidelyusedtechniquesfordefendingagainst
CSRFattacks: validatingasecretrequesttoken,validating
theHTTPRefererheader,and validatingcustomheaders
attached toXMLHttpRequests. . None e of f these e techniques
aresatisfactory,foravarietyofreasons.
1. ThemostpopularCSRFdefenseistoincludeasecret
token with each request and to o validate that t the re-
ceived tokenis correctly bound totheuser’ssession,
preventingCSRFbyforcingtheattackertoguessthe
session’s token. . There e areanumberofvariationson
thisapproach,eachfraughtwithpitfalls,andevensites
1
DavidAireylaterrepudiatedthisincident[2].
Add pdf to powerpoint presentation - C# Create PDF from PowerPoint Library to convert pptx, ppt to PDF in C#.net, ASP.NET MVC, WinForms, WPF
Online C# Tutorial for Creating PDF from Microsoft PowerPoint Presentation
adding pdf to powerpoint slide; change pdf to powerpoint online
Add pdf to powerpoint presentation - VB.NET Create PDF from PowerPoint Library to convert pptx, ppt to PDF in vb.net, ASP.NET MVC, WinForms, WPF
VB.NET Tutorial for Export PDF file from Microsoft Office PowerPoint
pdf page to powerpoint; convert pdf file to powerpoint
thatimplementthetechniquecorrectlyoftenoverlook
theirloginrequestsbecauseloginrequestlackasession
towhichtobindthetoken.
2. The e simplestCSRFdefense is tovalidatetheHTTP
Referer header, , preventing g CSRF by accepting g re-
quests only from m trusted d sources. . Whileeffective e in
principle,thistechniquemustdealwithrequeststhat
lack aRefererheader entirely. . Sites s can either pro-
cess theserequestsorblockthem. . Ifasite e processes
requeststhatlackaRefererheader,thedefenseisinef-
fectivebecausetheRefererheadercanbesuppressed
byanattacker. Ifthesiterefusestoprocessthesere-
quests,our experimentalmeasurements indicatethat
thesitewillexcludeanappreciablefractionofusers.
3. XMLHttpRequest’spopularity y hasincreasedrecently
withmoresitesimplementingAJAXinterfaces. Sites
candefendagainst CSRFbysettingacustomheader
viaXMLHttpRequest andvalidatingthattheheader
is present before processingstate-modifyingrequests.
Althougheffective,thisdefenserequiressitestomake
all state-modifying requests s via XMLHttpRequest, , a
requirementthatpreventsmanynaturalsitedesigns.
ReferervalidationisanappealingCSRFdefense,butthe
techniqueishamperedbythewidespreadsuppressionofthe
Refererheader. Toevaluatethisdefense,weconductedan
experiment to o determine e how frequently, , and d under what
circumstances,Refererheaderisblocked.Weplacedadver-
tisementsontwodifferentadvertisingnetworksthatcaused
283,945browsersdisplayingtheadvertisementstoissuenet-
workrequeststoserversinourlaboratory. Ourresultsshow
that although the Refererheaderissuppressed oftenover
HTTP, the header is rarely suppressed d over r HTTPS, let-
tingcurrentsitespreventCSRFbyusingHTTPSandstrict
Referervalidation.
TocreatearobustCSRFdefense,weproposethatbrowsers
includean“Origin”headerwithPOSTrequests.Thisheader
provides thesecurity benefits of theRefererheader while
addressingtheprivacyconcernsthathaveleadtothewide-
spreadsuppressionoftheRefererheader. TheOriginheader
letssitesdefendagainstCSRFbydeployingafewsimpleweb
applicationfirewallrules. Thismechanismalsoprotectslo-
ginformswithoutrequiringadditionaleffortfromthesite’s
developers.
AlthoughCSRFdefensesarenecessarytoprotectsession
integrity, other session integrityattacks are possible, even
againstsiteswithoutXSSorCSRFvulnerabilities. Wede-
scribe other r attacks on session initialization n in which h the
user becomes authenticated to the honest site e as the e at-
tacker. Although h similar tologin CSRF, these attacks do
notrequire CSRFvulnerabilities. . Wedescribe e session ini-
tialization vulnerabilities in OpenID [13], PHP cookieless
session management[37],andHTTPSSecurecookies[40].
Foreachvulnerability,weproposeanimprovedsessionman-
agementprotocoltopreventattacksonsessioninitialization.
Contributions. Ourmaincontributionsinclude:
1. AnexplanationoftheCSRFthreat t model,including
often-overlooked variations basedonnetworkconnec-
tivity and login CSRF.We demonstrate theseverity
ofloginCSRFvulnerabilitiesbydescribingtheconse-
quencesofthevulnerabilityfor asmallsampleofthe
manywidelyusedwebsitesthatarevulnerable.
2. Astudyofcurrentbrowserbehavior,includingexper-
imental measurement of Referer header r suppression
basedon283,945advertisingimpressionontwoadver-
tisement networks. . Based d on our experimentaldata,
weproposearefinementtoReferervalidation:employ
HTTPSandstrictReferervalidation.Thistechnique
issecurebecausebrowsersensuretheintegrityofthe
Refererheader andis compatiblewith 99.9%of the
webusersweobservedinourexperiment.
3. AproposalforanOriginheaderthatcontainsonlythe
thescheme,host,andportpartsofthereferringURL,
addressingtheprivacyconcernsoftheRefererheader
whilecontainingtheinformationnecessaryforCSRF
defense. Forbrowsers,wehaveimplementedthispro-
posalasa466-lineextensiontoFirefoxandasaeight-
linepatchtoWebKit. Forsites,wehaveimplemented
OriginvalidationinthreelinesofModSecurity,aweb
applicationfirewallforApache.
4. Astudyofrelatedsessioninitializationvulnerabilities
anddefensesforOpenID,PHPcookielesssessions,and
HTTPScookies. Weimplementourcookiedefenseas
a202-lineextensiontoFirefox.
Organization.Theremainderofthepaperisorganizedas
follows. Section2reviewsthethreatmodel. . Section3pro-
videsexamples of login CSRF.Section 4analyzes existing
defenses using g experimental data. . Section n 5proposes the
Originheader as adefensemechanism. . Section6general-
izesloginCSRFtoothersessioninitializationvulnerabilities.
Section7describesrelatedwork. Section8concludes.
2. CSRFDEFINED
Inacross-siterequestforgery(CSRF)attack,theattacker
disrupts the integrityof theuser’s session with aweb site
by injecting networkrequests viatheuser’s browser. . The
browser’s security policy allows web b sites s to send HTTP
requeststoany networkaddress. . Thispolicyallows s anat-
tackerthatcontrolscontentrenderedbythebrowsertouse
resourcesnototherwiseunderhisorhercontrol:
1. Network k Connectivity. . For r example, if the e user
is behind a a firewall, the attacker r is able e to o leverage
theuser’s browser tosend network requests toother
machinesbehindthefirewallthatmightnotbedirectly
reachablefromtheattacker’smachine. Eveniftheuser
isnot behind afirewall, the requests carrytheuser’s
IPaddress and d might confuse services relyingon IP
addressauthentication[36].
2. ReadBrowserState.Requestssentviathebrowser’s
network stack typically y include browser state, , such
as cookies, client certificates, or basic authentication
headers. Sites s that rely on this s authentication n state
mightbeconfusedbytheserequests.
3. WriteBrowserState.Whentheattackercausesthe
browser toissuea a network request, thebrowser r also
parses and acts ontheresponse. . For r example,ifthe
response contains s aSet-Cookie header, , the browser
willmodifyits cookiestore. . Thesemodifications s can
leadtosubtleattacks,whichwedescribeinSection3.
VB.NET PowerPoint: Use PowerPoint SDK to Create, Load and Save PPT
an empty PowerPoint file with our reliable .NET PPT document add-on; a fully customized blank PowerPoint file by using the smart PowerPoint presentation control
table from pdf to powerpoint; change pdf to powerpoint online
VB.NET PowerPoint: Sort and Reorder PowerPoint Slides by Using VB.
index = 1 End If correctOrder.Add(index) Next clip art or screenshot to PowerPoint document slide powerful & profession imaging controls, PDF document, image
change pdf to powerpoint; convert pdf into ppt online
In-ScopeThreats.Weconsiderthreedifferentthreatmod-
els,varyingbyattackercapability:
• Forum m Poster. . Manywebsites,suchasforums,let
users tosupply limited d kinds s of f content. . For r exam-
ple,sitesoftenpermituserstosubmitpassivecontent,
suchasimagesorhyperlinks.Ifanattackerchoosesthe
“image’s”URLmaliciously,thenetworkrequestmight
leadtoaCSRFattack. Theforumpostercanissuere-
questsfromthehonestsite’sorigin,buttheserequests
cannothavecustomHTTPheadersandmustusethe
HTTP“GET”method. AlthoughtheHTTPspecifica-
tion[6]requiresGETrequeststobefreeofsideeffects,
somesitesdonotcomplywiththisrequirement.
• Web b Attacker. . Aweb b attacker isamalicious prin-
cipal who o owns s a a domain name, , e.g. . attacker.com,
hasavalid HTTPScertificatefor attacker.com,and
operates aweb server. . Thesecapabilities s can n all l be
obtainedfor$10. Iftheuservisitsattacker.com,the
attackercanmountaCSRFattackbyinstructingthe
user’s browser to o issue cross-site requests s using g both
theGETandPOSTmethods.
• Network k Attacker. . A A active e network attacker is
amalicious principalwhocontrolstheuser’s network
connection.Forexample,an“eviltwin”wirelessrouter
or a a compromised d DNS server can be exploited d by
anattacker tocontroltheuser’snetworkconnection.
Theseattacksrequiremoreresourcesthanwebattacks,
but weconsider thisthreatin-scopefor HTTPSsites
because HTTPSisdesigned toprotectagainstactive
networkattacks.
Out-of-Scope Threats. . There e are a number of f related
threatmodels wedonotconsiderinthispaper. . CSRFde-
fensesarecomplementarytodefensesagainstthesethreats.
• Cross-siteScripting(XSS).Iftheattackeris s able
toinjectscriptintoasite’ssecurityorigin,theattacker
can disrupt both h the integrity and confidentiality of
the user’s session with the site. . Some e XSS attacks
involve networkrequests,for exampletotransferthe
user’sbankbalancetotheattacker,butCSRFdefenses
donotattempttoguardagainsttheseattacks. Tobe
secure,asitemustimplementXSSandCSRFdefenses.
• Malware. . If f the e attacker is able e to run n malicious
softwareontheuser’smachine,theattackercancom-
promisethe user’s browser andinject script intothe
honest web site’s security origin. . Browser-based d de-
fenses are e helpless s against such h an n attacker r because
the malwareattacker can replacethebrowser witha
browserofmaliciousdesign.
• DNS Rebinding. . Like e CSRF, DNS rebinding[25]
canbeusedtoobtainnetworkconnectivitytoaserver
ofanattacker’schoiceusingthebrowser’sIPaddress.
WebserversthatarebehindfirewallsorthatusetheIP
addressofthebrowsertomakepolicydecisionsrequire
DNSrebindingdefenses. AlthoughDNSrebindingat-
tacks often havea a similar r purposetoCSRFattacks,
theyrequiredifferentdefenses. AsimpleDNSrebind-
ing defense is to validate the Host header of f HTTP
requeststoensurethatitcontainsanexpected value.
AnalternativeDNSrebindingdefenseistofilterDNS
traffic,preventingexternalDNSnamesfromresolving
toprivateIPaddresses.
• Certificate e Errors. . If f the e user is s willing to click
through HTTPS certificate errors, , much h of f the e pro-
tectionaffordedbyHTTPSagainstnetworkattackers
evaporates. Anumberofresearchers[38,31,24]have
addressed this threat model, but, in n this s paper, we
assumeusersdonotclickthroughcertificateerrors.
• Phishing. . Phishing g attacks s [12] occur when an at-
tacker’swebsitesolicitsauthenticationcredentialsfrom
the user. . Phishing g attacks s can be very effective be-
causeusers finditdifficulttodistinguishtherealsite
fromafakewebsite[11].
• User Tracking. . Cross-site e requests can beused by
cooperatingweb sites to build acombined d profile of
a user’s s browsing activities. . Most t browsers include
third-partycookieblockingfeaturesthataredesigned
todiscouragesuchtracking,butthesefeaturescanbe
circumvented[26].
3. LOGINCSRF
Mostdiscussionsofcross-siterequestforgeryfocusonre-
quests that mutate server-side e state, , either r by leveraging
browser’snetworkconnectivityorbyleveragingthebrowser’s
state. CSRF F attacks s that t mutate browser state have re-
ceivedlessattentioneventhoughtheseattacksalsodisrupt
theintegrityoftheuser’ssessionwithhonestsites. Inalogin
CSRFattack,theattackerforgesaloginrequesttoanhon-
estsiteusingtheattacker’susernameandpasswordatthat
site.Iftheforgerysucceeds,thehonestserverrespondswith
aSet-Cookieheader thatinstructs thebrowser tomutate
its state by storinga a session n cookie, loggingtheuser into
thehonestsiteastheattacker. This s session cookieisused
tobindsubsequentrequeststotheuser’ssessionandhence
to the attacker’s authentication n credentials. . Login n CSRF
attackscanhaveseriousconsequences,dependingonother
sitebehavior:
SearchHistory.Manysearchengines,includingYahoo!and
Google, allow w their users s to o opt-in to saving their search
historyandprovideaninterfaceforausertoreview hisor
herpersonalsearchhistory.Searchqueriescontainsensitive
details about theuser’s interests and activities [41, 4]and
couldbeusedbyanattackertoembarrasstheuser,tosteal
theuser’sidentity, ortospy ontheuser. . An n attacker can
spyon auser’s search historybyloggingthe user intothe
searchengineastheattacker;seeFigure1. Theuser’ssearch
queriesarethenstoredintheattacker’ssearchhistory,and
theattackercanretrieve thequeriesbyloggingintohisor
herownaccount.
PayPal.PayPalletsitsuserstransferfundstoeachother.
Tofund aPayPalaccount,usersenrolltheircredit cardor
theirbankaccount. Aweb attackercanuseloginCSRFto
mountthefollowingattack:
1. Thevictimvisitsamaliciousmerchant’ssiteandchooses
topayusingPayPal.
2. Asusual,victimisredirectedtoPayPalandlogsinto
hisorheraccount.
VB.NET PowerPoint: VB Codes to Create Linear and 2D Barcodes on
Here is a market-leading PowerPoint barcode add-on within VB.NET class, which means it as well as 2d barcodes QR Code, Data Matrix, PDF-417, etc.
embed pdf into powerpoint; changing pdf to powerpoint file
VB.NET PowerPoint: Merge and Split PowerPoint Document(s) with PPT
For Each doc As [String] In dirs docList.Add(doc) Next code in VB.NET to finish PowerPoint document splitting If you want to see more PDF processing functions
image from pdf to powerpoint; drag and drop pdf into powerpoint
GE T /search?q=llamas HTTP/1.1
C ookie: SessionID =Z Z A 1Fa34
HTTP/1.1 200 OK
Set-C ookie: SessionID D =ZA A 1Fa34
POST /login HTTP/1.1
Referer: hƩp://www.aƩacker.com/blog
username=aƩacker&password=xyzzy
<form acƟon=hƩps://www.google.com/login
method=POST target=invisibleframe>
<input name=username value=aƩacker>
<input name=password value=xyzzy>
</form>
<script>document.forms[0].submit()</script>
GE T /blog HTTP/1.1
www.aƩacker.com
www.google.com
VicƟm B rowser
Figure1: EventtracediagramforaloginCSRFattack. Thevictimvisitstheattacker’ssite,andtheattacker
forgesacross-siterequesttoGoogle’sloginform,causingthevictimtobeloggedintoGoogleastheattacker.
Later,thevictim makesa web search,whichislogged in the attacker’ssearch history.
3. The e merchantsilently logs thevictiminto his orher
PayPalaccount.
4. To fund her purchase, the victim enrolls s his or her
creditcard,butthecreditcardhasactuallybeenadded
tothemerchant’sPayPalaccount.
iGoogle. UsingiGoogle,users s can customizetheirGoogle
homepagebyincludinggadgets. Forusability,somegadgets
are“inline,”meaning they run in the security context of
iGoogle. Before e adding such h gadgets, users are e asked d to
make atrust decision, butin alogin CSRFattack, aweb
attackermakesthetrustdecisiononbehalfoftheuser:
1. Usinghisorherownbrowser,theattackerauthorsan
inline iGooglegadget (containing amalicious s script)
andaddsittohisorherownpersonalizedhomepage.
2. The attacker logs the e victim into Google as s the at-
tackerandopensaframetoiGoogle.
3. Googlebelievesthevictimtobetheattackerandserves
theattacker’sgadgettothevictim,lettingtheattacker
torunscriptinthehttps://www.google.comorigin.
4. The attacker can now w either r (a) ) create a a fake e login
pageatthecorrectURL,(b)stealtheuser’sautocom-
pletedpassword,or(c)waitfortheusertologinusing
anotherwindowandreaddocument.cookie.
We disclosed this vulnerability y to Google, , and they y have
mitigated the vulnerability in n twoways. . First, , they have
deprecatedtheuseofinlinegadgets.Developerscannotcre-
atenew inlinegadgets, and onlya a few w of themost popu-
lar inlinegadgets are still allowed [22]. . Second, , theyhave
deployed the secret token validation n defense e against t login
CSRF (discussed d below), but the defenseis deployed only
inloggingmode. WeexpectGoogletobegin n denyinglogin
CSRFattemptsoncetheyhavefullytestedtheirdefense.
4. EXISTINGCSRFDEFENSES
There arethreemechanisms asite can usetodefend it-
self against cross-site request forgeryattacks: : validatinga
secrettoken,validatingtheHTTPRefererheader,andin-
cluding additional headers s with XMLHttpRequest. . Allof
thesemechanismsareinuseonthewebtoday,butnoneof
themareentirelysatisfactory.
4.1 SecretValidationToken
One approach to defending against CSRFattacks is to
sendadditionalinformationineachHTTPrequestthatcan
be used d to determine e whether r the e request t came e from an
authorized source. . This“validationtoken”should d be hard
to guess s for attacker whodoes not alreadyhave access to
theuser’saccount. Ifarequestismissingavalidationtoken
orthetokendoes notmatchtheexpectedvalue,theserver
shouldrejecttherequest.
Secret validationtokenscan defendagainstloginCSRF,
but developers s often n forget to implement the e defense e be-
cause, before e login, , there is no o session to which to bind
the CSRFtoken. . To o use secret validation n tokens s topro-
tect against login CSRF, the sitemust first createa“pre-
session,”implementtoken-basedCSRFprotection,andthen
transitiontoarealsessionaftersuccessfulauthentication.
TokenDesigns.Thereareanumbertechniquesforgener-
atingandvalidatingtokens:
• SessionIdentifier.Thebrowser’scookiestoreisde-
signedtopreventunrelateddomainsfromgainingac-
cesstoeachother’scookies. Onecommondesignisto
usetheuser’ssessionidentifierasthesecretvalidation
token. Oneveryrequest,theservervalidatesthatthe
tokenmatchestheuser’ssessionidentifier. Anattacker
whocanguessthevalidationtokencanalreadyaccess
theuser’saccount.Onedisadvantageofthistechnique
isthat,occasionally,users revealthecontents ofweb
VB.NET PowerPoint: Add Image to PowerPoint Document Slide/Page
of "AddPage", "InsertPage" and "DeletePage" to add, insert or delete any certain PowerPoint slide without & profession imaging controls, PDF document, tiff
pdf into powerpoint; how to change pdf to powerpoint slides
C# PDF Text Extract Library: extract text content from PDF file in
text content from source PDF document file for word processing, presentation and desktop How to C#: Extract Text Content from PDF File. Add necessary references
convert pdf back to powerpoint; how to add pdf to powerpoint presentation
pagestheyviewtothirdparties,forexampleviaemail
oruploadingthewebpagetoabrowservendor’s bug
trackingdatabase.Ifthepagecontainstheuser’sses-
sion identifier in the form m of f a a CSRF token, anyone
who reads s thecontents of the page can impersonate
theusertothewebsiteuntilthesessionexpires.
• Session-IndependentNonce. Instead d ofusingthe
user’ssessionidentifier,theservercangeneratearan-
domnonceandstoreitasacookiewhentheuserfirst
visitsthesite. On n everyrequest,the server validates
thatthetokenmatchesthevaluestoredinthecookie.
Forexample,thewidelyusedTracissuetrackingsys-
tem [49] implements this technique. . This s approach
fails toprotectagainstactivenetworkattackers,even
if the entireweb b application n is hosted over HTTPS,
because anactivenetworkattackercanoverwritethe
session-independent nonce (see e Section n 6.2) with his
orher own CSRFtokenvalueandproceedtoforgea
cross-siterequestwithamatchingtoken.
• Session-Dependent Nonce. . An n refinement of the
nonce technique is s to store e state on n the e server r that
bindstheuser’sCSRFtokenvaluetotheuser’ssession
identifier. Oneveryrequest,theservervalidatesthat
thesuppliedCSRFtokenisassociatedwiththeuser’s
sessionidentifier. ThisapproachisusedbyCSRFx[19],
CSRFGuard[48],andNoForge[30]buthasthedisad-
vantagethatthesitemustmaintainalargestatetable
inordertovalidatethetokens.
• HMACofSessionIdentifier.Insteadofusingserver-
sidestatetobindtheCSRFtokentothesessioniden-
tifier, the site can use cryptography tobind thetwo
values. Forexample,theRubyonRails[46]webappli-
cationframeworkimplementsthistechniqueand uses
theHMAC ofthesession identifierasaCSRFtoken.
Aslongasallthesite’s serverssharetheHMACkey,
each servercanvalidatethattheCSRFtoken is cor-
rectly bound to the e session identifier. . Properties s of
HMAC ensure e that t an attacker who learns a user’s
CSRFtokencannotinfertheuser’ssessionidentifier.
Given sufficient t engineering g resources, , a a web b site can use
theHMACtechniquetodefenditselfagainstCSRFattacks.
However, many web sites s and CSRF F defense frameworks
(such as NoForge [30], CSRFx [19]and CSRFGuard [48]),
fail toimplement the secret token n defense e correctly. . One
common mistakeis toleak theCSRF F token n duringcross-
siterequests. For r example,if the honest siteappendsthe
CSRFtokentohyperlinksanothersites,thatsitegainsthe
abilitytoforgecross-siterequestsagainstthehonestsite.
Case Study: : NoForge. . NoForge[30]implements s CSRF
defenseusing secret t validation token bound tothesession
identifier usingserver-sidestate. . Instead d of modifyingthe
webapplicationtohandletheCSRFtoken,NoForgeparses
the site’s s HTML as s it is serialized onto the e network k and
appendstheCSRFtokentoallhyperlinksandformsubmis-
sions. Thistechniqueisnotrobustforthreereasons:
1. HTML dynamically created in the e browser r will not
bere-written toincludetheCSRFtoken. . Somesites
createmostoftheirHTMLontheclient. Forexample,
Gmail, Flickr, , and Digg all use JavaScript tocreate
formsthatrequireCSRFprotection.
2. NoForgedoesnotdiscriminatebetweenhyperlinksback
to the web b application and d hyperlinks to other r web
sites. Ifthewebapplicationlinkstoanothersite,the
remotesitewillreceiveacopyoftheuser’sCSRFto-
ken. For r example, , if phpBB [44] adopted d NoForge,
forumposterswouldreceiveacopyoftheuser’sCSRF
token if the user r clicked a link k in their r post. . Even
ifNoForgediscriminatedbetweensame-siteandcross-
sitehyperlinks,theHTTPRefererheaderwouldleak
theuser’sCSRFtoken.
3. NoForgedoesnotdefendagainstloginCSRFbecause
it only validates the CSRFtoken if the user already
has asessionidentifier. . Although h thisoversightisre-
pairable,itdemonstratesthecomplexityofimplement-
ingsecrettokenvalidationcorrectly.
Althougheach is repairable, thesevulnerabilitiesillustrate
thecomplexityofimplementingthe secretvalidation tech-
niquecorrectly. CSRFxandCSRFGuard,as s wellas many
websites,containsimilarissues.
4.2 TheRefererHeader
Inmanycases,whenthebrowserissuesanHTTPrequest,
itincludesaRefererheaderthatindicateswhichURLini-
tiated therequest. . TheRefererheader,ifpresent,distin-
guishesasame-siterequestfromacross-siterequestbecause
theheadercontainstheURLofthesitemakingtherequest.
Asitecandefenditselfagainstcross-siterequestforgeryat-
tacksbycheckingwhethertherequestinquestionwasissued
bythesiteitself.
Unfortunately,theReferercontainssensitiveinformation
that impingesontheprivacy ofweb users[18]. . For r exam-
ple, the Referer header reveals the contents of thesearch
querythatleadtheusertovisitaparticularsite. Although
this information n is useful to o web b site owner, whocan use
the information n to o optimize e their search engine rankings,
thisinformationdisclosureleadssomeuserstofeeltheirpri-
vacy has been violated. . Additionally, , many y organizations
areconcerned[28]thatconfidentialinformationabouttheir
corporateintranetsmightleaktoexternalwebsitesviathe
Refererheader.
Bugs.Historically,browsersandhavecontainedvulnerabil-
itiesthatletmaliciouswebsitesspoofvalueoftheReferer
header, especiallyin conjunction with proxy servers. . Dis-
cussionsofRefererspoofingoftencite[32]asevidencethat
browsers permit t the Referer r header r to o spoofed. . Mozilla
has patched the e Referer spoofing g vulnerabilities s in n Fire-
fox1.0.7[15]. Internet t Explorer currentlycontainsknown
Refererspoofingvulnerabilities[47],but thesevulnerabili-
ties affect onlyXMLHttpRequest andcanbeused onlyto
spoofReferersdirectlybacktotheattacker’sownsite.
Strictness.IfasiteelectstousetheRefererheadertode-
fendagainstCSRFattacks,thesite’sdevelopersmustdecide
whetherimplementlenientorstrictReferervalidation.
• Inlenient Referer validation,thesite blocks s requests
whoseRefererheader has anincorrectvalue. Ifare-
quests lacksthe header, the siteaccepts therequest.
Althoughwidelyimplemented,lenientReferervalida-
tioniseasilycircumventedbecauseawebattackercan
causethebrowsertosuppresstheRefererheader[27].
Forexample,requestsissuedfromftpanddataURLs
donotcarryRefererheaders.
C# Create PDF from OpenOffice to convert odt, odp files to PDF in
In order to run the sample codes, the following steps would be necessary. Add necessary references: RasterEdge.XDoc.PDF.dll. RasterEdge.XDoc.PowerPoint.dll.
image from pdf to ppt; converting pdf to powerpoint
VB.NET Create PDF from OpenOffice to convert odt, odp files to PDF
In order to run the sample codes, the following steps would be necessary. Add necessary references: RasterEdge.XDoc.PDF.dll. RasterEdge.XDoc.PowerPoint.dll.
convert pdf into powerpoint online; how to convert pdf file to powerpoint presentation
• In n strict Referer r validation, the site also blocks s re-
queststhatlackaRefererheader. Blockingrequests
thatlackaRefererheaderprotectsagainstmalicious
Referersuppressionbutincursacompatibilitypenalty
assomebrowsersandnetworkconfigurationssuppress
theRefererheaderforlegitimaterequests. Themag-
nitude of this compatibility y penalty y is an empirical
question,whichweinvestigateinSection4.2.1.
Case Study: : Facebook. Throughoutthemajorityof f its
site,Facebookusessecrettokenvalidationtoprotectagainst
CSRF.Facebook’sloginform,however,useslenientReferer
validationtodefendagainstCSRFattacks. This s approach
tologinCSRFprotectionisineffectiveagainstwebattackers.
Forexample,awebattackercanredirecttheuserfromhttp:
//attacker.com/toftp://attacker.com/index.htmland
then issue across-site loginrequest toFacebook. . Because
itoriginatesfromanftpURL,noneofthemajorbrowsers
sendaRefererheader.
4.2.1 Experiment
ToevaluatethecompatibilityofstrictReferervalidation,
weconductedanexperimenttomeasurehowoften,andun-
derwhich circumstances,theRefererheaderissuppressed
duringlegitimaterequests.
Design.Advertisementnetworksprovideaconvenientplat-
formformeasuringbrowserandnetworkcharacteristics[25].
Toassess how often theRefererheader is suppressed, we
purchased283,945advertisementimpressions from163,767
uniqueIPaddressesusingtwoadvertisementnetworksfrom
5April2008to8April2008. On n Ad Network A,wepur-
chased banner r advertisements s by y bidding $0.50 per r thou-
sand impressions for the keywords“Firefox,”“Game,”“In-
ternet Explorer,”“Video,”and d “YouTube.” ” On n Ad d Net-
workB,wepurchasedinterstitialadvertisementsbybidding
$5perthousandimpressionsforthekeywords“Ballet,”“Fi-
nance,”“Flowers,”“Food,”and“Gardening.”Wespent$100
oneachadnetwork,obtaining241,483impressions(146,310
uniqueIPaddresses)onAd NetworkAand42,406impres-
sions(18,314uniqueIPaddresses)onAdNetworkB.
Theadvertisement wasservedfromtwomachines in our
laboratory. Theserversusedtwodomainnamespurchased
throughseparateregistrars. Whendisplayed,theadvertise-
mentgeneratesauniqueidentifierthataccompaniesallsub-
sequentrequestsgeneratedbytheimpressionandrandomly
choosesoneof thetwomachinestobetheprimary server.
The primary y server r sends s the client t HTML that t issues a
sequence ofGET and POST requests toour servers, both
over HTTP andHTTPS.Therequests are generated pro-
grammaticallybysubmittingforms,requestingimages,and
issuingXMLHttpRequests. Therequestsaregeneratedina
randomorderandoccurautomaticallywithoutinvolvingthe
user. When n permitted bythebrowser security policy,the
advertisementgenerates bothsame-domainrequeststothe
primaryserverandcross-domainrequeststothesecondary
server. Each h server cost $400, each domain name cost $7,
and each 90-day domain-validated HTTPS certificate was
obtainedforfreefromalegitimatecertificateauthority.
Upon receiving network k requests, , the e servers s logged d a
numberofrequestparameters,includingtheRefererheader,
the User-Agent header, the date, the client’s class C net-
work,andthesessionidentifier.UsingJavaScript,theservers
recordedthevalueofdocument.referrerDOMAPIaswell.
The servers did not logthe client’s IPaddress. . To o count
uniqueIPaddresses,theserversinsteadlogged theHMAC
oftheclient’s IPaddress usingarandomly generated key,
whichwasdiscarded. Noneoftheinformationrecordedby
theserversissufficienttoindividuallyidentifytheviewerof
theadvertisement.
Ethics. Theexperimentaldesigncompliedwith h theterms
ofserviceofbothadvertisementnetworks. Theactionstaken
bytheexperimentareroutineforwebadvertisements,which
typically requestadditional resources from advertisers, in-
cluding images, audio, and d video. . While e the e number r of
HTTP requests generated d by y our r advertisement t is s likely
greaterthanatypicaladvertisement,thebandwidthrequired
torunouradvertisementissignificantlysmallerthanatyp-
icalvideoadvertisement. Theservers s loggedonlyinforma-
tion that is typically logged by advertisers when their ad-
vertisements are e displayed. . By y not recording the client’s
IP address, our servers actually recorded significantlyless
informationthanisrecordedbycommercialadvertisers.
Results.OurobservationsaresummarizedinFigure2and
Figure3. Weobservethefollowingresultsatthe95%con-
fidencelevel:
• Over r HTTP,the Referer r header r is suppressed more
oftenforcross-domainrequeststhanforsame-domain
requests,both forPOST (chi-square= 2130, p-value
<0.001) andforGET (chi-square=2175,p-value<
0.001)requests.
• TheRefererheaderissuppressedmoreoftenforHTTP
requeststhanHTTPSrequestsforcross-domainPOST
(chi-square=6754,p-value<0.001),forcross-domain
GET (chi-square=6940,p-value< 0.001),forsame-
domain POST(chi-square= 2286, p-value< 0.001),
andforsame-domainGET(chi-square=2377,p-value
<0.001)requests.
• OverHTTP,theRefererheaderissuppressedmoreof-
tenthanthedocument.referrervalueforcross-domain
POST(chi-square=3096,p-value<0.001),forcross-
domain GET (chi-square e = = 3146, p-value < < 0.001),
for same-domainPOST (chi-square=786, p-value<
0.001),andforsame-domainGET(chi-square=754,
p-value<0.001)requests.
• TheRefererheader r is suppressed moreoften on Ad
NetworkBthan onAd NeworkAfor alltypesof re-
quest,includingHTTPcross-domainPOST(chi-square
=3060,p-value<0.001),HTTPsame-domainPOST
(chi-square= 6537, p-value <0.001), HTTPS cross-
domainPOST (chi-square=49.13,p-value<0.001),
andHTTPSsame-domainPOST(chi-square=44.52,
p-value<0.001)requests.
• Wealsomeasured d suppressionof thecustomheaders
X-Requested-By(seeSection4.3)andOrigin(seeSec-
tion 5). . X-Requested-By y was s suppressed d for 0.029–
0.047% of f HTTP P POST requests, , for 0.084–0.112%
of HTTPGET requests,for0.008–0.018%ofHTTPS
POSTrequests,andfor0.009–0.020%ofHTTPSGET
requests.Originwassuppressedforthesamerequests.
Discussion. Thereare e twostrongpieces of evidencethat
theRefererheaderisusuallysuppressedinthenetworkand
notinthebrowser.
0%
2%
4%
6%
8%
10%
12%
h�ps://x → h�ps://x POST
h�ps://x → h�ps://x GET
h�ps://x → h�ps://y POST
h�ps://x → h�ps://y GET
h�p://x → h�p://x POST
h�p://x → h�p://x GET
h�p://x → h�p://y POST
h�p://x → h�p://y GET
Ad Network A
Ad Network B
Figure 2: : Requests s with a a Missing or r Incorrect Referer Header r (283,945 observations). . The e “x” and “y”
representthedomain namesoftheprimaryand secondaryweb servers,respectively.
1. TheRefererheaderissuppressedmoreoftenforHTTP
requests than for HTTPS requests because network
proxiesareabletoremovetheheaderfromHTTPtraf-
fic but areunabletotamper withHTTPStraffic. . In
some corporate networks, anetwork proxy serves s as
theHTTPS endpointandcanalterHTTPS requests,
butthisconfigurationisfairlyrare.
2. Browsers s that suppress the Refererheader alsosup-
pressthedocument.referrervalue,butwhenReferer
issuppressedinthenetwork,thedocument.referrer
valueis not suppressed. . If f theReferer header were
suppressedinthebrowser,thebrowserwouldalsosup-
pressthevalueofdocument.referrer,butweobserved
that the document.referreris suppressed less s often
thantheRefererheader.
Infact,mostobservationsof thedocument.referrervalue
beingsuppressed are e explainable by y two o facts s about t spe-
cificbrowsers: thePlayStation3browserdoesnotsupport
document.refererandOperasuppressesdocument.referrer
(butnottheRefererheader)forcross-siteHTTPSrequests.
The higher percentage of Referer r suppression for XML-
HttpRequest is duetoabuginFirefox1.0and1.5. . These
observationsindicatesthatextremelyfewbrowsersarecon-
figuredtoblockreferrers.
There is s also evidence e that the Referer header r is sup-
pressed due toprivacyconcerns. . Theuser’sprivacyis s de-
gradedtoagreaterextentwhenthebrowsersendsaReferer
header from one e site to another because the second site
learns about theuser’sactivitieson thefirst site. . Bycon-
trast,sendingaRefererheaderbacktothesamesitedoes
notincurmuchprivacycostbecausethesitecaneasilycor-
relate multiple requests from the same user usingcookies.
We observed moreRefererblockingfor cross-siterequests
than forsame-siterequests,suggestingthattheentitysup-
pressingtheheader is cognizant of thedifferential privacy
impactofthesetypesofrequests.
Conclusions.Wedrawtwomainconclusions:
1. CSRF F DefenseoverHTTPS.TheRefererheader
can beused asaCSRFdefense for HTTPS requests.
In order to o use the Referer header r as s a CSRF de-
fense,asitemustrejectrequeststhatomittheheader
because an n attacker can n cause the browser to o sup-
press the e header. . Over r HTTP, sites s cannot t afford
toblockrequeststhatlackaRefererheaderbecause
they would d cease e to o be compatible e with the sizable
percentage (roughly3–11%) of users. . Over r HTTPS,
however, strict Referervalidation is feasiblebecause
onlyatiny percentage (0.05–0.22%)of browsers sup-
presstheheader. Inparticular,strictReferervalida-
tionis well-suitedforpreventinglogin CSRFbecause
loginrequestsaretypicallyissuedoverHTTPS.
2. Privacy y Matters. . Strict t Referer validation is s an
appealingCSRFdefensebecausethedefenseissimple
toimplement. Unfortunately, , the poor privacy prop-
erties oftheRefererheader hamperattempts touse
theheader for security over HTTP. New browser se-
curity features, including new CSRFdefensemecha-
nisms, must address privacyconcerns in order to be
effectiveinlarge-scaledeployments.
4.3 CustomHTTPHeaders
CustomHTTPheaderscanbeusedtopreventCSRFbe-
causethebrowserpreventssitesfromsendingcustomHTTP
headerstoanothersitebutallowssitestosendcustomHTTP
headers tothemselves usingXMLHttpRequest. . For r exam-
ple,theprototype.jsJavaScript library[45]uses thisap-
proach and d attaches the X-Requested-By y header r with the
value XMLHttpRequest. . Google e Web Toolkit also o recom-
mends[16]thatwebdevelopersdefendagainstCSRFattacks
byattachingaX-XSRF-CookieheadertoXMLHttpRequets
thatcontainsacookievalue. Thecookievalueisnotactu-
ally required toprevent CSRFattacks: : themerepresence
oftheheaderissufficient.
To use custom headers as s a a CSRF defense, a site must
issue all state-modifying requests usingXMLHttpRequest,
attach the customheader (e.g., X-Requested-By), and re-
ject allstate-modifyingrequeststhat are notaccompanied
bytheheader. Forexample,todefendagainstloginCSRF,
the sitemustsendthe user’s authentication credentials to
0%
1%
2%
3%
4%
h�ps://x → h�ps://x
h�ps://x → h�ps://y
h�p://x → h�ps://x
h�p://x → h�ps://y
h�p://x → h�p://x
h�p://x → h�p://y
h�ps://x → h�p://x
h�ps://x → h�p://y
Image
Form
document.referrer
XMLH�pRequest
99.5%
99.7%
Opera
Firefox 1.x
Firefox 1.x
PS
PS
PS
PS
PS
PS
Figure3: RequestswithaMissingorIncorrectRefererHeaderonAdNetworkA(241,483observations). Opera
blockscross-sitedocument.referrerforHTTPS.Firefox1.0and1.5donotsendRefererforXMLHttpRequest
due toabug. . ThePlayStation3(denotedPS)doesnotsupportdocument.referrer.
the server viaXMLHttpRequest. . In n our r experiment, the
X-Requested-Byheaderiscorrectlydeliveredtoserversap-
proximately99.90–99.99%ofthetime,suggestingthatthis
techniqueworksforalargepercentageofusers.
5. PROPOSAL:ORIGINHEADER
TopreventCSRFattacks,weproposemodifyingbrowsers
tosendaOriginheaderwithPOSTrequeststhatidentifies
theoriginthatinitiated therequest. . Ifthebrowsercannot
determinetheorigin,thebrowsersendsthevaluenull.
Privacy.TheOriginheaderimprovesontheRefererheader
byrespectingtheuser’sprivacy:
1. The e Originheader includes only the information re-
quiredtoidentifytheprincipalthat initiated there-
quest(typicallythescheme,host,and portoftheac-
tivedocument’sURL).Inparticular,theOriginheader
doesnotcontainthepathorqueryportionsoftheURL
included in the Referer r header r that invade privacy
withoutprovidingadditionalsecurity.
2. The Origin n header r is s sent only for r POST T requests,
whereas the Referer header r is sent t for all l requests.
Simplyfollowingahyperlink(e.g.,fromalistofsearch
resultsorfromacorporateintranet)doesnotsendthe
Originheader,preventingthemajorityof accidental
leakageofsensitiveinformation.
By respondingtoprivacy concerns,theOriginheaderwill
likelynotbewidelysuppressed.
Server Behavior. . Touse e the Originheader as aCSRF
defense,sitesshouldbehaveasfollows:
1. Allstate-modifyingrequests,includingloginrequests,
mustbesentusingthePOSTmethod[6]. Inparticu-
lar,state-modifyingGETrequestsmustbeblockedin
ordertoaddresstheforumposterthreatmodel.
2. IftheOriginheaderispresent,theservermustreject
anyrequests whose Originheadercontainsanunde-
siredvalue(includingnull).Forexample,asitecould
rejectallrequestswhoseOriginindicatedtherequest
wasinitiatedfromanothersite.
Security Analysis. . Although h the e Origin header r has a
simpledesign,theuseoftheheaderasaCSRFdefensehas
anumberofsubtleties.
• Rollback and Suppression. . Because e asupporting
browser willalways includethe Originheader when
making POST T requests, , sites s can detect that a a re-
quest was initiated by y a supporting browser r by y ob-
servingthe presence of the header. . This s design pre-
vents an attacker from m makingasupportingbrowser
appear to be anon-supporting browser. . Unlike e the
Refererheader, which is absentwhen suppressedby
thebrowser,theOriginheadertakesonthevaluenull
whensuppressedbythebrowser.
• DNS S Rebinding. . In n existingbrowsers,TheOrigin
headercanbespoofedforsame-siteXMLHttpRequests.
Sites that t rely y only on n network k connectivity for au-
thenticationshoulduseoneoftheDNSrebindingde-
fensesinSection2,suchasvalidatingtheHostheader.
This requirementiscomplementarytoCSRFprotec-
tion and also o applies s toallthe other existingCSRF
defensesdescribedinSection4.
• Plug-ins.Ifasiteoptsintocross-siteHTTPrequests
viacrossdomain.xml,anattackercanuseFlashPlayer
tosettheOriginheaderincross-siterequests. Opting
intocross-siteHTTP requests also defeats secret to-
kenvalidationCSRFdefensesbecausethetokensleak
during cross-site e HTTP P requests. . To o prevent these
(and other) ) attacks, sites s should d not t opt t into cross-
siteHTTPrequestsfromuntrustedorigins.
Adoption.TheOriginheaderissimilartofourotherpro-
posals thatidentify theinitiator of arequest. . TheOrigin
header improves and unifies s these e proposals and has been
adoptedbyseveralworkinggroups.
• Cross-SiteXMLHttpRequest.Theproposedstan-
dard for r cross-site e XMLHttpRequest [50] ] included a
Access-Control-Originheader toidentifytheorigin
issuingtherequest. ThisheaderissentforallHTTP
methods, but it is sent t only for r XMLHttpRequests.
OurspecificationfortheOriginheaderismodeledoff
thisheader. Theworkinggroupacceptedourproposal
torenametheheadertoOrigin.
• XDomainRequest. . TheXDomainRequestAPI[39]
inInternetExplorer8Beta1sendscross-siteHTTPre-
queststhatomitthepathandqueryfromtheReferer
header. Thistruncated d Refererheaderidentifiesthe
origin of the request. . Our r experimental l results s sug-
gest that t the e Referer header r is frequently y blocked
by the network, whereas the Origin header israrely
blocked. Microsofthas s announced that it will adopt
our suggestion n and d rename XDomainRequest’s trun-
catedRefererheadertoOrigin.
• JSONRequest. . The e JSONRequest API for r cross-
siteHTTPrequests[7]includedaDomainheaderthat
identifiesthehostnameoftherequester. TheOrigin
improves on n the Domain n header r by including g the re-
quester’s scheme and port. . The e JSONRequest spec-
ification editor accepted our r proposal l toreplace the
DomainheaderwiththeOriginheaderinordertode-
fendagainstactivenetworkattackers.
• Cross-Document t Messaging. . TheHTML L 5spec-
ification proposes s a a new browser API I for r authenti-
catedclient-sidecommunicationbetweenHTMLdocu-
ments[20]. Eachmessageisaccompaniedbyanorigin
propertythatcannotbeoverwritten. Theprocessfor
validatingthispropertyisthesameastheprocessfor
validatingtheOriginheader,except thatthevalida-
tionoccursontheclientratherthanontheserver.
Implementation. Weimplementedboth h thebrowserand
servercomponentsoftheOriginheaderCSRFdefense. On
the browser side, weimplemented theOriginheader in a
eight-linepatch toWebKit,theopen sourcecomponent of
Safari,andina466lineextensiontoFirefox. Ontheserver
side,weusedtheOriginheadertoimplementawebappli-
cationfirewallforCSRFinthreelinesofModSecurity,aweb
applicationfirewalllanguageforApache;seeFigure4.These
rulesvalidatethat,forPOSTrequests,theHostheaderand
theOriginheadercontainanacceptablevalues.Theserules
implementCSRFprotectionwithoutmodificationtothesite
itself, provided d GET T requests s are free of sideeffects (and
thatbrowsersimplementtheOriginheader).
6. SESSIONINITIALIZATION
Login CSRF is s one example of f a more e general class s of
vulnerabilities in session n initialization. . After r initializinga
session, theweb server typicallyassociates auser identity
withsomeformasessionidentifier. Therearetwotypes of
sessioninitializationvulnerabilities,oneinwhichtheserver
associatesthehonestuser’s identitywith thenewlyinitial-
izedsessionandanotherin whichtheserverassociatesthe
attacker’sidentitywiththesession.
• AuthenticatedasUser.Insomecases,theattacker
can forcethesite touse apredictablesession identi-
fierforanewsession. Thesevulnerabilitiesareoften
referredtoas session fixation n vulnerabilities s (see, for
example,[52]). Aftertheusersuppliestheirauthenti-
cationcredentialstothehonestsite,thesiteassociates
the user’s s authorization with h the predictable session
identifier. The e attacker can then access the e honest
site direct using the session identifier andcan act as
theuser.
• Authenticated as s Attacker. . Alternately, , the at-
tackercausethehonestsitetobeginanewsessionwith
theuser’sbrowserbutforcethesessiontobeassociated
withtheattacker’sauthorization. (Section3contains
examples ofhow thisvulnerabilitycan beexploited.)
Thesimplestformofthistypeofsessioninitialization
vulnerabilityisloginCSRF,butthereareother ways
toforcetheuser’s browser toparticipateinasession
associatedwiththeattacker.
Therearetwocommonapproachestomountinganattackon
session initialization: : HTTPrequests s and cookieoverwrit-
ing. IntheHTTPrequestsapproach,awebattackercauses
theuser’sbrowsertoissueHTTPrequeststothehonestsite
andconfusethesiteintoincorrectlyinitializingasession. In
thecookieoverwritingapproach,anetworkattacker usesa
design flaw inSecurecookies tooverwriteHTTPScookies
fromanunauthenticatedHTTPconnection.
6.1 HTTPRequests
OpenID. The OpenID protocol [13], used by y many web
sitesincludingLiveJournal,MovableType,andWordpress,
recommendsthatsitesincludeaself-signednoncetoprotect
against reply attacks, but does not t suggest (nor r do sites
implement) a mechanism m to bind d the OpenID session to
the user’s browser, lettinga web attacker r force e the user’s
browsertoinitializeasessionauthenticatedastheattacker:
1. Usinghisorherownmachine,thewebattackervisits
theRelyingParty(suchasBlogger)andbeginstheau-
thenticationprocess withtheIdentityProvider (such
asYahoo!).
2. In the final l step p of f the e OpenID protocol, , the Iden-
tity Provider r redirects s the attacker’s browser r to the
“return_to”URLoftheRelyingParty.
3. Insteadoffollowingtheredirect,theattacker directs
theuser’sbrowsertothereturn_toURL.
4. TheRelyingPartycompletestheOpenIDprotocoland
storesasessioncookieintheuser’sbrowser.
5. Theuserisnowloggedinastheattacker.
Thespecificationstates“thereturn_toURLMAYbeused
as a mechanism for the e Relying Party y to attach context
abouttheauthentication request totheauthentication re-
sponse,”but this behavior is neither required nor imple-
mentedbyLiveJournal,MovableType,orWordpress.
SecRule REQUEST_HEADERS:Host !^www\.example\.com(:\d+)?$ deny,status:403
SecRule REQUEST_METHOD ^POST$ chain,deny,status:403
SecRule REQUEST_HEADERS:Origin n !^(https?://www\.example\.com(:\d+)?)?$
Figure4: ModSecurityrules s neededtoimplement CSRF protection usingtheOriginheader.
Todefendagainsttheseattacks,theRelyingPartyshould
generateafreshnonceatthestartoftheprotocol,storethe
nonceinthebrowser’scookiestoreandincludethenoncein
thereturn_toparameteroftheOpenIDprotocol.Uponre-
ceivingapositiveidentityassertionfromtheuser’sIdentity
Provider,theReplyingPartyshouldvalidatethatthenonce
included in thereturn_to o URLmatches s the nonce stored
thecookiestore. Thisdefenseissimilartothesecrettoken
validationtechniqueandensuresthattheOpenIDprotocol
sessioncompletesonthesamebrowserasitbegan.
PHP Cookieless Authentication. . PHP P cookieless s au-
thentication[37]isusedbysiteslikeHushmailtoavoidleav-
ingcookiesontheuser’smachine. Cookielessauthentication
storestheuser’s session identifier in aqueryparameterin-
stead. Thistechniquefailstobindthesessiontotheuser’s
browser, lettingaweb attacker forcetheuser’sbrowser to
initializeasessionauthenticatedastheattacker:
1. Usinghis s or her ownmachine, theweb attacker logs
intothehonestwebsite.
2. The e web attacker redirects the user’s browser tothe
URLcurrentlydisplayedintheattacker’slocationbar.
(Recall that t the e web attacker can navigate any top-
levelframeintheuser’sbrowser[5].)
3. BecausethisURLcontainstheattacker’ssessioniden-
tifier,theuserisnowloggedinastheattacker.
Topreventthissessioninitializationattackwithoutcookies,
asitemust use someothermechanism m tobindtotheses-
sionidentifiertotheuser’sbrowsers. Forexample,thesite
couldmaintainalong-livedframethatcontainsthesession
identifier token. . Thisframebinds s thesessiontotheuser’s
browserbystoringthesessionidentifierinmemory.
SitesthatusePHPcookielessauthenticationoftencontain
asessioninitializationvulnerabilitythatletsawebattacker
impersonateanhonestuser:
1. Usinghisorherownmachine,thewebattackervisits
thehonestwebsite’sloginpage.
2. The e web attacker redirects the user’s browser tothe
URLcurrentlydisplayedintheattacker’slocationbar.
(Recall that t the e web attacker can navigate any top-
levelframeintheuser’sbrowser[5].)
3. Theuserreadthelocationbar,accuratelydetermines
thatdisplayedURLcorrespondstothehonestsite,and
logsintothesite.
4. Because e the URL supplied by the attacker r contains
theattacker’s session identifier,theattacker’ssession
isnowauthenticatedastheuser.
Thissessionfixationvulnerabilityhasanumberofstandard
defenses[9]. Forexample,thesitecanregeneratethesession
identifieraftertheuserlogsin.
6.2 CookieOverwriting
Vulnerability.AservercanincludetheSecureflaginthe
Set-Cookieheader toinstructthebrowserthatthecookie
should besent onlyoverHTTPS connections. . All l modern
browsersrespectthisattribute,anditiscommonlyusedto
protectsessionsathigh-securitysites. However,theSecure
flagdoesnotofferanyintegrityprotection[40,35,34]inthe
cross-schemethreatmodel. Anactivenetworkattackercan
supplyaSet-CookieheaderoveraHTTPconnectiontothe
samehostnameasthesiteandinstalleitheraSecureora
non-Securecookie of f the e same name. . When n the browser
sends thecookiebacktothesiteoverHTTPS,thesitehas
nomechanismfordeterminingwhetherthecookiehasbeen
overwrittenbytheattacker. If f the Securecookiecontains
theuser’ssessionidentifier,theattacker canmountanat-
tackonsessioninitializationsimplybyoverwritingtheuser’s
sessionidentifierwithhisorherownsessionidentifier.
Most often, , this s attack can be e used d to o force the user’s
browsertoinitializeasessionauthenticatedastheattacker.
Thereislittlesitescandotoprotectthemselvesfromthisat-
tackbecausetheyrequirethebrowsertoprovideclient-side
storagewith integrityagainst networkattackers. . However,
someproposedbrowserfeatures,suchaslocalStorage[21],
providetheneededintegritytoworkaroundthedeficiencies
of the e Cookie e header. . Alternately, , if asite e maintains its
application-layerauthenticationsessionindependentlyofits
cookie-based HTTP-layer session, a network attacker can
overwrite the user’s session cookie prior r to authentication
andactastheuseraftertheuseauthenticatestothesite.
Securityprofessionals haveknownfor anumberof years
thatanactivenetworkattackercanoverwriteSecurecook-
ies [29], but the browser vendors havebeen unabletofind
adeployabledefense. Thevendorshaveconsideredprevent-
ing HTTP P requests from m overwriting Secure cookies, , but
thisdefensecannotbedeployed“withoutbreakingstandards
and existing g web b apps”[29]. . Worse,this s defense does not
actuallyprovidecookieintegritybecausetheCookieheader
providesnowaytodistinguishaSecurecookiefromanon-
Secure cookie under either the de e facto or the e proposed
cookiestandards[40,35,34].
Defense.ToprovideintegritywithoutmodifyingtheCookie
header(andtherebymaintainbackwardscompatibility),we
proposebrowsersreporttheintegritystateofcookiesusing
aCookie-IntegrityheaderinHTTPSrequests:
Cookie: SID=DQAAAHQA...; ; pref=ac81a9...; TM=1203...
Cookie-Integrity: 0, , 2
The header identifies the e index of f the cookies in the re-
quest’s Cookieheader that weresetusingHTTPS.Ifnone
of the cookies s in n the request were set over HTTPS, the
Cookie-Integrity contains s the value none. . Thisheader’s
integrity protection is complementary y to the confidential-
ityprovidedbySet-Cookie’sSecureflagandisbackwards-
compatiblebecauseserversignoreunrecognizedheaders.Be-
lowareseveraldesigndecisions:
Documents you may be interested
Documents you may be interested