Analyzing Websites for User-Visible Security Design Flaws

Laura Falk, Atul Prakash, Kevin Borders University of Michigan

Symposium on Usable Privacy and Security July 23-25, 2008

Mo#va#on:Authors’PersonalExperiences

•  On‐linebanking–  Loginboxesoninsecurepages

•  Needtoreachcustomerservice–  Contactinforma#ononaninsecurepage

•  SeDngupre#rementaccounton‐line•  UseridwasSSN

•  Decidedtoanalyzeotherbankstoseeiftheproblemsweremorecommonandifwecouldhelpnudgebanksintherightdirec#on

Goals

•  Wemostlyfocusonsecurityproblemsthatshouldbevisibletocarefulusersofawebsite•  Mostmakeithardforevencarefuluserstomakecorrectjudgementcalls

•  Wepickedonfinancialsitesbecausetheyareassumedtobedesignedbysecurityexpertsandtheirusersarefrequentlytargeted

OurStudy

•  Wechosenottoexamine“bugs”orbrowserflaws– E.g.,bufferoverflows,cross‐sitescrip#ng,etc.– Theflawswediscussaffectuserswhoareusingbug‐freeclientsoVware

•  Couldnotanalyzeallflaws(e.g.,thosethatrequireloginatthebanksites)

Methodology

•  Acombina#onofautomatedandmanualanalysisof214websites(mostlybanks)

•  Sourceoflist:h\p://www.quazell.com/bank/bank‐usa.html

•  Studyini#atedinFallof2006– Used5visibleflawsfoundinini#alanalysisof20sites

– Downloadedwebsitecontentstodisk– Searchedfilescontainingwebpagesusingscripts

LoginWindowonanInsecurePage

•  Presen#ngsecureloginop#onsoninsecurepage– A\ackercouldmodifyinsecurepage

– Forwardlogincreden#alstoanotherdes#na#on

ShortVideoIllustra#nganA\ackonInsecureLoginPages

(RecordedonJuly20th,2008)

ExampleRiskScenario

Coffee Shop

Router/Access Point

Rogue Router/Access Point DNS flaws [see recent bug report by Dan Kaminsky] could potentially allow even remote, large-scale exploits

ContactInforma#ononanInsecurePage

Videoillustra#ngthecompromiseof“ContactUs”Pages

(RecordedonJuly20th,2008)

Shouldthisbeaconcern?

•  Exploitswouldnotbestraighhorward(e.g.,mayrequireseDnguparoguecallcenter),buta\ackersarebecomingmoreorganized– Othercustomerservicechannels,suchaschat,mayalsobecreatedthatcouldbeexploitedcheaply

•  Bo#omLine:Nogoodreasonwhybanksshouldnotsecurelydeliverallcontent

UseofThird‐PartySites

•  Breakinthechainoftrust– Forwardusertonewpagesthathavedifferentdomains

– OVennono#fica#onofany3rdpartytransi#on– Poten#alforcustomerconfusion

•  Userhasnostraighhorwardwayofknowingif3rdpartydomainistrustworthy

Example

•  No#cethedomainintheURL

Example(contd.)

•  Transi#onto3rdpartysite(2006example)

ShortVideodemonstra#ngUserConfusionwithThird‐Party

Domains(RecordedonJuly24th,2008)

InformalPoll

•  Visityourbank(s)webpage– Locateloginwindow

•  Isitonaninsecureorsecurepage?– Locatethecontactinforma#on

•  Isitonaninsecureorsecurepage?–  Isyourbankusing3rdpartysites?

•  Wewillaskforashowofhandsfortheseques#onsattheendofthetalk

PoliciesonUserIdsandPasswords

•  Inadequateorunclearpoliciesforuseridsandpasswords– Somesitesusedsocialsecuritynumbersforlogin(e.g.,TIAA‐CREFin2006.Wecontactedthemaboutit.Sincechangedthepolicy)

– Maynotrequireorrecommendstrongpasswords

AmbiguityinPolicies

•  E‐mailingsecuritysensi#veinforma#oninsecurely– Sitesofferedtosendstatementsandpasswordsthroughe‐mail

– Asweknowandbanksknow,emailisnotasecuremedium

•  (Caveat:Itispossiblethatthesiteswillonlysendyouano#fica#on,notthetheactualstatement.ButthiswasoVennotapparentfromthewording.)

Example

•  Offeringtoe‐mailsecuritysensi#veinforma#on

Results

Specific Design Flaw % of Sites Affected Login window on insecure page 47%

Contact info on insecure page 55%

Inadequate policies on user ids/passwords

28%

E-mailing sensitive information 31%

Use of 3rd party sites 30%

  List of Design Flaws and Percentage of Sites Affected

KeyPoints

•  Severalofthesedesignflawswerewidespread•  76%hadatatleastonedesignflaw(note:useofnon‐SSLpagesmorecri#calthanothers)

•  Almosthalfthesitespresentedloginboxesoninsecurepages

•  Useof3rdpartydomainswasfairlycommon•  Lessthanhalfsecuredtheircontactinforma#on•  Scopeforimprovementinotherareas,suchasbe\erpoliciesonuserids,passwords,andemailusebythesite

SomeLimita#onsofOurStudy

•  Wemayhavefailedtocompletelyretrieveallrelevantpages–  Impact:ourresultslikelytounder‐es#mateflaws

•  Onlylookedfinancialins#tu#onsinU.S.– Resultscouldbedifferentinothercountries.

•  Weusedheuris#csforautomatedanalysis– Couldcauseustounderoroveres#mateerrors

•  Humanerrorswherewedidmanualinspec#on

SomeRelatedWork

•  Usersmaymakeerrorsevenifbanksfixthedesignflaws[Schechteretal.]

•  Implementa#onflawsarealsocommon•  Applica#onlevelwebsitescanners

•  RogeriodePaulaetal.,discoveredthatimplementa#onandintegra#onoftechnicalcomponentsishardwithrespecttosecurity•  Perhaps,banksiteshavemul#pledomainsandadministrators.Noonelookingatthe“bigpicture”

UsabilityLessonsforWebSites

•  Provideaconsistentexperiencetouserssothatitiseasierforuserstospotdevia#onsfromthenorm– Stayonthesamehostname(www.bank.com)

– Nextbest:www.bank.comtosecure.bank.com– Nextbest:make“properintroduc#on”

•  FromtheoriginaldomainoverHTTPS•  Saywhetherthenewdomaincanbetrusted

– UseSSLthroughoutthesite.

TheBigPicture–TakeAway

•  Wewanttohelpbanksbythisstudyrecognizetheimportanceofusablesecurity–problemsarecommon

•  Keyrecommenda1ons:–  UseSSLforen#resite(noexcep#ons)–  Discon#nueuseof3rdpartydomainsifpossible(especiallyforservicesforthesamebank)orintroducethemsecurely

–  Improvesecuritypoliciesandstatethemclearly

•  Benefits:Hopefully,thatwillmakeiteasierforcarefulcustomerstono#ceinconsistenciesbecausemostfinancialsiteswilluseasimple,consistentmodel

InformalPoll

•  Didyourbank’sloginwindowresideonaninsecurepage?

•  Didthecontactinforma#ononyourbank’ssiteresideonaninsecurepage?

•  Didyourbankuse3rdpartydomainsduringauthen#ca#on?

Ques#ons?