OAuth: Where are we going?...• Resource Owner or End-User: User and account owner of resource (the...

Post on 09-Jul-2020

2 views 0 download

Transcript of OAuth: Where are we going?...• Resource Owner or End-User: User and account owner of resource (the...

OAuth:Wherearewegoing?

1

WhatisOAuth?

OAuthandCSRF

Redirection

TokenReuse

OAuthGrantTypes

OAuthv1andv2

2

"OAuth2.0atthehandofadeveloperwithdeepunderstandingofwebsecuritywilllikelyresult[in]asecureimplementation.However,atthehandsofmostdevelopers ...2.0islikelytoproduceinsecureimplementations."

http://hueniverse.com/2012/07/26/oauth-2-0-and-the-road-to-hell/http://hueniverse.com/2010/09/29/oauth-bearer-tokens-are-a-terrible-idea/

Eran Hammer,OriginalFounderofOAuth

OAuthHistory

• Nov2006:BlaineCookbeginsworkingonOAuthwhileatTwitter• 2007:Ma.gnolia,Googleandothersjointhediscussion• 2007:Eran Hammerjoinsandsoonleadsthespecification• Dec2007:OAuth1.0finaldraft• 2008:GoogleOAuth1.0supportbegins• 2010:TwitterforcesallthirdpartyappstouseOAuth1.0• June2012:Eran ragequits theOAuth2.0bodyaftertheshiftfromcryptotobearertokens• October2012:OAuth2.0frameworkpublished

3

OAuthv1andv2:Whataretheprimarysecuritydifferences?

4

OAuthv2isTransport-DependentMostsecuritydefensesaredelegatedtoHTTPS/TLS

OAuthv1isTransport-IndependentSecurityisnotdelegatedtoHTTPS/TLS

Atypo,animproper TLSconfiguration, orafailuretoproperlyvalidateacertificatecanleadtoaman-in-the-middleattack,compromising allOAuthcommunications.

OAuthv1messagesareeachindividuallycryptographically signed.Ifasinglemessagewithinthecommunication isconstructedorsigned improperly, theentiretransactionwillbeinvalidated.

OAuthv1andv2:SignaturesvsBearerTokens

5

OAuthv2AuthorizesMessageswithBearerTokens

OAuthv1AuthorizesMessageswithDigitalSignatures

BearerTokensdonotprovide internalsecuritymechanisms.Theycanbecopiedorstolen.

Asignedmessageistiedtoit'sorigin. Itcannotbetamperedwithorcopiedtoanothersource.

OAuthv1andv2:Whichshouldyouuse?

6

• GooglemovedawayfromOAuth1.0inApril2012.

• TwitterstillsupportsOAuth1.0.

• It’srarefornewserverimplementationstosupportOAuth1.0.

• PlentyofOAuth2.0“add-on”RFC’stosupportcryptoifneeded.

• Soyea,2.0inalmostallsituationsin2015.

OAuthv1Workflow

7

http://docs.spring.io/spring-social/docs/1.0.0.RC1/reference/html/serviceprovider.html#service-providers-oauth1

OAuthv2Workflow

8

http://docs.spring.io/spring-social/docs/1.0.0.RC1/reference/html/serviceprovider.html#service-providers-oauth2

OAuthSecurityinProductsisStabilizing(osvdb.org)

9

SampleOAuthWorkflow

• UsingOAuth,youreCommerceservercannowtweetonbehalfoftheuserevenwhentheuserisnotloggedon.Howdoesthishappen?• First,theuserlogsintotheeCommerceserverwithhisaccountandeditshisaccountprofile.• Next,theeCommerceserverredirectstheusertoTwitter.• TheuserlogsontoTwitterandauthorizestheeCommerceservertotweetonherbehalf.• Then,wheneverordersarecompletetheeCommercetweetsalittlenoteabouthowawesometheeCommercecompanyis- evenwhentheuserisnotloggedontotheeCommerceserver.

10

HighLevelConcepts

• OAuthRoles(Resourceowner,resourceserver,clientapp,authorizationserver)• OAuthGrantTypes (authorizationcode, implicit,resourceownerpasswordcredentials,clientcredentials,extensions)• TokenTypes (refreshtoken,accesstoken)• EndpointTypes (resourceserver,authorizationserver,clientregistration,clientauthorization)

11

Terms• ResourceOwnerorEnd-User: Userandaccountownerofresource(theend-user)• ResourceServer/ServiceProvider: Serverhostingprotectedresourcesownedbytheend-user. Acceptsaccesstokensforprotectedresources.• AuthorizationServer/ServiceProvider. Serverissuingaccesstokenstoprovideotherclientsaccesstoprotectedresources.Oftensameserverasresourceserver.Oneauthorizationservermayissueaccesstokenstomany resourceservers.

12

Terms

• Client/Consumer: Applicationrequestingaccesstoprotectedresourceonbehalfofresourceowner(typicalclientsaremobileapplications, webbrowsers, desktopapplicationsorotherwebapplications). DependingontheOAuthworkflow,thebrowsermayuseanaccesstokendirectly(implicitgranttype)orredirecttheusertoanotherwebapplicationthatactsastheclientoftheservice(authorizationcodegranttype).

13

Terms• AccessToken: OAuthtokenusedtodirectlyaccessprotectedresourcesonbehalfofauserorservice.• RefreshToken: Refreshtokens,whengiventotheauthorizationserver,willprovideanewactiveaccesstoken.Refreshtokensthemselvescannotaccessresources. Whileaccesstokensshouldbeshortlived,refreshtokensarelonglivedorsimplyneverexpireuntiltheuserrevokesthem.Refreshtokensalsoprovidemorescalablepatterns.• ClientIdentifier:UniqueIDofeachclientgiventoclientbyauthorizationserver.• BearerToken: "Asecuritytokenwiththepropertythatanypartyinpossessionofthetoken(a"bearer")canusethetokeninanywaythatanyotherpartyinpossessionofitcan.Usingabearertokendoesnotrequireabearertoprovepossessionofcryptographickeymaterial(proof-of-possession)." -https://tools.ietf.org/html/rfc6750#section-1.2

14

AuthorizationServerSecurity

• TLSforeverything(Authenticity,Confidentiality,Integrity)• Authorizationserversshouldnotautomaticallyprocessrepeatauthorizationstopublicclientsunlesstheclientisvalidatedusingapre-registeredredirectURI(Section5.2.3.5).• Authorizationserverscanmitigatetherisksassociatedwithautomaticprocessingbylimitingthescopeofaccesstokensobtainedthroughautomatedapprovals(Section5.1.5.1).• Explainthescope(resourcesandthepermissions)theuserisabouttograntinanunderstandableway(Section5.2.4.2).• Narrowthescopeasmuchaspossible(Section5.1.5.1).• Don'tredirecttoaredirectURIiftheclientidentifierorredirectURIcan'tbeverified(Section5.2.3.5).

15

https://tools.ietf.org/html/rfc6819

OAuth2.0GrantTypes

• Youcanhidelonglivedtokenstokenfromtheuser(authorizationcodegrant)• Youcanonlyactivateashort-livedtokeninthebrowserwhentheuseriscurrentlyloggedon(implicitgrant)• Youcangrantandexposealong-livedtokensdirectlytotheuserviaatrustedclient(passwordgrant).• Youcangrantandexposealong-livedtokendirectlytootherservicesthatneedtoaccessdatanotassociatedwithaspecificuser(clientcredentialsgrant)

16

OAuth2.0AuthorizationCodeGrant

17

OAuth2.0AuthorizationCodeGrant

OAuth2.0AuthorizationCodeGrant

18

• TheUser(ResourceOwner)CredentialsareneverexposedtoClient

• TheUser(ResourceOwner)neverhasaccesstoactualaccesstoken

• TheClientapplicationcanusetheaccesstokenevenwhentheresourceownerisnotpresent

• AuthorizationCodeRefreshTokensareoftenlonglivedorpermanentuntiltheUser(ResourceOwner)revokesthisaccessthroughtheClientUI.

AuthorizationCodeVariables• Theclientstartsthe"authorizationcode"workflowbyredirectingtheusertotheauthorizationserverwiththerightrequestdata.Thisinitialclientrequestincludes:• response_type :thisisrequiredby"authorizationcode"granttypeandshouldcontainthevalue"code"• client_id:thisistheclientidentifierassignedtotheclientatclientregistrationtime.Thisisuniqueforeveryclientforauthorizationcodegrants.• scope:levelofaccessrequested,domainspecific• redirectionURI:Wheretheauthorizationserverredirectstheuserafteraccessisgrantedordenied

19

AuthorizationCodeGrantSecurity

• 4.4.1.1Threat:EavesdroppingorLeakingAuthorization"codes"(Referrerheaderleakage,logs,openredirect,browserhistory)• UseTLS,requirestrongauthenticationbetweenclientandserver,expirationtimeforaccesstokens,onlyallowoneusepertoken,considerrevokingclientsendinglotsofbadcodes,reducescopeoftokens,flushbrowsercache

• 4.4.1.2Threat:ObtainingAuthorization"codes"fromAuthorizationServerDatabase• ParameterizeyourF#$KINGQUERIES,storeaccesstokenswithaone-waymethodology,gooddatabasesecurity

• 4.4.1.3Threat:OnlineGuessingofAuthorization"codes"• Highentropytokens,strongclientauthentication,shortexpirationtime

• 4.4.1.5Threat:Authorization"code"Phishing• StandardPhishingdefense.Goodluck!Onephishandgameover.

20

https://tools.ietf.org/html/rfc6819#section-4.4.1

CSRFAttacksagainstOAuthPart11. Attacker assumesthatVictimiscurrentlyloggedinat

Consumer sitehttps://consumer-site.example/ (TheOAuthClient Application)

2. Attacker goesthroughregistrationandloginworkflowatConsumerSite https://consumer-site.example/login andusesthataccounttotriggeraOauth

workflowwiththeProviderService(TheOAuthauthorization/resourceserver)

1. ConsumerSiteredirectsattackertoProviderSite logininterface.ThisiscalledtheAuthorizationRequest.https://provider-site.example/login

2. Attacker successfullylogsinwithProviderSite3. Provider SiterespondswithredirectURLwhichcontainsthe

authorizationcodeinthecode parameter.thisiscalledtheAuthorizationGrant.http://consumer-

site.example/auth?code=1a2s3d4f5g6h

21

CSRFAttacksagainstOAuthPart23. InsteadofvisitingorredirectingtotheAuthorizationGrant

redirectURL,Attacker copiestheURLandplacesareferencetoitinanimagetagonawebpage(<img src="http://consumer-site.example/auth?code=1a2s3d4f5g6h"/>)(https://evil-page.example/)

4. Attacker getsVictimtovisithttps://evil-page.example/.1. ThisinturngetsVictim torequesttheAuthorizationGrant

URL(http://consumer-site.example/auth?code=1a2s34f5g6h)

2. ByvisitingtheAuthorizationGrantURL,theVictim hasnowauthorizedtheAttacker tohavefullauthorizedaccesstoVictim's accountonConsumer Site (https://consumer-site.example/).

22

OAuth2andavoidingCSRF

23

1 Consumer generatesuniquerandomstatevalue,andstoresitinserversidesessionvariable.JSONWebTokensaregoodforstatevalues.

2 Consumer sends"state"parameterwithAuthorizationRequest

3 Onsuccessfulauthorization,Provider Site includes"state"parameterinAuthorizationGrantredirectURI

4WhenVictim visitsredirectURI,the"state"parameteriscomparedagainstthe"state"parameterstoredinserversidesessionvariable.

Usethe"state"parameter!ItisessentiallyaCSRFtoken

OAuth2AuthorizationCodeFlowOpenRedirector:Attack1. VictimgoesthroughloginworkflowatConsumerSite

(https://consumer-site.example/login)usingProviderSiteforauthorization.

2. Attacker constructsanAuthorizationRequestURLforProviderSite1. redirect_uri issettohttps://evil-site.example/

3. Attacker eitherembedsevilURLinanimagetagorconstructsaclickablelinkatConsumerSite.

4. WhentheevilURLisloaded,theproviderwill302redirectbacktoredirect_uri sinceuser wasalreadyloggedin.

5. Whentheredirectoccurs,theevilsitecanreadtheHTTPReferrertogettheAuthorizationCode.

6. UsingthisAuthorizationCode,Attackercanloginasuser

OAuth2AuthorizationCodeFlowOpenRedirector:Remediation

1. Whitelistredirect_uri!2. ThereisnoneedforaProvidertorequiretheredirect_uri param!

OAuth2ImplicitFlowAccessTokenReuse:Attack1. VictimauthorizeswithEvilConsumer Site forProviderSite usingaccess_token2. AcmeWidgetsConsumerSiteusesImplicitFlowforauthentication.3. AttackerauthenticatesasVictimwiththeEvilConsumerSiteaccess_token using

https://acme-widgets.example/callback#access_token=access_token

"OneTokentoRuleThemAll"

OAuth2ImplicitFlowAccessTokenReuse:Remediation

1. OAuthshouldbeusedforauthorization,notauthentication!2. Validatethataccess_token belongstoyourclient_id viaproviderAPI

OAuth2.0:Summary

28

1. Holycrapthisiscrazy2. IttakesmassiveeffortstobuildsecureOAuth2solutions3. Thecorestandardbarelyaddressessecurity4. MajorproviderswithPHD'stospareareoveralldoinga

reasonablejobofbuildsecuresolutions5. Clientsareatriskbecausetheyarelikelytobuildless

securityimplementationsthanproviders6. Buckleup,readthethreatmodelseveraltimesandfollow

it'smanymanymanyrecommendations

OAuth:Summary

29

WhatisOAuth?

OAuthandCSRF

Redirection

TokenReuse

OAuthGrantTypes

ThankYou!

jim@manicode.com