Information-flow security for JavaScript and its APIs

102 Pages·2015·0.59 MB·English

JournalofComputerSecurity0(2015)1–102 1
IOSPress
Information-flow security for JavaScript and
its APIs
DanielHedin,LucianoBello,andAndreiSabelfeld∗
DepartmentofComputerScienceandEngineering,ChalmersUniversityofTechnology
EDITBuilding,Rännvägen6B,41296Gothenburg,Sweden
E-mail:{daniel.hedin,bello,andrei}@chalmers.se
Abstract.JavaScriptdrivestheevolutionofthewebintoapowerfulapplicationplatform.Increasingly,webapplicationscom-
bineservicesfromdifferentproviders.Thescriptinclusionmechanismroutinelyturnsbarebonewebpagesintofull-fledgedser-
vicesbuiltupfromthird-partycode.Scriptinclusionposesachallengeofensuringthattheintegratedthird-partycoderespects
securityandprivacy.
ThispaperpresentsadynamicmechanismforsecuringscriptexecutionsbytrackinginformationflowinJavaScriptandits
APIs.Ontheformalside,thepaperidentifieslanguageconstructsthatconstituteacoreofJavaScript:dynamicobjects,higher-
orderfunctions,exceptions,anddynamiccodeevaluation.Itdevelopsadynamictypesystemthatguaranteesinformation-flow
securityforthislanguage.Basedonthisformalmodel,thepaperpresentsJSFlow,apracticalsecurity-enhancedinterpreter
for fine-grained tracking of information flow in full JavaScript and its APIs. Our experiments with JSFlow deployed as a
browser extension provide in-depth understanding of information manipulation by third-party scripts. We find that different
sitesintendedtoprovidesimilarserviceseffectuateratherdifferentsecuritypoliciesfortheuser’ssensitiveinformation:some
ensure it does not leave the browser, others share it with the originating server, while yet others freely propagate it to third
parties.
Keywords:webapplicationsecurity,JavaScript,informationflow,referencemonitoring,noninterference
1. Introduction
Increasingly,webapplicationscombineservicesfromdifferentproviders.Thescriptinclusionmecha-
nismroutinelyturnsbarebonewebpagesintofull-fledgedservices,oftenutilizingthird-partycode.Such
code provides a range of facilities from utility libraries (such as jQuery) to readily available services
(suchasGoogleAnalyticsandTynt).Evenstand-aloneservicessuchasGoogleDocs,MicrosoftOffice
365, and DropBox offer integration into other services. Thus, the web is gradually being transformed
intoanapplicationplatformforintegrationofservicesfromdifferentproviders.
Motivation: Securing JavaScript At the heart of this lies JavaScript. When a user visits a web page,
evenasimpleonelikealoancalculatororanewspaperwebsite,JavaScriptcodefromdifferentsources
is downloaded into the user’s browser and run with the same privileges as if the code came from the
*Correspondingauthor
0926-227X/15/$27.50(cid:13)c 2015–IOSPressandtheauthors.Allrightsreserved
2 D.Hedin,L.Bello,A.Sabelfeld/Information-flowsecurityforJavaScriptanditsAPIs
webpageitself.Thisopensuppossibilitiesforabuseoftrust,eitherbydirectattacksfromtheincluded
scripts or, perhaps more dangerously, by indirect attacks when a popular service is compromised and
itsscriptsarereplacedbyanattacker.Alarge-scaleempiricalstudy[52]ofscriptinclusionreportshigh
reliance on third-party scripts. As an example, it shows how easy it is to get code running in thousands
of browsers simply by acquiring some stale or misspelled domains. A recent real-life example is an
attackonReutersinJune2014,attributedto“SyrianElectronicArmy”,whichcompromisedathird-party
widgetforcontent-targeting(Taboola)toredirectvisitorsfromReuterstoanotherwebsite[63].
Thisposesachallenge:howdoweguaranteethattheintegratedthird-partycoderespectsthesecurity
andprivacyofwebapplications?
Atthesametime,thebusinessmodelofmanyoftheonlineserviceprovidersistogiveawayaservice
forfreewhilegatheringinformationabouttheirusersandtheirbehaviorinorderto,e.g.,selluserprofiles
orprovidetargetedads.Howdowedrawalinebetweenlegitimateinformationgatheringandunsolicited
usertracking?
Background: State of the art in securing JavaScript Today’s browsers enforce the same-origin policy
(SOP) in order to limit access between scripts from different Internet domains. SOP offers an all-or-
nothing choice when including a script: either isolation, when the script is loaded in an iframe, or full
integration, when the script is included in the document via a script tag. SOP prevents direct communi-
cation with non-origin domains but allows indirect communication. For example, sensitive information
fromtheusercanbesenttoathird-partydomainaspartofanimagerequest.
Although loading a script in an iframe provides secure isolation, it severely limits the integration of
the loaded code with the main application. Thus, the iframe-based solution is a good fit for isolated
servicessuchascontext-independentads,butitisnotadequateforcontext-sensitiveads,statistics,utility
libraries,andotherservicesthatrequiretighterintegration.
Loading a script via a script tag provides full privileges for the included script and, hence, opens up
forpossibleattacks.ThestateoftheartinresearchonJavaScript-basedsecurecomposition[59]consists
of a number of approaches ranging from isolation of components to their full integration. Clearly, as
much isolation as possible for any given application is a sound rationale in line with the principle of
least privilege [62]. However, there are scenarios where isolation incapacitates the functionality of the
application.
As an example, consider a loan calculator website. The calculator requires sensitive input from the
user, such as the monthly income or the total loan amount. Clearly, the application must have access to
thesensitiveinputforproperfunctionality.Atthesametime,theapplicationmustbeconstrainedinwhat
itcandowiththesensitiveinformation.Iftheuserhasabusinessrelationshipwiththeserviceprovider,it
mightbereasonableforthisinformationtobesentbacktotheproviderbutremainconfidentialotherwise.
However,ifthisisnotthecase,itismorereasonablethatsensitiveinformationdoesnotleavethebrowser.
Howdoweensurethatthesekindsoffine-grainedpoliciesareenforced?
As another example, consider a third-party service on a newspaper site. The service appends the link
totheoriginalarticlewhenevertheusercopiesapieceoftextfromit.Theapplicationmusthaveaccess
to the selected text for proper functionality (there is no way of appending to the clipboard - the data
mustberead,modifiedandwrittenback).However,withthecurrentstateoftheartinwebsecurity,any
third-party code can always send information to its own originating server, e.g. for tracking. When this
is undesired, how do we guarantee that this trust is not abused to leak sensitive information to the third
party?
Unfortunately, access control is not sufficient to guarantee information security in these examples.
Boththeloancalculatorandnewspapercodemustbegiventhesensitiveinformationinordertoprovide
D.Hedin,L.Bello,A.Sabelfeld/Information-flowsecurityforJavaScriptanditsAPIs 3
the intended service. The usage of sensitive information needs to be tracked after access to it has been
granted.
Goal: Securing information flow in the browser Those scenarios motivate the need of information-
flowcontroltotrackhowinformationisusedbysuchservices.Intuitively,aninformation-flowanalysis
tracks how information flows through the program under execution. By identifying sources of sensitive
information,aninformation-flowanalysiscanlimitwhattheservicemaydowithinformationfromthose
sources,e.g.,ensuringthattheinformationdoesnotleavethebrowser,orisnotsenttoathirdparty.
The importance of tracking information flow in the browser has been pointed out previously,
e.g., [43,70]. Further, several empirical studies [67,36,30,28] (discussed in detail in Section 9) provide
clear evidence that privacy and security attacks in JavaScript code are a real threat. The focus of these
studiesisbreadth:tryingtoanalyzethousandsofpagesagainstsimplepolicies.
Complementary to the previous work, our overarching goal is an in-depth approach to information
flow tracking in practical JavaScript. This leads us to separate the goal into fundamental and practical
parts:
First, our goal is to resolve the fundamental challenges for tracking information flow in a highly dy-
namiclanguageatthecoreofJavaScript:withfeaturessuchasdynamicobjects,higher-orderfunctions
anddynamiccodeevaluation.Thisgoalincludesaformalmodeloftheenforcementmechanisminorder
toguaranteesecureinformationflow.
Second,ourgoalistopushthefundamentalapproachallthewaytopractice:toextendtheenforcement
tofullJavaScript,implementit,andevaluateonwebpageswherein-depthunderstandingofinformation-
flowpoliciesisrequired.
Objectives:JavaScriptandlibraries ThedynamismofJavaScriptputsseverelimitationsonstaticanal-
ysismethods[64].Theselimitationsareofparticularconcernwhenitisdesirabletopinpointthesource
ofinsecurity.Whilestaticanalysiscanbereasonableforempiricalstudieswithsimplesecuritypolicies,
the situation is different for more complex policies. Because dynamic tracking has access to precise
information about the program state in a given run, it is more appropriate for in-depth understanding
of information flow in JavaScript. With this in mind, our overarching goal translates into the following
concreteobjectives.
1. ThefirstobjectiveistoidentifyacoreofJavaScriptthatembodiestheessentialconstructsfromthe
pointofviewofinformationflowcontrol.Wesetouttoproposedynamicinformationflowcontrol
forthecode,withthetechnicalchallengesexpandedinSection3.
2. The second objective is covering the full non-strict JavaScript language, as described by the
ECMA-262 (v.5) standard [24]. This part draws on the sound analysis for the core of JavaScript,
and so the challenge is whether the rich security label mechanism and key concepts such as read
andwritecontextsscaletothefulllanguage.
3. Thethirdobjectiveiscoveringlibraries,bothJavaScript’sbuiltinobjectsaswellasonesprovided
by browser APIs. The Document Object Model (DOM) API, a standard interface for JavaScript to
interact with the browser, is particularly complex. This challenge is substantial due to the stateful
nature of the DOM tree. Attempts to provide “security signatures” to the API result in missing
security-critical side effects in the DOM. The challenge lies in designing a more comprehensive
approach.
4. ThefourthobjectiveisimplementingtheJavaScriptinterpreterinJavaScript.Thisallowstheinter-
pretertobedeployedasaFirefoxextensionbyleveragingtheideasofZaphod[50].Theinterpreter
4 D.Hedin,L.Bello,A.Sabelfeld/Information-flowsecurityforJavaScriptanditsAPIs
keepstrackofthesecuritylabelsand,wheneverpossible,itreusesthenativeJavaScriptengineand
standardlibrariesfortheactualfunctionality.
5. Thefifthobjectiveisevaluationoftheapproachonscenarioswherein-depthunderstandingofmod-
ern third-party scripts (such as Google Analytics) is required. Following the scenarios mentioned
above, the focus of the evaluation is on loan calculator web sites and web sites with behavioral
tracking.
Contributionsandoverview Afterrecallingthebasicsofdynamicinformation-flowcontrol(Section2),
we spell out the challenges of securing JavaScript (Section 3). The challenges are divided into three
sections:challengesrelatedtothelanguage,challengesrelatedtoafull-scaleimplementation,andchal-
lengesrelatedtodynamicenforcement.Together,thechallengesjustifythechoiceoftheJavaScriptcore,
andillustratekeyissuesrelatedtoapracticalimplementation.
Addressing the first objective, we identify a language that constitutes a core of JavaScript. Such lan-
guage includes the following constructs: dynamic objects, higher-order functions, exceptions, and dy-
namiccodeevaluation(Section4).Wearguethatthechoiceofthecorecapturestheessenceofthelan-
guage. It allows us to concentrate on the fundamental challenges for securing information flow in dy-
namic languages. While we address the major challenge of handling dynamic language constructs, we
alsoresolveminorchallengesassociatedwithJavaScript.Thesemanticsofthelanguagecloselyfollows
theECMA-262standard(v.5)[24]onthelanguageconstructsfromthecore.
We develop a dynamic type system for information-flow security for the core language (Section 4)
and establish that the type system enforces a security policy of noninterference [17,27], that prohibits
informationleaksfromtheprogram’ssecretsourcestotheprogram’spublicsinks(Section5).
Addressing the second objective, we scale up the enforcement to cover the full JavaScript language
(Section6).Thescaled-upenforcementtightlyfollowstheenforcementprinciplesforthecore,indicating
thatthechoiceofthecoreiswell-justified,andimplementsthesolutionsoutlinedbytheimplementation
challenges.
Addressing the second and fourth objectives, we report on the implementation of the JSFlow, an
information-flowinterpreterforfullnon-strictECMA-262(v.5)(Section6).JSFlowisitselfimplemented
in JavaScript. This enables the use of JSFlow as a Firefox extension, Snowfox, as well as on the server
side,e.g.,byrunningontopofnode.js[37].Theinterpreterpassesallstandardcompliantnon-stricttests
intheSpiderMonkeytestsuite[49]passedbySpiderMonkeyandV8.
Addressingthethirdandfourthobjectives,inadditiontothecorelanguagewehavedesignedandim-
plementedextensivestatefulinformation-flowmodelsforthestandardAPI(Section7).Thisincludesall
ofthestandardAPI,aswellastheAPIpresentinabrowserenvironment,includingtheDOM,navigator,
location and XMLHttpRequest. A distinction is made between shallow and deep models, which repre-
sentdifferenttrade-offsbetweenreimplementingnativecodeandmaintainingamodelofitsinformation
flow.
Tothebestofourknowledge,thisisthefirsteffortthatbridgesallthewayfromtheorytoimplemen-
tation of dynamic information-flow enforcement for such a large platform as JavaScript together with
statefulinformation-flowmodelsforitsstandardexecutionenvironment.
Addressingthefifthobjective,wereportonourexperiencewithJSFlow/Snowfoxforin-depthunder-
standing of existing flows in web pages (Section 8). Rather than experimenting with a large number of
websitesforsimplepolicies(asdoneinpreviouswork[67,36,30,28]),wefocusonin-depthanalysisof
twocasestudies.
The case studies show that different sites intended to provide similar service (a loan calculator) en-
force rather different security policies for possibly sensitive user input. Some ensure it does not leave
D.Hedin,L.Bello,A.Sabelfeld/Information-flowsecurityforJavaScriptanditsAPIs 5
the browser, others share it only with the originating server, while yet others freely share it with third
party services. The empirical knowledge gained from running such case studies on actual web pages
and libraries has been invaluable in order to understand the possibilities and limitations of dynamic
information-flowtracking,andtosetthedirectionsforfutureresearch.
Thepapermerges,expands,andimprovesourpreviouslydisjointeffortsontheory[34]andimplemen-
tation[33]ofinformation-flowcontrolforJavaScript.Inadditiontounifyingtheseefforts,thefollowing
arethemostprominentfeaturesthatoffervalueoverthepreviouswork.
– We have reworked the rules for Delete and Put of the ECMA objects to make them more intuitive
andtomaketheirrelationclearer.
– Wehaveaddedthefullproofofsoundnessofthecorelanguage.
– Wehavesignificantlyreworkedseveralsectionstoimprovethereadabilityofthepaper.Inparticular,
we have 1) added Section 2 on dynamic information flow, 2) reworked Section 3 to more clearly
state the challenges and their solutions, as well as added some examples and challenges, and 3)
performedasignificantexpansionofSection4onthecorelanguage.
– Based on our practical experiments we have reworked the upgrade instructions. Instead of raising
thesecuritylabelsofvaluestoastaticlabels,adynamicupgradeallowsavaluetobeupgradetothe
securitylabelofanothervalue.
2. Dynamicinformationflow
Before presenting the security challenges, we briefly recap standard information-flow terminol-
ogy[20].Traditionally,informationflowanalyzesdistinguishbetweenexplicitandimplicitflows.
Inthefollowingexampleslethandl representhighandlowvariables,i.e.secretandpublicinforma-
tion.Explicitflowsamounttodirectlycopyinginformation,e.g.,viaanexplicitassignmentlikel = h;,
wherethevalueofasecret(orhigh)variablehiscopiedintoapublic(orlow)variablel.Highandlow
representsecuritylevels.Thistwo-levelmodelcanbegeneralizedtoarbitrarysecuritylattices[19].
Implicit flows may arise when the control flow of the program is dependent on secrets. Consider the
program:
if (h) {l = 1;} else {l = 0;}
Dependingonthesecretstoredinvariableh,variablelwillbesettoeither1or0,reflectingthevalue
of h. Hence, there is an implicit flow from h into l. In order to handle implicit flows, a security level
associated with the control flow is introduced, called the program counter level, or pc for short. In the
aboveexample,thebodyoftheconditionalisexecutedinasecretcontext.Equivalently,thebranchesof
theconditionalaresaidtobeundersecretcontrol.Thedefinitionofpubliccontextandpubliccontrolare
naturalduals.
The pc reflects the confidentiality of guard expressions controlling branch points in the program, and
governssideeffectsintheirbranchesbypreventingmodificationoflessconfidentialvalues.
Dynamicinformationflowenforcement Dynamicinformation-flowanalysisissimilartodynamictype
analysis.Securitylabelsareusedtostoresecuritylevelsforassociatedvariables—eachvalueislabeled
with a security label representing the confidentiality of the value. Since the security label is associated
with values dynamic information flow enforcement is naturally flow sensitive. Consider the following
program.
6 D.Hedin,L.Bello,A.Sabelfeld/Information-flowsecurityforJavaScriptanditsAPIs
l = h;
Eventhoughtheoriginalvalueoflislabeledpublictheresultoftheassignmentwilloverwriteboththe
value and the security label with the value and security label of h. Thus, in the dynamic setting explicit
flowsarenotproblematicperse,unlesstheflowistoalocationthatcanbeobservedbytheadversary.
Thereisaknownlimitation [26,57]oftheflowsensitivityofdynamicanalyzes.Considerthefollowing
example,whereweassumehis1or0originally:
l = 1; t = 0;
if (h == 1) {t = 1;}
if (t != 1) {l = 0;}
Ifsecuritylabelsareallowedtochangefreelyundersecretcontrol,theaboveprogramresultsinthevalue
ofhbeingcopiedintolwithoutchangingthesecuritylabelofl.
Inordertopreventsuchleaksitsufficestodisallowsecuritylabelupgradesundersecretcontrol.This
correspondstoAustinandFlanagan’snosensitiveupgrade(NSU)[3]discipline.Forsoundness,security
violations force execution to halt [34]. Hence, the execution of the above program is stopped with a
securityerror.
Readandwritecontexts Theexplanationofdynamicinformationflowenforcementinalanguagewith
references is facilitated by the notions of read context and write context. All information-flow control
rulesinthispaperaregovernedbythosetwoprinciples.
The read context for an entity is the accumulated security label of the access path of the entity. For
a property, the access path is the primitive reference to the object containing the property together with
propertyname.Whenreading,theresultisraisedbysecuritylabelofthereadcontext.
To illustrate the notion of access path and read context consider the following program, where the
access path to the property identified by the value of p in o is the security label of o together with the
securitylabelofp.
x = o[p];
Thesecuritylabelofthevaluewrittentoxisthesecuritylabelofthevaluestoredatthereadproperty
raisedbythesecuritylabelofoandp.
The write context of an entity is the read context together with the security context, i.e., the program
counter.Whenwritingtoanentity,NSUdemandsthatthesecuritylabeloftheentityisatleastassecret
asthewritecontextofit.
The notion of write context is illustrated in the following program, where the access path is the same
asintheexampleabove,butwherethewriteadditionallytakesplaceunderthecontrolofx.
if (x) {
o[p] = y;
}
Inthisexample,thedemandfromthewritecontexttranslatesintothedemandthelabelofthetargetis
belowthelabelsofx,oandp.
D.Hedin,L.Bello,A.Sabelfeld/Information-flowsecurityforJavaScriptanditsAPIs 7
3. Challenges
Theultimategoalofthisworkispracticalenforcementofinformation-flowsecurityinJavaScript.This
entailsbothasolidtheoreticalbaseaswellasafullscaleimplementation.Reflectingthis,thissectionis
dividedintothreeparts.First,weoutlinethemainlanguagechallengesofJavaScript.Thisillustratesthe
corelanguagepresentedinSection4.Second,weoutlinethechallengesofextendingthecorelanguage
tofullJavaScriptasdefinedintheECMA-262(v.5)[24]standard(sometimesreferredtoasthestandard
henceforth)andhowtheyrelatetothecorechallenges.Finally,wediscusschallengesrelatingtodynamic
enforcement of secure information flow. For each of the challenges we first illustrate the problem and
giveourapproachtosolvingit.
3.1. Languagechallenges
JavaScript is a dynamically typed, object-based language with higher-order functions and dynamic
codeevaluationvia,e.g.,theevalconstruction.ThevoluminousECMA-262(v.5)[24]standarddescribes
thesyntaxandsemanticsofJavaScript.Thechallengeisidentifyingasubsetofthestandardthatcaptures
the core of JavaScript from an information-flow perspective, i.e., where the left-out features are either
expressible in the core, or where their inclusion does not reveal new information-flow challenges. We
identify the core of the language to be: dynamic objects, prototype inheritance, higher-order functions,
exceptions,anddynamiccodeevaluation.Inaddition,weshowthatthewell-knownproblemsassociated
with the JavaScript variable handling and the with construct can be handled via a faithful modeling in
termsofobjects.
3.1.1. Dynamiccodeevaluation:eval
The runtime possibility to parse and execute a string in a JavaScript program, provided by the eval
instruction, poses a critical challenge for static program analyzes, since the string may not be available
toastaticanalysis.
Our approach: Dynamic analyzes do not share this limitation, by virtue of the fact that dynamic ana-
lyzesareexecutedatruntime.
3.1.2. Aliasingandflowsensitivity
ThetypesystemofJavaScriptisflowsensitive:thetypesof,e.g.,variablesandpropertiesareallowed
to vary during the execution. In addition, objects in JavaScript are heap allocated and represented by
primitivereferences—theirheaplocation.Hence,objectsinJavaScriptmaybealiased.Analiasoccurs
whentwosyntacticallydifferentprogramlocations(e.g.,twovariablesxandy)refertothesameobject
(containthesameprimitivereference).
Flowsensitivityinthepresenceofaliasesposesasignificantchallengeforstaticanalyzes,sincechang-
ingthelabelsofoneofthelocationsrequiresthatthesecuritylabelsofallaliasedlocationsarechanged
aswell,whichrequiresthestaticanalysistokeeptrackofthealiasing.
Ourapproach:Dynamicapproachesdonotsharethislimitation,sincetheyareabletostorethesecurity
label in the referred object instead of associating it with the syntactic program location. Consider the
followingprogram:
x = new Object();
x.f = 0;
y = x;
y.f = h;
8 D.Hedin,L.Bello,A.Sabelfeld/Information-flowsecurityforJavaScriptanditsAPIs
First, a new object is allocated and the primitive reference to the object is stored into x. Thereafter, the
property f of the newly allocated object is set to 0, and y is made an alias of x. Finally, the property
f is overwritten by a secret via y. This kind of programs are rejected by static analysis like Jif [51]. In
the dynamic setting, we simply update the security label of the value of the property f of the allocated
object.
3.1.3. Dynamicobjects:structureandexistence
JavaScriptobjectsaredynamicinthesensethatpropertiescanbeaddedtoorremovedatruntime.This
createsasituationwherenotonlythevaluesofpropertycanbeusedtoencodeinformation,butalsotheir
presenceorabsence.Considerthefollowingexample:
o = {};
if (h) {o.q = 0};
Afterexecutionoftheconditionaltheanswertothequestionwhetherq isinthedomainofogivesaway
thevalueofh.Itisimportanttonotethatboththepresenceandtheabsenceofq givesawayinformation
— copying the value of h into l via the presence/absence of q can easily be done by executing, e.g.,
l = (o.q != undefined);(projectingnon-existingpropertiesreturnsundefined).
Our approach: We solve this by associating an existence security label with every property and a
structure security label with every object. The demand is that changing the structure of the object by
adding or removing properties under secret control is possible only if the structure security label of the
objectissecret.Oncethestructureofanobjectissecret,knowingtheabsenceofpropertiesintheobject
isalsosecret.
3.1.4. Exceptions
Exceptions offer further intricacies, since they allow for non-local control transfer. Any instructions
following an instruction that may throw an exception based on a secret must be seen as being under
secretcontrol,since,similartotheconditional,theinstructionmayormaynotberunbasedonwhether
theexceptionisthrownornot.Considerthefollowingexample:
l = true;
if (h) { throw 0; }
l = false;
Whetherhis0ornotcontrolswhetherthesecondupdateisrunornotandhencel encodesinformation
abouth.
Ourapproach:Weintroduceasecuritylabelforexceptions,theexceptionsecuritylabel.Theexception
securitylabelisanupperboundonthelabelofthesecuritycontextinwhichexceptionsareallowed.Ifthe
exceptionsecuritylabelispublic,exceptionsundersecretcontrolareprohibited.Theexceptionsecurity
label and the pc together form the security context that governs side effects. That is, if the exception
securitylabelissecret,thesecuritycontextissecretandsideeffectsareconstrained.
3.1.5. Higher-orderfunctions
Being first class values, functions carry a security type that must be taken into consideration when
calling the function. Consider the following example, where a secret function f is created by choosing
betweentwofunctionsundersecretcontrol.
D.Hedin,L.Bello,A.Sabelfeld/Information-flowsecurityforJavaScriptanditsAPIs 9
var l;
if (h) {f = function g() { l = 1; };}
else {f = function g() { l = 0; };}
f();
Dependingonthesecreth,afunctionthatwrites1orafunctionsthatwrite0tol ischosen.Callingthe
selectedfunctioncopiesthevalueofhintol.
Ourapproach:Thebodyofthefunctionmustberuninasecuritycontextthatisatleastassecretasthe
securitylabelofthefunction.Thisdisciplineisinspiredbystatichandlingofhigher-orderfunctions[53].
3.1.6. Variablesandscoping
JavaScript is known for its non-standard scoping rules. Variable hoisting in combination with non-
syntactic scoping, the with and eval constructions, and the fact that assigning to undeclared variables
causesthevariabletobedefinedglobally,causecomplexandsometimesunexpectedbehavior.Toappre-
ciatethisconsider,e.g,conditionalshadowingusingeval.
f = function f(x) {if (h) {eval(’var l’)}; l = 0}
InordertounderstandthisexamplewemustknowmoreaboutfunctionsandscopinginJavaScript.First,
thevariableenvironmentsformachain.Variablelookupstartsinthetopmostenvironmentandcontinues
downthechainuntilthevariablehasbeenfoundortheendofthechainhasbeenreached.
Second, both if and eval are unscoped, i.e., the variable declared by the eval is declared in the top-
most variable environment of the function call. The use of eval is to prevent variable hoisting until the
executionoftheconditionalbranch.Otherwise,l wouldbehoistedoutoftheconditionalandalwaysbe
declaredregardlessofthevalueofh.
Execution of f is split into two cases. If h is true, the variable is defined locally in the function, and
theupdateofliscapturedbythelocall.Ifhisfalse,liscreatedintheglobalvariableenvironment.
Asimilarsituationcanbecreatedusingwiththattakesanobjectandinjectsitintothevariablechainal-
lowingthepropertiesoftheinjectedobjecttoshadowvariablesdeclaredhigherupinthechain.Consider
thefollowingexample.
o = {};
if (h) { o[’l’] = 1 }
with (o) {
l = 0;
}
When the update l = 0; is executed, the variable lookup will first look in the topmost environment
record, i.e., the injected o object. If the object defines a property with the name l, the variable lookup
terminatesreturningareferencetotheobject.Otherwisethelookupcontinuesintheremainingvariable
environment chain. In the above example, in case h is true the update is captured byo. If h is false, l is
createdintheglobalvariableenvironment.
The result is that both the value of l in the global variable environment and potentially its existence
encodes information about h. The latter implies that, similar to objects, we must track the structure of
variableenvironments.Inaddition,thepresenceorabsenceofthelinthelocalvariableenvironment(or
elsewhereinthechain)effectswheretheupdatetakesplace.
10 D.Hedin,L.Bello,A.Sabelfeld/Information-flowsecurityforJavaScriptanditsAPIs
Ourapproach:WeshowthattheintricatevariablebehaviorofJavaScriptcanbehandledbyafaithful
modelingoftheexecutioncontextintermsofbasicobjectsandobjectoperations.
3.1.7. Prototypehierarchy
In a similar way the prototype chain that forms the basis for prototype based inheritance can cause
intricate behavior. In JavaScript functions are used to create new objects. The body of the function acts
asaconstructorforthenewlycreatedobjectandthecontentsoftheprototypepropertyiscopiedintothe
prototype chain of the object. The prototype chain is then traversed when looking up a property in the
object.Thisisdoneinasimilarmannertothevariablechain.Considerthefollowingexample.
function f() { };
f.prototype.l = 0;
var x = new f();
Executing x[’l’] would return 0 even though x does not define the property l itself. Instead it is the
propertyloftheprototypethatisreturned.Considerthefollowingadditiontotheaboveexample.
function g() { };
g.prototype = x;
x = new g();
Wecreateanewfunctiongandlettheprototypefieldofgbex,i.e.,theobjectcreatedbyf,andweletx
beanobjectcreatedbyg.Executingx[’l’]wouldresultin0eventhoughneitherxnortheimmediate
prototype of x defines l. The prototype of the prototype of x does, however, and its property l is found
anditsvalue,0,isreturned.Inthisway,xinheritsthepropertiesofallprototypesintheprototypechain.
Nowconsiderthefollowingadditiontotheexample.
if (h) {
g.prototype.l = 1;
}
Since the prototype chain is traversed for each property lookup modifications of the prototypes in the
prototypechainmaycauseeffectsonthepropertylookup.Incasehistruethepropertylisaddedtothe
immediate prototype of x. This shadows the previous property l and executing x[’l’] now returns 1
insteadof0.
Our approach: We show that the intricacies of prototype inheritance can be handled by a faithful
modelingintermsofbasicobjectsandobjectoperations.
3.2. TacklingfullJavaScript
A practical implementation of secure information-flow enforcement for JavaScript requires that the
core solutions are extended to the full language and execution environment as defined by the standard.
Belowweoutlinethemostinterestingextensionsrelatingtothehandlingofthefullstandard.