SCUDO A Finegrained Protection Model for Web Browsers - PDF document

ESCUDO:AFine-grainedProtectionModelforWebBrowsersKarthickJayaraman,WenliangDu,BalamuruganRajagopalan,andSteveJ.ChapinDepartmentofEECS,SyracuseUniversityfkjayaram,wedu,barajago,chaping@syr.eduAbstractWebapplicationsarenolongersimplehyperlinkeddoc-uments.Theyhaveprogressivelyevolvedtobecomehighlycomplex—webpagescombinecontentfromseveralsources(withvaryinglevelsoftrustworthiness),andincorporatesignicantportionsofclient-sidecode.However,theprevailingwebprotectionmodel,thesame-originpolicy,hasnotadequatelyevolvedtomanagethesecurityconse-quencesofthisadditionalcomplexity.Asaresult,webap-plicationshavebecomeattractivetargetsofexploitation.Wearguethatthisdisconnectionbetweentheprotectionneedsofmodernwebapplicationsandtheprotectionmod-elsusedbywebbrowsersthatmanagethoseapplicationsamountstoafailureofaccesscontrol.Inthispaper,wepresentESCUDO,anewwebbrowserprotectionmodelde-signedbasedonestablishedprinciplesofmandatoryaccesscontrol.WedescribeourimplementationofaprototypeofESCUDOintheLobowebbrowser,andillustratehowwebapplicationscanuseESCUDOforsecuringtheirresources.OurevaluationresultsindicatethatESCUDOincurslowoverhead.Tosupportbackwardscompatibility,ESCUDOdefaultstothesame-originpolicyforlegacyapplications.1IntroductionInitially,webapplicationscomprisedasetofdocumentsthatmostlycontainedtexttoberenderedandhyperlinkstootherdocuments,withlittleornoclient-sidecode.Allthecontentoriginatedfromasingle,trustedsource.Overthelastseveralyears,intheracetoaddinteractivefeatures,webapplicationshaveprogressivelybecomemorecomplex.Inmorerecenttimes,webapplicationshaveevolvedtobe-comehighlyinteractiveapplicationsthatexecuteonboththeserverandclient.Asaresult,webpagesinmodernap-plicationsarenolongersimpledocuments–theynowcom-prisehighlydynamiccontentsthatinteractwitheachother.Insomesense,awebpagehasnowbecomea“system”–thedynamiccontentsareprogramsrunninginthesystem,andtheyinteractwithusers,accessothercontentsbothonthewebpageandinthehostingbrowser,invokebrowserAPIs,andinteractwithprogramsontheserverside.Moreover,today'swebpagesnolongerdrawcontentsfromasinglesource;contentsarenowderivedfromseveralsourceswithvaryinglevelsoftrustworthiness.Contentsmaybeincludedbytheapplicationitself,derivedfromuser-suppliedtext,orfrompartiallytrustedthirdparties.Dur-ingparsing,rendering,andexecutioninsidethebrowser,thedynamicandstaticcontentsofwebpagescanbothactandbeacteduponbyotherentities—inclassicsecuritypar-lance,theycanbeinstantiatedasbothprincipalsandob-jects.Theseprincipalsandobjectsareonlyastrustworthyasthesourcesfromwhichtheyoriginate.Thesecurityofawebapplicationisprimarilydependentontheintegrityandcondentialityofitsresourcesinsidethewebbrowser.Forexample,sessionidentiersincook-iesneedtobeprotectedagainstaccessbyuntrustedprinci-pals;codefromuntrustedsourcesmustbeauthorizedbe-foreitisallowedtomodifyanytrustedcontentonawebpage.Withoutappropriateaccesscontrolinwebapplica-tions,wecannotpreservethetrustworthinessofcontents,andsecuritycouldbecompromised.Ifweconsidereachwebpageasa“system,”weneedanadequateprotectionmodelinbrowserstomediatetheinteractionswithinsuchasystem.Allwebbrowsersimplementaprotectionmodelcalledthesame-originpolicy.Unfortunately,thismodelhasnotadequatelyevolvedtomanagethesecurityconsequencesoftheadditionalcomplexityinmodernwebpages.Itcannotdistinguishgradationsintrustworthiness,nordoesitpro-videsufcientisolationbetweenwebbrowserobjectstoen-sureproperaccesscontrol.Asaresult,webapplicationshavebecomeattractivetargetsofexploitation.Bothcross-site-scriptingattacksandcross-site-requestforgeryattacksareexamplesofuntrustedprincipalsexercisingcontrolovertrustedobjectsinsidethewebbrowser.Wearguethattherootcauseoftheproblemisafailureofaccesscontrol.Thesame-originpolicyclearlyviolatestwoimportantprinciplesofaccesscontrol,namelyseparationofprivilegeandprin-cipleofleastprivilege[32].Becauseofaccess-controlfailures,webapplicationsthatembedthirdpartycontentintheirwebpagecannotrestrictthepermissionsofthethirdpartycode.Forexample,ablogpublishermaysellasmallportionofhiswebpagetoanadvertisingnetwork.Theadvertisingnetwork,inturn,ac-ceptsJavascriptadsfromitsclientsanddisplaysthemon1 thepublisher'swebpage.Thepublisherhasnofurthercon-troloverwhatappearsinthatadspace—hetruststhenet-worktohaveveriedallcontent.AnattackerposingasanadvertisercouldcompromisetheintegrityofthepublisherswebapplicationusingamaliciousJavaScriptprogram[36].JavaScriptverierssuchasADsafe[12]couldbeusedbyanadvertisementnetworktoverifyaJavaScriptprogram,butthatdoesnotchangethepublisher'sposition:heisre-lyingonathird-partytovouchforthetrustworthinessofJavascriptprogramsthatwillruninhisownwebpages.Therehavebeenotherapproachesfordealingwiththisaccess-controlfailure.Webapplications,asarstlineofdefense,employinputvalidationandcontentlteringattheserverwhengeneratingthewebpage.Theobjectiveofthisstepispreventingknownattacksfrominstantiatinganun-trustworthyprincipalinsideawebpage.Forexample,todefeatcross-sitescriptingattacks,wecanlteroutallthecodefromcontentsoriginatingfromuntrustedsources.Thisrst-lineofdefensehasproventobedifculttoimplementproperly;manyvulnerabilitiesarebecauseoftheerrorsinsuchaprocess[15,17].Second,therearebrowserpatchesthataddressspecicattacks[18].Ingeneral,alltheseap-proachesaddressthesymptomsofspecicproblemswith-outaddressingthefundamentalrootcause—thelackofarobustprotectionmodelsuitableformodernwebapplica-tions.Wedescribeanalternateapproachthataddressestheaccess-controlfailureinwebbrowsersbyredesigningtheunderlyingaccess-controlmodel,attackingtherootoftheproblem.Redesigningtheaccess-controlmodelforwebbrowsersinvolvesfourchallenges.First,theaccess-controlmodelshouldbeabletoidentifyprincipalsandobjectsatre-quiredgranularity.Second,theaccess-controlmodelshoulduseanappropriatepolicytosecurecontentwithvaryinglev-elsoftrustworthiness.Third,achallengeuniquetowebap-plicationsisdistributedenforcement–theapplicationsattheserverareawareoftrustworthiness,buttheactualinterac-tionsthathavetoberestrictedhappenatthebrowser.Fi-nally,thenewmodelshouldbebackwardcompatiblewiththesame-originpolicytofacilitateincrementaldeployment.Inthispaper,wedescribeESCUDO,ane-grainedwebbrowserprotectionmodel,basedonvettedaccess-controlprinciplestoprotectmodernwebapplications.Tothebestofourknowledge,thisistherstworkonredesigningtheaccess-controlmodelforwebbrowsers.ESCUDOisde-signedtoenforceseparationofprivilegeandtheprincipleofleastprivilege,andtoprovideadequategranularityinbothspecicationandenforcement.Wearguethattheprotectionrequirementsofwebapplicationsaresimilartooperatingsystems.Someoperatingsystemsusehierarchicalprotec-tionrings(HPR)toenforcetheirprotectionrequirements.ESCUDOisanadaptationofHPRtailoredtomeetthepro-tectionrequirementsofwebapplications.Toaddressthedistributedenforcementproblem,wede-scribeamethodthatwebapplicationscouldusetoidentifytheprincipals,objects,andtheirtrustworthinessandcon-guretheirresourcesatthegranularityrequiredbythemtoreecttheirprotectionneeds.Themethodisbackwardcompatiblewithnon-ESCUDObrowsers,whichignorethecongurationanddefaulttothesame-originpolicy.WeimplementedaprototypeofESCUDOfortheLobobrowserandourevaluationresultsshowthatESCUDOin-cursaround5%overhead.WeillustrateourexperienceinbuildingwebapplicationsforESCUDOusingtwoopen-sourcewebapplicationsascasestudies.WemodiedtwoopensourcewebapplicationstouseESCUDO.Weanalyzedthewebapplicationstounderstandtheirsecurityrequire-mentsandconguredthemtouseESCUDOtoenforcethesecurityrequirements.Thekeycontributionsofthepapercanbesummarizedasfollows:ESCUDOisanewne-grainedwebbrowserprotectionmodeltomeettheprotectionrequirementsofmodernap-plications.Abackward-compatiblecongurationmethodthatwebapplicationscanusetoidentifytheprincipals,objects,andtheirtrustworthinessinordertouseESCUDO.AprototypeimplementationofESCUDOontheLobowebbrowser.CasestudiesillustratingourexperienceofbuildingwebapplicationsforESCUDO.2ProtectionRequirementsforWebApplica-tionsInthissection,wewilldescribetheprotectionrequire-mentsofwebapplicationsbyprovidingananalysisoftheprincipals,objects,andthecharacteristicsofmodernwebapplications.Finally,wedescribetheinadequacyofthesame-originpolicyinmeetingtheprotectionrequirements.2.1PrincipalsandObjectsInawebapplication,principalsareaction-inducingHTMLexcerptssuchasJavaScriptprograms,andobjectsareapplicationresourcessuchasthewebpagecontentsandcookiesthataretargetsofactions.SomeHTMLexcerpts,suchasJavaScriptprograms,mayactasbothprincipalsandobjects.Table1describestheprincipalsandobjectsinsideawebapplication.HTTP-requestIssuingPrincipals:HTTP-requestissu-ingprincipalsareHTMLtagssuchasa,img,form,embed,andiframethatinstructthewebbrowsertoissueanHTTPrequest.Script-invokingPrincipals:Script-invokingprincipalsareHTMLconstructssuchasscriptandtheCSSexpres-sionthatcaninvoketheJavaScriptinterpreter.Additionally,2 webapplicationscanspecifyuser-interface(UI)eventhan-dlerstobeinvokedforspeciceventsusingattributessuchasonload,onmouseover,etc.Plugins:Pluginsarecontent-specicrun-timeenviron-mentsforcertaintypesofcontentssuchasFlash,Sil-verlight,andPDF.Additionally,browserssuchasFirefoxprovideaframeworkforcreatingextensions,enablinguserstoextendthefunctionalityofthebrowser.Pluginsandex-tensionshavetheirownsecuritymodelsandmayormaynotbecontrolledbythewebapplications.Inthispaper,weonlyfocusontheprincipalsthatcanbecontrolledbythewebapplications.Documentobjectmodel(DOM):Internally,webbrowsersrepresentthecontentsofawebpageusingadatastructuredcalledtheDOM,inwhichalltheHTMLtagsandtheircontentareorganizedinahierarchicalfashion.EachHTMLtagisaDOMelement.DOMelementshaveaspecialfeature—theycanactasbothprincipalsandobjects.SomeDOMelementsarescript-invokingprincipalsorHTTP-requestinitiatingprincipals.SuchDOMelementsactasprincipalsmomentarilywhentheyareinstantiated.Ontheotherhand,theyactasobjectswhentheyarethetargetsofmodicationviatheDOMAPI.Cookies:Webapplicationscreatecookiesinwebbrowsers;cookiestypicallycontaindatausedtotrackses-sions.Afteracookieiscreated,webbrowsersattachthecookiesinallsubsequentHTTPrequestsbacktothewebapplication.Therefore,cookiesareobjectsthatareimplic-itlyaccessedinallHTTPrequests.Inaddition,JavaScriptprogramsmayexplicitlymanipulatecookies.NativeCode:NativebrowsercodeisexposedtoJavaScriptprogramsviaanAPI.Forexample,theXMLHttpRequestAPIisanexampleofnativecodethathelpsJavaScriptprogramsinteractwithserver-sidepro-grams.Similarly,theDOMAPIisusedbyJavaScriptpro-gramstoaccessandmodifythewebpage.WebapplicationsmaynotwanttoexposetheseAPItountrustedcode.There-fore,theabilitytoinvokesuchAPIshouldbeacontrollableprivilege.BrowserState:Webbrowsersmaintainbrowsinghistoryandvisitedlinkinformationforeachbrowsingsessionwithawebsite.Thisinformationispartofthestateofabrows-ingsessionandisaccessibletoJavaScriptprogramsthroughtheDOMAPI.Browsinghistoryisalogofrecentlyvis-itedURLandusersmayusethisinformationtoinstructthewebbrowsertorenderapreviouslyvisitedwebpage.Vis-itedlinkinformationisusedbywebbrowserstodifferen-tiaterecentlyvisitedfromunvisitedURL—typically,webbrowsersusedifferingcolorstodisplayvisitedandunvis-itedlinks. Principals Objects HTTP-requestissuingprinci-pals Documentobjectmodel(DOM) -HTMLForm -HTMLAnchor Cookies -HTMLImg -HTMLIframe NativeCodeAPI -HTMLEmded -XMLHttpRequestAPI -DOMAPI Script-invokingprincipals -JavaScriptPrograms BrowserState -UIeventHandlers -History -Visitedlinkinformation Plugins(Cannotbecontrolledbywebapplications) Table1.Principalsandobjectsinsidethewebbrowser.2.2ProtectionNeedsWeoutlinetwocharacteristicsofmodernapplicationsthatarerelevantformotivatingourprotectionrequirements:IncreasingUseofClient-sideCode:Earlier,webap-plicationsprimarilyexecutedontheserverandonlywebpagesweredeliveredtobrowsers.WiththeintroductionofJavaScriptprograms,webapplicationscouldadditionallyexecuteinthebrowsertoprovidesomeinteractivefeatures.JavaScriptprogramsarecommonlyusedtodisplaydrop-downmenusbyupdatingthecontentsofthewebpage.Fur-thermore,AJAXenablesJavaScriptprogramstocommuni-catewiththeapplicationattheserver.Aninstant-messagingapplicationmightuseanAJAX-basedJavaScriptprogramforcommunicatingwiththeserverandupdatingthechatwindow.ContentwithVaryingLevelsofTrustworthiness:Inmodernapplications,thecontentinsidewebpagesisde-rivedfrommultiplesourceswithnonuniformtrustworthi-ness.Therefore,contentinsidewebpagesisnolongeronlytrustedandprovidedbytheapplicationitself.Therearesev-eralexamplesofapplicationsincludinguntrustedcontent.Blogsandwikisenableuserstoprovidearbitrarytextthatwillbepartofthewebpages.Becausethetextissuppliedbytheuser,itshouldnotbetrusted.Therearealsoex-amplesofapplicationsincludingsemi-trustedcontent.AnonlineauctionapplicationmayenableasellertocreateawebpageinitsapplicationandmayalsoallowthesellertoprovideJavaScriptprogramsinthepagetoenablesomerichfunctionality.Asocialnetworkingapplicationmayal-lowuserstoaddapplications,essentiallyJavaScriptpro-grams,intheirproletoextendthefunctionalityoftheirprolepages.WebapplicationsfrequentlyaddthirdpartyJavaScriptprogramsforaddingsomefeatures.Forexam-ple,anapplicationmayincludethirdpartyJavaScriptpro-gramforkeepingtrackofsitestatistics.Onlineadvertising3 thatwediscussedearlierisanotherexampleofincludingsemi-trustedcontent.Asadirectconsequenceofthesetwocharacteristics,wehaveprincipalsofvaryingtrustworthinessinsidethewebpage.Currently,theseprincipalsaccessormodifycon-tentinthewebpage,invokenativeAPI,andcommunicatewiththeapplicationattheserver,irrespectiveoftheirtrust-worthiness.SaltzerandSchroeder[32]havesummarizedeightdesignprinciplesforbuildingprotectionmechanisms:economyofmechanism,fail-safedefaults,completemedi-ation,opendesign,separationofprivilege,leastprivilege,leastcommonmechanism,andpsychologicalacceptability.Oftheeightguidelines,thesame-originpolicyclearlyvio-latestwoprinciples,namelyleastprivilegeandseparationofprivilege,buthasdoneafairlygoodjobwithrespecttotheothercharacteristics.Thesame-originpolicy'snon-conformancewithsounddesignprinciplesleadsdirectlytoitsfailuretomeettheprotectionneedsofmodernapplica-tions.Basedonouranalysisofmodernapplicationsandvettedprinciples,aprotectionmodelforwebbrowsersre-quiresthreecharacteristics:1.SeparationofPrivilege:Separationofprivilegeindi-catesthat,ifpossible,privilegesinasystemshouldbedividedintolesspowerfulprivileges,suchthatnosin-gleaccident,deception,orbreachoftrustissufcienttocompromisetheprotectedinformation.2.PrincipleofLeastPrivilege:Theprotectionmodelshouldbeabletolimittheinteractionsofprincipalsbasedontheirtrustworthiness.Essentially,aprincipalshouldnothavemoreprivilegestoaccessinformationorresourcesthanrequiredforitslegitimatepurpose.Inaddition,aprincipalshouldnotbeabletoelevateitsprivilegeinanuncontrolledmanner.3.FineGranularity:Theprotectionmodelshouldbeabletoidentifyprincipalsatasufcientgranularitytoascertaintheirtrustworthiness.Therefore,originsaloneareinsufcientforthispurpose.Havingnegranularityisessentialforachievingtheprincipleofleastprivileges.2.3TheSame-OriginPolicyisInadequateThesame-originpolicy(SOP)identiesanapplica-tion'soriginasauniquecombinationofhprotocol,do-main,porti.Forinstance,http://www.amazon.com/index.phpandhttp://www.amazon.com/search.phpbelongtothesameorigin,buthttp://www.gmail.comandhttp://www.amazon.comdonotbelongtothesameoriginbecausetheyhavediffer-ingdomains.Similarly,http://www.gmail.comandhttps://www.gmail.comdonotbelongtothesameoriginbecausetheyusedifferentprotocols.Webbrowsersassociateapplicationresourcessuchascookiesanddocu-mentobjectmodel(DOM)totheirorigin,andtheSOPpre-ventsJavaScriptprogramsfromoneoriginfromaccessingapplicationresourcesbelongingtootherorigins.UndertheSOP,allprincipalsinsidethewebapplicationareassociatedwithasingleprincipalidentiedbytheoriginandareassociatedwithalltheprivilegesirrespectiveoftheirtrustworthiness,violatingtheprincipleofleastprivilege.Inaddition,principalsandresourcesacrossapplicationsarenotappropriatelyisolatedfromoneanother.Bothcross-site-scripting(XSS)attacksandcross-site-requestforgery(CSRF)attacksareasideeffectoftheseinadequacies.InXSSattacks,anattackerdeftlyconstructsinputdataforanapplicationthatisinterpretedasJavaScriptbythewebbrowserandexecuteswithallprivileges.Ideally,theJavaScriptprogramshouldexecutewithlimitedornopriv-ilegesbecauseitwasderivedfromuntrustedwebcontent.InCSRFattacks,amalicioussiteforgesandinjectsare-questintoavictimuser'sactivesessionwithatrustedsite.SomeHTMLtagssuchasa,img,andiframescaninitiateanHTTPrequest.TherearenorestrictionsontheURLthatcanbeusedintheseHTMLtags.Inaddition,webbrowsersautomaticallyattachthetargetsite'scookiestotheHTTPrequest,irrespectiveofwhoismakingtherequest.Ama-licioussiteabusesthisweaknesstoforgearequestforatrustedsite.Ideally,principalsandobjectsacrossapplica-tionsshouldbeisolatedfromthesetypesofunintendedin-terferences.3OurApproachWeneedfundamentalchangestotheexistingwebbrowserprotectionmodeltoaddresstheprotectionneedsofmodernapplications.Ourapproachistodesignawebbrowserprotectionmodelbasedonvettedmandatoryaccess-control(MAC)principles.Inourproposedmodel,developerscanconguretheirapplicationbyappropriatelyspecifyingtheprincipals,objects,andtheirtrustworthiness.Webapplicationscommunicatethecongurationtothewebbrowser,wheretheproposedaccess-controlmodelenforcesaccessdecisionsbasedontheconguration.ThisistypicalofanyMACsystem,whereasystemadministratorcong-uresthesystemandsystem-levelmechanismsenforceac-cessdecisionsbasedontheconguration[8].Conceptually,accesscontrolistheabilitytodecidewhocandowhattowhominasystem.Anaccess-controlsys-temconsistsofthreecomponents:principals,objects,andanaccess-controlmodel.Principals(thewho)aretheen-titiesinthesystemthatcanmanipulateresources.Objects(thewhom)aretheresourcesinthesystemthatrequirecon-trolledaccess.Anaccess-controlmodeldescribeshowac-cessdecisionsareenforcedinthesystem;theexpressionofasetofruleswithinthemodelisanaccess-controlpolicy(thewhat).Basedontheanalysisoftheprotectionneedsinwebap-plications,itisclearthatahierarchicalmulti-levelMACmodelcanaddresstheseneeds.Insuchmodels,asystemorganizesitsprincipalsandobjectsintohierarchiesbased4 ontheirtrustworthiness,andassignsappropriateprivilegestoeachhierarchy.Accessdecisionsarebasedonthehier-archyoftheprincipalsandobjects.Forexample,SELinuxandWindowsVistahaveadoptedaMACmodeltoenforcerestrictionsonprogramsbasedontheirtrustworthiness.Weanalyzedseveralexistingmulti-levelMACmodelssuchasBiba[7],Bell-LaPadula[6],andhierarchicalpro-tectionrings(HPR)[33].Thereareseveralsimilaritiesbetweentheprotectionneedsofwebapplicationsinwebbrowsersandthoseofprogramsinoperatingsystems.Inop-eratingsystems,aprogramwithuser-levelprivilegesmustbeisolatedfromaprogramwithkernel-levelprivileges.Inaddition,thememoryaddressspacesofuserprogramsshouldbeisolatedfromoneanother.Ourdesignisprimarilymotivatedbythissimilaritytoprotectionneedsinoperatingsystems. Figure1.Protectionrings:Allprincipalsandob­jectsareorganizedintoprotectionrings.Thein­nermostringisthemostrestrictedringandtheoutermostringistheleastrestrictedring.HPRwasrstintroducedintheMulticsoperatingsys-tem.InMultics,theaccesspermissionsareorganizedintohierarchicalringsnumberedfrom0ton(Figure1).Ring0isthemostprivilegedringandringnistheleastprivilegedring.Theaccesspermissionsinaringxareasubsetofac-cesspermissionsinringy,wheneverx�y.Aprocessinaparticularringislimitedtousetheaccesspermissionsinitsownringorouterrings.Therearespecialgatesbetweenringstoallowaprocessfromanouterringtorequestsomeresourcesfromaninnerringinacontrolledfashion.Toiso-latethememoryaddressspacesofuserprograms,Multicsusessegmentdescriptors.Organizingtheprograminringsprovidesseparationofprivilege,andmemoryisolationen-forcedviasegmentdescriptorsfurtherincreasesthegranu-larityofprotectionofferedbyringsandenforcestheprinci-pleofleastprivilege.ESCUDOisanadaptationofHPRtomeettheprotectionrequirementsofwebapplications.4TheESCUDOAccessControlModelESCUDOconsistsoffourcomponents:Rings:ESCUDOtreatseachwebpageasa“system,”andalltheelementsinthissystemareplacedinastaticsetofper-pageprotectionrings.ThisissimilartoHPRinop-eratingsystems.However,unlikeinoperatingsystems,wherethereisonlyonesetofrings,abrowsercansimul-taneouslyhostmultiplesystems(i.e.webpages),thesetofringsforeachwebpageisindependentfromtheoth-ers.Theringsofwebpagesbelongingtothesameoriginarecompatiblewitheachother.RingAssignments:Awebapplicationshouldprovidetheringassignmentsforalltheelementsinthesystembasedonthetrustworthinessoftheelementsandprotec-tionneeds.Theringassignmentmethodvariesdepend-ingonthetypeofelementandisdiscussedinsection4.1.Thisstepiscalled“conguration,”analogoustoasys-temadministratorconguringasystem.Ourcongura-tionmethodprovidesne-grainedgranularityinspeci-cation.AccessControlList(ACL):ESCUDOallowsobjectstoadditionallyuseanACLtoimprovethegranularityofprotectionprovidedbythemodel.Essentially,theACLusedbyeachobjectenforcestheprincipleofleastprivi-lege.Section4.1describeshowanobjectcancongureitsACL.Access-controlModel:ESCUDOusesaMACmodelbasedonHPRforenforcingaccessrestrictionsinsidethebrowser.Theaccessdecisionsarebasedonthecongura-tion(ringassignmentandACL)providedbytheapplica-tion.Therulesintheaccess-controlmodelaredescribedinsection4.2.ThisdesignreectsthethreeprincipleswesummarizedinSection2.2.WithringsandACLs,privilegesinawebapplicationsaredividedintomanypieces;thesepiecesareorganizedintoawidely-usedhierarchicalmodel,makingthemeasytouse.Thenegranularityofprincipalsandprivilegesisalsoachievedthroughtheintroductionofmul-tiplerings.Withne-grainedprincipals,ne-grainedpriv-ileges,andwell-isolatedprivileges,theprincipleofleastprivilegecanbeeasilyenforcedinwebapplications.4.1Rings,RingAssignment,andACLESCUDOallowswebdeveloperstochooseasetofringsfortheirapplications,andassigntheelementsofthewebapplicationsintotheserings.Thesetofringsforonewebapplicationisindependentfromthatofothers;therefore,otherthandeningtherelationshipsamongdifferentrings,ESCUDOdoesnotdenewhateachringmeans,nordoesitstipulatethetotalnumberofrings.Thedenitionsareuptothewebapplicationdesigners.Designerscanchoosethetotalnumberofringsthatttheirapplicationneeds;theycanmaketheirownringassignment,independentofotherapplications.5 RingsinESCUDOarelabeled0,1,:::,N,whereNisapplicationdependent.IntheHPRmodel,highernumberedringshavelesserprivilegesthanlowernumberedrings.Ring0isthehighest-privilegedring,andringNistheleast-privilegedring.Allexamplesinthispaper,forthesakeofsimplicityinillustration,useN=3.Thisisalargeenoughnumbertodemonstrateinteractionbetweenringswithoutbeingcumbersome;otherthanthat,3isarbitrary.Inthissubsection,wedescribehowvariousprincipalsandobjectsinthewebapplicationareassignedtorings.WebapplicationscancommunicatetheringassignmenttoESCUDOeitherusingHTMLtagsoroptionalHTTPhead-ers,dependingonthetypeoftheobject.DOMElements:RecallthatDOMelementscanactasbothprincipals(e.g.script-invokingconstructs)andob-jects(e.g.HTMLexcerpts).WeusetheHTMLdivtagtolabeleachDOMelement.HTMLdivtagswereorig-inallyintroducedtospecifystyleinformationforagroupofHTMLtags;recentlytheyhavebeenextendedforotherpurposes[35].Weintroduceanewattributecalledtheringattributeforthedivtag.ThisattributeofthedivtagassignsaringlabeltoalltheDOMelementswithinthescopeofthetag,whichistheregionenclosedbythedivand/divtags(Figure2).Werefertosuchdivtagsasaccess-control(AC)tags. divring=2r=1w=0x=2&#x-2.2;䦒 ... divring=3r=2w=0x=2&#x-2.2;䦒 ... /div&#x-2.2;䦒 /div&#x-2.2;䦒 Figure2.RingassignmentHTMLallowshierarchicaldivscopes,i.e.,adivscopecanbeenclosedentirelywithinanotherdivscope.There-fore,ringassignmentscanalsobehierarchical.Tomaintaintheintegrityoftheringassignment,ringnumbersinthein-nerscopemustbeequaltoorhigherthantheringnumbersintheouterscope(i.e.fewerprivileges).Figure2givesanexampleofringassignment.Specialattentionmustbetakentoensuretheintegrityoftheringassignment.InSection5,wewilldescribespecicmechanismstothwartattemptstocompromisetheintegrityofringassignment.WhenaDOMelementactsasanobject,ESCUDOallowswebapplicationstofurtherspecifyanergrainedsecuritypolicyonhowthisobjectcanbeaccessed,inadditiontothepolicyalreadyimposedbytherings.ESCUDOusesAccessControlLists(ACL)forthispurpose.EachACLconsistsofthreeitems:permissionsforread,write,anduseop-erations.Themeaningsforreadandwriteoperationsarestraightforward;theuseoperationneedsmoreexpla-nation.Insomescenarios,webbrowsersimplicitlyaccessobjectsonbehalfofprincipals,eventhoughtheprincipaldoesnotexplicitlyrequesttheaccess.Forexample,when-everanHTTPrequestisgeneratedforatargetURL,webbrowsersautomaticallyattachthecookiesbelongingtothetargetsitetotheHTTPrequest.However,theprincipalwhoinitiatedtherequestdidnotexplicitlyreferencethecookies.AnotherexampleisdeliveringaUIeventtoaDOMelementusingaJavaScriptprogram.Wecalltheseimplicitaccessestheuseoperation.AnACLisspeciedusingalistofattributes(r,w,x)inthedivtag,wherer,w,xrefertotheread,write,anduseoperationsrespectively.Thevalueofeachattributeidentiestheoutermostringrequiredfortheoperation.Forexample,inFigure2,theoutermostACtagmapstheob-jectsinsideitsscopetoring2(“ring=2”).However,onlyprincipalsinring0canmodifyanyDOMelementsembed-dedinsidetheoutermostACtags(“w=0”).Cookies:Typically,webapplicationsinstructthewebbrowsertostoreacookieinthebrowserusingaset-cookieheaderinHTTP.InESCUDO,weuseanadditionaloptionalHTTPheadertocommunicatetothebrowserstheringas-signmentandACLforcookies.Cookiesthatcontainsen-sitivedatasuchassessionidentiersshouldbemappedtoahigher-privilegedring.Othercookiescouldbemappedtolesser-privilegedrings.IfringmappingsareomittedfromtheHTTPheader,bydefault,allcookiesareassignedtoring0.NativeCodeAPI:TheringmappingsfornativecodeAPIssuchasXMLHttpRequestarealsocommunicatedtoESCUDOusinganoptionalHTTPheader.Bydefault,ES-CUDOassignsnativecodeAPIsuchasXMLHttpRequesttothehighest-privilegedring0,conformingtothefail-safedefaultsguideline.WebapplicationsmayassignthenativecodeAPIstodifferentrings.BrowserState:ESCUDOmandatorilyassignsinternalbrowserstatesuchascacheandbrowsinghistorytoring0.Inourcurrentmodel,theringassignmentofbrowserstateisnotcongurable.Thewebbrowsercouldmanipulateorusethestateinformation.However,JavaScriptprogramsintheapplicationscannotmanipulatethestate,unlesstheybelongtoring0.Thisisbecausetherearewell-knownattacksthatabusethisinformationfortrackingusers[18].4.2TheMandatoryAccessControlPolicyESCUDOdenesaMandatoryAccessControl(MAC)policybasedonringsandACLs,andthispolicycontrolshowprincipalsinawebpagecanaccesstheobjects.Forthesakeofpresentation,weusethefollowingnota-tionfordescribingthepolicy:hPBOidenotesaprincipalPtryingtoperformanoperationBonobjectO.R(P)andR(O)denotetheringsoftheprincipalandobjectrespec-tively.O(P)andO(O)denotetheoriginoftheprincipalandobject.Weuseu(O;B)todenotetheleast-privilegedringthatisallowedtoconducttheoperationBontheobject6 O.AnaccessrequesthPBOiispermittedifandonlyiftheaccessispermittedbyallthefollowingthreerules:1.TheOriginRule:O(P)=O(O)Originistheuniquecombinationofhprotocol;domain;portiintheURLofthewebapplicationthatinstantiatestheprincipalorobject.Theoriginrulerequirestheprincipalandobjecttobelongtothesameorigin.However,unliketheSOP,thisisnottheonlybasisforaccess-controldecisions.2.TheRingRule:R(P)R(O)Theringrulefactorsthetrustworthinessoftheprinci-palsandobjectsintothemodel.Theringrulerequiresthattheprincipal'sringshouldbeofequalofgreaterprivilegethantheobject'sring.3.TheACLRule:R(P)u(O;B)TheACLrulefurtherlimitstheaccesscontrolonob-jects.TheACLrulerequiresthattheprincipal'sringbeatleastasprivilegedasthatspeciedfortheoperationbytheobject'sACL.Webapplicationscanavoidinter-ferencebetweenJavaScriptprogramsbelongingtothesameringbyassigningamorerestrictiveringintheACL.However,itshouldbenotedthatwebapplicationscan-notassociateanACLwithanobjectthatislessre-strictivethantheobject'sring.Forexample,anobjectassignedtoringncannothaveanACLthatpermitsaprincipalbelongington0,wheren0�n,toaccesstheobject.EveniftheACLissetincorrectly,theACLwillbeineffectivebecausetheRingRulepreventssuchanaccess.4.3AnExampleTohelpunderstandourmodel,wegiveamorecompleteexampleinFigure3.Thisisanexampleofablogappli-cation.InLine2,theoriginalblogpost(Lines2-11)isas-signedtoring2asaprincipal,anditsACLindicatesthatonlyring0hasthepermissiontoread/write/useit1.Theusercomment(Lines14-19)isassignedtoring3,soevenifthereisamaliciousscriptintheusercomment,thescriptcannotaccessanythingintheoriginalblogpost.Ifaringspecicationismissing,ESCUDOassumesasafede-faultvalue,i.e.theringattributewillbesettotheleast-privilegedring,andtheACLwillbesettor=0,w=0,x=0,allowingonlytheprincipalsinring0toaccessit.5SecurityAnalysisofEscudoThekeytoEscudo'ssecurityenforcementisthesafetyandintegrityofthecongurationprovidedbytheappli-cation.BecauseEscudoisaMACmodel,Escudoreads 1Pleasetemporarilyignorethenumberinthenonceattribute.WewillexplainthepurposeofthatattributeinSection5. Figure3.AssigningDOMelementstorings:Thisisthewebpageofablogapplication.Theoriginalpostedmessageisisolatedfromtheusercom­mentsbyassigningthemtodifferentrings.thecongurationinformationprovidedbytheapplicationandperformstheringmappingexactlyonce.Escudo'sim-plementationdisallowsreassignmentofrings,becausethecongurationinformationisnotexposedtoJavaScriptpro-gramsformodication.Wedescribeadditionalmeasurestoensurethesafetyofthecongurationfromtampering.ThecongurationinformationforalltheprincipalsandobjectsmaintainedinsidethebrowserisnotexposedtoJavaScriptprograms.However,becausetheringmappingforDOMelementsiscommunicatedviaHTML,itisvulnerabletocertaintamperingmethodsviaHTMLandJavaScript.Escudoenforcessomeadditionalrulestoprohibitsuchtamperingmethods.Broadly,therearetwowaysthatHTMLorJavaScriptcouldbeusedforillegallyelevatingprivilege.(1)APrincipalIncreasingPrivilege:AJavaScriptprogrammayattempttoremapanACtagtoahigherprivilegedringusingtheDOMAPIfunctionsetAttribute.RecallthatthecongurationinformationisnotexposedtoJavaScriptprograms.Therefore,suchattemptstomodifytheattributescannotsucceed.(2)APrincipalTryingtoCreateaNewPrincipalwithElevatedPrivilege:HTMLtagscouldbevulner-abletonode-splittingbecauseofvulnerabilitiesintheapplication[21].Inanode-splittingattack,anattackermayprematurelyterminateadivregionusing/div&#x-5.1;䘘,andthenstartanewdivregionwithadifferentsetofringassignments(potentiallywithhigherprivileges).Thisattackescapestheprivilegerestrictionsetonadivregion7 bywebdevelopers.Node-splittingattackscanbepreventedbyusingmarkuprandomizationtechniques,whichinvolveincorporatingrandomnoncesinthedivtags(SeeLines2,11,14,and19inFigure3).Escudoignoresany/div&#x-5.1;ä¡£tagwhoserandomnoncedoesnotmatchthenumberinitsmatchingdivtag.Therandomnoncesaredynamicallygeneratedwhenconstructingawebpage,soadversariescannotpredictthosenumbersbeforetheyinserttheirmaliciouscontentsintoawebpage.JavaScriptprogramscanaddnewDOMelements.Ama-liciousJavaScriptprogrammayattempttousethisfeaturetocreateanewACtagwithhigherprivileges.Escudoen-forcesascopingruletoprotectagainstsuchattempts.ThescopingrulerestrictsallchildelementsofaDOMelementtobemappedtoeitherthesameringorsomelessprivilegedring.Formallyspeaking,whenadivtagislabeledwithring="n",thentheprivilegesoftheprincipalswithinthescopeofthisdivtag,includingallsubscopes,areboundedbyringleveln.Escudo'simplementationstrictlyenforcesthiseveniftheringspecicationofthesubscopeviolatesthisrule.Inaproperlyconguredwebapplication,amaliciousprincipalwouldbelongtotheleastprivilegedring.Asaresult,suchamaliciousprincipalcanonlymodifyDOMel-ementsthataremappedtotheleastprivilegedringforwriteoperation.Thatis,amaliciousprincipalcanaddnewDOMelementsinonlytheleastprivilegedring.ThescopingrulerestrictsallchildelementsofaDOMelementtobemappedtoeitherthesameringoralessprivilegedring.Asaresult,amaliciousprincipalcannotcreateanewprincipalthathashigherprivilegesthanitself.AlltheDOMmodicationsdoneusingtheDOMAPIaresubjecttothescopingrule.6EvaluationWeimplementedaprototypeofESCUDOontheLobowebbrowserandevaluatedtheprototypetoascertainthefeasibilityofdeployingandusingESCUDO.Ourevaluationassessedthefollowing:(1)howwebapplicationscantakeadvantageofESCUDO(2)compatibilitywithlegacywebapplications,(3)resistancetocommonXSSandCSRFat-tacks,and(4)performanceoverhead.6.1ImplementationWeimplementedaprototypeofESCUDOfortheLobowebbrowser[34],anextensibleJava-basedwebbrowser.Loboisintendedtobeaplatformforbuildingnewclient-sideweblanguages.Therefore,thebrowserarchitectureisdesignedtobeeasilyextensible.ImplementingESCUDOonLoboinvolved500linesofcodeforextracting,track-ing,andenforcingtheESCUDOpolicyspeciedbythewebapplication.ESCUDO'simplementationcanbecategorizedintothreeparts:extractingthesecuritycontexts,trackingthesecuritycontexts,andenforcingtheaccesscontrolpol-icy.TheESCUDOimplementationmaintainsasecuritycon-textderivedfromthecongurationinformationprovidedbytheapplication,tracksitthroughthebrowser,andmakesitavailablewheneveraprincipalmakesarequest.Thesecu-ritycontextisinternallymaintaineddatasuchastheringassignments,domain,andACLforalltheprincipalsandobjects.WeimplementedtheESCUDOReferenceMoni-tor(ERM),whichenforcesaccess-decisionsbasedonthesecuritycontexts.TheERMisspreadoverseveralplacesbecausetheplacestoembedthechecksisspecictotheobjecttype.6.2BuildingESCUDO-basedWebApplica-tionsWeanalyzedtwoopen-sourcewebapplications,phpBBandPHP-Calendar,andcreatedESCUDOcongurationsforsecuringthem.phpBB(http://www.phpbb.com/)isamulti-usermessageboardapplicationandPHP-Calendar(http://www.php-calendar.com/)isamulti-useronlinecal-endarapplication.Weanalyzedtheprincipalsandobjectsinthesewebapplicationsandunderstoodtheirsecurityre-quirements.ItdidnottakemorethanadayformodifyingeitherapplicationtouseESCUDO.Adeveloperwhoknowstheapplicationbetterwouldbeabletomakethechangesfaster.phpBB:phpBBisprimarilyusedtocreateanonlinecom-munity,inwhichusersmayinteractwithoneanotherbypostingnewtopicsfordiscussion,respondingtoexistingdiscussionthreads,orsendingprivatemessagestootherusers.ThekeysecurityconcerninphpBBisappropriatelylimitingthecapabilitiesofmessagespostedbyusers.Table2describesthesecurityrequirements.Applicationcontents,suchastrustedJavaScriptprogramsandHTMLformsin-cludedintothewebpagebytheapplication,requireaccesstothemessages,cookies,andtheXMLHttpRequestobject.Topics,replies,andprivatemessages,however,donotre-quiresuchprivileges.Furthermore,user-providedtopics,replies,andprivatemessagesarenotexpectedtomanipu-latethecontentsofthewebpage.WecreatedanESCUDOcongurationthatenforcestheserequirements.TheESCUDOpolicyforphpBBisdescribedinTable3.TheheadportionofthepagecontainsstyleinformationandsometrustedJavaScriptprograms.Theseareallassignedtoring0andcanbemanipulatedonlyfromring0.Thecontentenclosedbetweenthebodyand/bodytagsisamixofapplicationprovidedcontentanduser-providedtopics,replies,andprivatemessages.Thebodytagsareassignedtoring1andcanonlybemanipulatedbyprincipalsinrings0and1.Topics,replies,andprivatemessagesappearinginsidethebodyareassignedtoring3,buttheirACLiscon-guredsothattheycanbemanipulatedonlybyprincipalsinring0,1,and2.Therefore,contentprovidedbyoneuseriscompletelyisolatedfromcontentprovidedbyan-other.Therearetwocookiesinthewebapplication,namelyphpbb2mysql dataandphpbb2mysql sid.Bothcookiesare8 Principal ModifyMessages(DOM) AccessCookies AccessXMLHttpRequest Applicationcontents Yes Yes YesTopicsandreplies No No NoPrivatemessages No No No Table2.Applicationcontentscanmodifymessages,accesscookies,andaccesstheXMLHttpRequestobject.However,topics,replies,andprivatemessagesdonothavesuchcapabilities.Conguration Cookies XMLHttpRequest Applicationcontents Topics&Replies PrivateMessages Ring 1 1 1 3 3 Access-controlList Readaccess 1 1 1 2 2 Writeaccess 1 1 1 2 2 Table3.ESCUDOsecuritycongurationforphpBB:Applicationcontents,cookies,andtheXMLHttpRequestobjectareassignedtoring1.TheACLforcookiesandapplication­contentissetsothatitcanbeaccessedonlyfromrings0and1.Topics,replies,andprivatemessagesareassignedtoring3.TheACLfortopics,replies,andmessagesareconguredtoallowonlyprincipalsinring0­2tomanipulateit,providingisolationbetweenthemessages.assignedtoring1.ThecookiesareattachedonlytoHTTPrequestsgeneratedbyprincipalsbelongingtorings0and1.phpBBusesatemplateenginesimilartoSmartyforsep-aratingtheHTMLlayoutfromtheinternalprocessingthatproducescontentforthewebpage.TospecifytheESCUDOconguration,wemadechangesinthetemplateforeachwebpage.Moreover,phpBBcreatestwosessioncookiesandsendsthemtothebrowserusingtheset-cookieheader.Thereweretwoplacesinthesourcecodethatcreatethecookies.WeusedtheheaderfunctiontoaddanadditionalHTTPheadertospecifytheringmappingforthesecookies.PHP-Calendar:PHP-Calendarismeanttofacilitateagroup'scollaborativecreatingandtrackingofevents.AneventinPHP-Calendarconsistsofatextmessagedescrib-ingtheevent,time,anddateoftheevent.ThekeysecurityconcerninPHP-Calendarisappropriatelylimitingtheca-pabilitiesofeventsinsidethewebapplication.Table4de-scribesthesecurityrequirementsforPHP-Calendar.Appli-cationcontentrequiresprivilegestomodifyevents,sessioncookies,andusetheXMLHttpRequestobject.However,eventsshouldbeprohibitedfrommodifyingothereventsviatheDOMAPIandarenotexpectedtomanipulatecookiesorusetheXMLHttpRequestobject.Thesecurityrequire-mentsforthePHP-CalendarapplicationareverysimilartophpBB.WecreatedanESCUDOcongurationforenforcingthesecurityrequirements.Table5describestheESCUDOpol-icyforPHP-Calendar.InallthewebpagesinsidePHP-Calendar,thebodyofthewebpageisamixofapplicationcontentandusercreatedevents.Thecontentenclosedbe-tweenthebodytagsismappedtoring1anditsACLisconguredtopermitmanipulationonlybyrings0and1.However,asallowedbythescopingrule,theindividualcal-endareventsthatappearwithinthebodyareassignedtoring3andconguredtoallowmanipulationbyrings0,1,and2.Therefore,thevariouscalendareventsareisolatedfromoneanother.Allthesessioncookiesintheapplicationareassignedtoring1,alongwiththeXMLHttpRequestobject.PHP-CalendarhascreatedanHTMLtypesystemusingPHPclassesforseparatingtheHTMLlayoutfromtheinter-nalprocessingrequiredforproducingcontentforthewebpage.Thisorganizationmadeiteasiertomodifythelayouttoincorporatetheisolationpolicies.Forspecifyingtheringmappingforcookies,weusethesametechniqueasweusedforphpBB.FrameworkSupportforESCUDOConguration:Cre-atingESCUDOcongurationsforstaticwebpagesisverystraightforwardbecausethecongurationcanbedirectlyembeddedinthewebpageandisnotexpectedtochange.Inthecaseofwebapplicationswithsignicantportionsofdynamiccode,weneedmoresystematicmethodsforspec-ifyingthecongurations.Otherwise,specifyingthecong-urationwillbecumbersome.HTMLtemplateenginesprovideastructuredmethodforisolatingtheviewelementsfromthebusinesslogic.Theviewelementsarespeciedinatemplateanddatacom-putedatrun-timeispluggedintothetemplatetocreatethewebpage.TheESCUDOcongurationcanbespeciedinthetemplate,isolatingthecongurationfromdynamicdata.SophisticatedtemplateenginessuchasStringTemplate[29]provideastricterseparationbetweenviewandmodel,mak-ingiteasytomanageESCUDOcongurationsforlarge-scalewebapplications.Language-basedinformationowcouldalsobeusedtocreateESCUDOcongurations.TheSIFframeworkisanextensionoftheJavaServletframeworktoenforcecon-dentialityandintegritypoliciesatrun-timeusinglanguage-basedinformationow[10].InSIF,developerprovides9 Principal ModifyMessages(DOM) AccessCookies AccessXMLHttpRequest Applicationcontent Yes Yes YesCalendarevents No No No Table4.Applicationcontentcanmodifymessages,accesscookies,andaccesstheXMLHttpRequestobject.However,calendareventsdonothavesuchcapabilities.Conguration Cookies XMLHttpRequest Applicationcontent Calendarevents Ring 1 1 1 3 Access-controlList Readaccess 1 1 1 2 Writeaccess 1 1 1 2 Table5.ESCUDOsecuritycongurationforPHP­Calendar:Applicationcontent,cookies,andtheXMLHttpRe­questobjectareassignedtoring1.TheACLforcookiesandapplication­contentissetsothatitcanbeaccessedonlyfromrings0and1.Calendareventsareassignedtoring3.TheACLforcalendareventsisconguredtoallowonlyprincipalsinring0­2tomanipulateit,providingisolationbetweentheevents.annotationsinthesourcecodetomarkthecondentialityandintegritypolicies.Thesepoliciesarethenenforcedatrun-timewhentheprogramexecutesattheserver.Thecon-dentialityandintegritypoliciesonthedatacanbeusedtoautomaticallyderivetheESCUDOcongurationforthewebpage,whenthewebpageiscreated.WearecurrentlyworkingonanSIFextensionthatcouldachievethis.Weareunabletodescribetheextensionindetailbecauseofspacelimitations.6.3CompatibilitywithLegacyApplica-tionsTherearetwotypesofcompatibilityconcernswithre-specttoESCUDO:(1)compatibilityofESCUDO-conguredapplicationswithnon-ESCUDObrowsers,and(2)compati-bilityofESCUDO-basedbrowserswithnon-ESCUDOappli-cations.ESCUDO-conguredapplicationsarecompatiblewithnon-ESCUDObrowsers.TheonlyaspectthatdistinguishesanESCUDO-basedapplicationistheavailabilityofringmappingsforcookies,theXMLHttpRequestAPI,andDOMobjects.ForDOMobjects,ringmappingsarespec-iedusingACtags,whichareadditionalattributesinthedivtag.Non-ESCUDObrowserswouldsimplyignoretheseattributes.ForcookiesandtheXMLHttpRequestAPI,ringmappingsarespeciedusinganoptionalHTTPheader;theyalsowillbeignoredbynon-ESCUDObrowsers.ESCUDO-basedbrowsersarealsocompatiblewithnon-ESCUDOapplications.Non-ESCUDOapplicationsdonotprovideanyringmapping.Therefore,allprincipalsandobjectinsidetheapplicationareassignedtoasinglering,effectivelymimickingthesame-originpolicy.6.4DefenseEectivenessWeevaluatedtheeffectivenessofESCUDOinaddress-ingcommonXSSandCSRFproblems.WecreatedXSSandCSRFattacksforbothapplications.Forthepurposeofevaluation,weremovedsomeprotectionmechanismsintheapplicationstofacilitatetheattacks.Inbothapplications,weremovedtheinputvalidationroutinestofacilitateXSSattacks.InphpBB,weremovedthesecret-tokenvalidationprotectiontofacilitateCSRFattacks.PHP-CalendarhadnoprotectionmechanismsforCSRFattacks.Wecreated4XSSattacksforeachwebapplications.InphpBB,wecreatedXSSattacksforpostingnewmessagesonbehalfofvictimusersandformodifyingexistingmes-sages.InPHP-Calendar,wecreatedXSSattacksforcre-atingneweventsonbehalfofvictimusers,andmodifyingexistingevents.Alltheattackswereneutralizedinthepres-enceofESCUDO.Thisisbecausewestructuredtheappli-cationtomapalluser-inuencedregionstobelongtoring3.WecreatedveCSRFattacksforeachwebapplications.Wesetupamaliciouswebsitethatcraftedcross-originrequestsforthetwowebapplications,whenaccessedbyauser.WhenaccessedusingourESCUDO-enabledLobobrowser,themalicioussitestillissuedtherequestsforthetwowebapplications.However,ESCUDOdidnotattachthesessioncookieautomaticallytotherequests(becauseoftheinsufcientprivilegesoftheprincipals),neutralizingtheat-tacks.6.5PerformanceOverheadESCUDO'sexecutionisinvokedduringbothparsingandrenderingofwebpagesandwhilerespondingtoUIevents.Therefore,tomeasuretheperformanceoverheadfromusingESCUDO,wemeasuredtheslowdowninbothactivities.WeinstrumentedLobotomeasuretheamountoftimetakentoparsethewebpageandalsotorespondtoUIevents.Inbothcases,wedidnotobserveanynoticeableoverheadinanyoftheactivities.Wesetup8webpagesvaryingamountsofACtagsanddynamiccontent.Tomeasuretheoverhead10 20 40 60 80 100 120 140 160 180 Parsing and rendering time (ms) Without Escudo Escudo Figure4.Performanceoverheadinparsingandrendering(in8differentscenarios).wecomparedthetimetakenforparsingandrenderingthe8pagesandaveragedtherenderingtimeover90executions(Figure4).Theaverageoverheadwas5.09%.ESCUDOprimarilydoesbookkeepingtokeeptrackoftheprincipalsandthisactivitydoesnotaddanysignicantcost.Similarly,wedidnotnoticeanyoverheadforUIeventhandling.7RelatedWorkSame-originpolicy(SOP)extensions:Jacksonetal.[18]extendstheSOPtobrowsercachecontentandvisitedlinkinformationtoprotectuserprivacy.LivshitsandUlfar[27]extendstheSOPtoadditionallyaccountfortheprincipalnamesaddedtotaggroupsforneutralizingcode-injectionattacks.Karlofetal.[24]extendstheSOPtoaccountforcerticateerrorsintheorigintodistinguishresourcesintheauthenticdomainfromaspoofeddomaintodetectdynamic-pharmingattacks.WhileeachoftheseproposalsaddressesaspecicshortcomingintheSOP,theydonotaddressthegeneralgapbetweenthefundamentalmodelandthesecu-rityrequirementsofmodernwebapplications.ESCUDOisane-grainedprotectionmodelspecicallydesignedtomeettheprotectionneedsofmodernwebapplications.Newbrowserarchitectures:TheOPwebbrowserisolateseachwebpageinstanceandvariousbrowsercomponentsusingOSprocesses[14].Thearchitecturemakescommuni-cationbetweencomponentsexplicitandinterposesitselfinallinter-processcommunicationtoprovideisolationguar-antees.Tahomaisolateseachinstanceofawebapplica-tioninsidethebrowserusingseparatevirtualmachines[20].Thepolicyforidentifyingprogramboundariesandtheper-missiblecharacteristics,suchaswhichURLmaybevisitedineachVM,arespeciedinamanifest.Essentially,thesearetwodifferentapproachesforisolatingwebapplicationsfromoneanotherandlimitingtheirpermissiblebehavior.Bothsharetheweaknessthatthegranularityofprotectionisthewebpage,ratherthanobjectswithinthepage.Incom-parison,ESCUDOprovidesmorene-grainedprotection.Chromium[5,31]andGazelle[38]aretwonewwebbrowserarchitecturesthatbifurcatethebrowserintotwoportions,kernelandapplications,forachievingbettersecu-rityandreliability.However,theaccesscontrolmechanismisstillbasedonthesame-originpolicy.XSSandCSRFsolutions:Currentworkhasproposedsev-eralsolutionsforXSSandCSRFsolutions.ApproachestoXSSincludetaint-tracking[16,28,30],pureclient-sidesolutions[26,37],pureserver-sideapproaches[9],andco-operatingdefenses[21].Similarly,cross-site-requestforgerysolutionscanbecategorizedintoclient-sidemeth-ods[22],HTTPreferrerheadervalidation[25],propos-alsfornewheaders[4],andsecret-tokenvalidationtech-niques[23].Allthesesolutionsareattack-specicpatchestotheapplication,framework,orbrowser.Incontrasttothesesolutionsthataddressthesymptomsoftheunderlyingproblem,ESCUDOisnotapatchforXSSorCSRFprob-lems.Rather,ESCUDOisane-grainedprotectionmodelforwebbrowsers.XSSandCSRFproblemsarethwartedasasideeffectofaddressingthefundamentalweaknessintheprotectionmodel.Inadditiontopatching,inputvalidationandsanitiza-tionisabasicandprimitivedefensivecodingtechniqueforavoidingXSS.FrameworkssuchasPHPandASP.NETpro-videlibrariesforthispurpose.Filteringandsanitizingin-put,althoughusefulasasanitycheck,maybebypassedbyknownevasiontechniques[15,17].Asweshowedearlierinthepaper,ESCUDOpreventssuchattacksevenwhenthefront-linedefensehasbeenbypassed.Mashupsolutions:Mashupsapplicationsintegratecon-tentfromseveralapplicationsfromdifferingoriginsintoonewebpage.Akeysecurityconcerninsuchapplica-tionsisisolatingtheresourcesofeachapplicationfromoneanother.Severalframe-baseddesignproposalsformashupshavecontributednewprimitivesandcommunica-tionmethodswithminimalornochangestothebrowser[3,11,13,19].Still,theseproposalshaveacoarse-grainedprivilegedmodelbecausetheyarebasedonthesame-originpolicy.Mashupsareoutsidethescopeofthispaper.How-ever,ESCUDO'sne-grainedprotectionmodelcouldbeex-tendedtoaddresssecurityrequirementsformashupapplica-tionsbyappropriatelydescribingtherelationshipbetweentheringsofapplicationsfromdifferentorigins.JavaScriptveriers:ThereareseveralstaticanddynamicveriersthatcouldbeusedtoverifyconformanceofaJavaScriptprogramtoasafesubsetofthelanguage[1,2,12,39].Theprimarytargetofthesetoolsareapplicationsthatembeduntrustedandsemi-trustedJavaScriptprogramsfromthirdparties.Verierscanbeconsideredasanalter-nativeapproachtodealingwiththewebbrowseraccess-controlfailure.However,apublishershouldtrustthecon-tentprovidertousetheverierontheJavaScriptprogram.Forexample,apublishermayleaseaportionofhispagetoanadvertisementnetwork.Currently,thepublisherhastotrusttheadvertisingnetworktouseaverierontheJavaScriptprogramprovidedtodisplaytheadvertisement.11 InthecaseofESCUDO,apublishercouldtakeadvantageofthebrowserprotectionmodeltoenforcerestrictionsontheembeddedJavaScriptcontentratherthantrustinganad-vertisementnetwork.Furthermore,ESCUDOisgenericpro-tectionmodelandconstraintsnotonlyJavaScriptprograms,butalsoHTTP-requestinitiatingprincipals.Therefore,ES-CUDOcanrestricttheactionsofanuntrustworthyHTTP-requestinitiatingprincipalmanipulatingmoretrustworthyresources(eg.CSRFattacks),butJavaScriptverierscan-notdothisbecausetheseprincipalsareoutsidethescopeoftheirprotection.8ConclusionThereisadisconnectionbetweentheprotectionneedsofmodernwebapplicationsandtheprevailingprotectionmodel–same-originpolicy.Weoutlinedthreecharacter-isticsthataprotectionmodelshouldhavetoaddressthedisconnection.WepresentedESCUDO,anewprotectionmodelthatissystematicallydesignedtofulllthethreere-quirementsusingmandatoryaccess-controlprinciples.WeimplementedaprototypeofESCUDOintheLobowebbrowser,andillustratedhowwebapplicationscanuseES-CUDOtosecuretheirresourcesusingcasestudies.Oureval-uationsresultsindicatethatESCUDOisapracticalaccess-controlmodel.Inaddition,ESCUDOcanbeincrementallydeployedbecauseitretainsbackwardcompatibilitywithlegacyapplications.References[1]Caja.http://code.google.com/p/google-caja/.[2]WebSandbox.http://websandbox.livelabs.com/.[3]MashupOS:operatingsystemabstractionsforclientmashups.InHOTOS,2007.[4]A.Barth,C.Jackson,andJ.C.Mitchell.Robustdefensesforcross-siterequestforgery.InACMCCS,2008.[5]A.Barth,C.Jackson,andC.Reis.Thesecurityarchitectureofchromiumbrowser.http://crypto.stanford.edu/websec/chromium/.[6]D.E.BellandL.J.LaPadula.SecureComputerSystem:UniedExpositionandMulticsInterpretation,1976.[7]K.J.Biba.IntegrityConsiderationsforSecureComputerSystems,April1977.[8]M.A.Bishop.TheArtandScienceofComputerSecurity.Addison-WesleyLongmanPublishingCo.,Inc.,2002.[9]P.BishtandV.Venkatakrishnan.XSS-GUARD:PreciseDynamicPreventionofCross-SiteScriptingAttacks.InDIMVA,2008.[10]S.Chong,K.Vikram,andA.C.Myers.Sif:enforcingcondentialityandintegrityinwebapplications.InUSENIX-SS,2007.[11]S.Crites,F.Hsu,andH.Chen.Omash:enablingsecurewebmashupsviaobjectabstractions.InACMCCS,2008.[12]D.Crockford.ADSafe.http://www.adsafe.org.[13]F.DeKeukelaere,S.Bhola,M.Steiner,S.Chari,andS.Yoshihama.Smash:securecomponentmodelforcross-domainmashupsonun-modiedbrowsers.InWWW,2008.[14]C.Grier,S.Tang,andS.T.King.Securewebbrowsingwiththeopwebbrowser.InIEEES&P,2008.[15]J.Grossman.Cross-sitescriptingwormsandviruses.Theimpendingthreatandthebestdefense.http://www.whitehatsec.com/downloads/WHXSSThreats.pdf.[16]M.V.GundyandH.Chen.Noncespaces:Usingrandomizationtoenforceinformationowtrackingandthwartcross-sitescriptingat-tacks.InNDSS,2009.[17]R.Hansen.XSScheatsheet.http://ha.ckers.org/xss.html.[18]C.Jackson,A.Bortz,D.Boneh,andJ.C.Mitchell.Protectingbrowserstatefromwebprivacyattacks.InWWW,2006.[19]C.JacksonandH.J.Wang.Subspace:securecross-domaincommu-nicationforwebmashups.InWWW,2007.[20]R.C.Jacob,R.S.Cox,J.G.Hansen,S.D.Gribble,andH.M.Levy.Asafety-orientedplatformforwebapplications.InIEEES&P,2006.[21]T.Jim,N.Swamy,andM.Hicks.Defeatingscriptinjectionattackswithbrowser-enforcedembeddedpolicies.InWWW,2007.[22]M.JohnsandJ.Winter.RequestRodeo:Client-sideprotectionagainstsessionriding.InOWASPEurope,2006.[23]N.Jovanovic,E.Kirda,andC.Kruegel.Preventingcrosssiterequestforgeryattacks.InIEEES&P,2006.[24]C.Karlof,U.Shankar,J.D.Tygar,andD.Wagner.Dynamicpharm-ingattacksandlockedsame-originpoliciesforwebbrowsers.InACMCCS,2007.[25]F.Kerschbaum.Simplecross-siteattackprevention.InSecureComm,2007.[26]E.Kirda,C.Kruegel,G.Vigna,andN.Jovanovic.Noxes:aclient-sidesolutionformitigatingcross-sitescriptingattacks.InACMSAC,2006.[27]B.LivshitsandU.Erlingsson.Usingwebapplicationconstructionframeworkstoprotectagainstcodeinjectionattacks.InPLAS,2007.[28]Y.Nadji,P.Saxena,andD.Song.Documentstructureintegrity:Arobustbasisforcross-sitescriptingdefense.InNDSS,2009.[29]T.J.Parr.Enforcingstrictmodel-viewseparationintemplateen-gines.InWWW,2004.[30]T.PietraszekandC.V.Berghe.Defendingagainstinjectionattacksthroughcontext-sensitivestringevaluation.InRAID,2005.[31]C.ReisandS.D.Gribble.Isolatingwebprogramsinmodernbrowserarchitectures.InEuroSys,2009.[32]J.H.SaltzerandM.D.Schroeder.Theprotectionofinformationincomputersystems.ProceedingsoftheIEEE,1975.[33]M.D.SchroederandJ.H.Saltzer.Ahardwarearchitectureforim-plementingprotectionrings.Commun.ACM,15(3),1972.[34]J.Solorzano.TheLoboProject.http://lobobrowser.org/.[35]M.TerLouw,P.Bisht,andV.Venkatakrishnan.AnalysisofhypertextisolationtechniquesforXSSprevention.InW2SP,2008.[36]A.Vance.Timeswebadsshowsecuritybreach.http://www.nytimes.com/2009/09/15/technology/internet/15adco.html.[37]P.Vogt,F.Nentwich,N.Jovanovic,E.Kirda,C.Kruegel,andG.Vi-gna.Cross-sitescriptingpreventionwithdynamicdatataintingandstaticanalysis.InNDSS,2007.[38]H.Wang,C.Grier,A.Moshchuk,S.King,P.Choudury,andH.Ven-ter.Themulti-principalosconstructionofthegazellewebbrowser.InUSENIX-SS,2009.[39]K.Zyp.SecureMashupswithdojox.secure.http://www.sitepen.com/blog/2008/08/01/secure-mashups-with-dojoxsecure/.12