4. What can an attacker do if he
getssomescript into your page?
5. An attacker can request additional
scriptsfrom any server in theworld.
Onceit getsafoothold, it can obtain
all of thescriptsit needs.
6. An attacker can makerequestsof
your server.
Your server cannot detect that the
request did not originatewith your
application.
7. An attacker can read the
document.
Theattacker can seeeverything the
user sees.
8. An attacker hascontrol over the
display and can request information
from theuser.
Theuser cannot detect that the
request did not originatewith your
application.
9. An attacker can send information to
serversanywherein theworld.
17. Another Example
• Bad text
" + alert("XSS") + "
• Bad encoding
{"json": "" + alert("XSS") + ""}
• Good encoding
{"json": "" + alert("XSS") + ""}
18. Coding hygieneiscritical for
avoiding turducken attacks.
Usegood encoders. json.org/json2.js
Do not usesimpleconcatenation.
Never trust thebrowser.
Validateall input.
21. Script Tag Hack
• Scripts(strangely) areexempt from Same
Origin Policy.
• A dynamic script tag can makeaGET request
from aserver.
receiver(jsontext);
• Extremely dangerous. It isimpossibleto
assurethat theserver did not send an evil
script.
37. A ThreeProng Strategy to
Fix theWeb
1. SafeJavaScript subsets.
2. Small browser improvements.
3. Massivebrowser improvements.
Thiscould takeawhile, so weshould proceed on
all threeimmediately.
39. ADsafe
• A JSLint option.
• It definesasafeHTML/JavaScript subset.
• Removesfrom JavaScript all featuresthat are
unsafeor suspect.
• Allowsforeign adsand widgetsto safely
interact.
40. ADsafe
• No global variablesor functionsmay be
defined.
• No global variablesor functionscan be
accessed except theADSAFE object.
• The[] subscript operator may not beused.
• Thesewordscannot beused: apply call
callee caller constructor eval
new prototype this watch
• Wordsstarting with _ cannot beused.
41. Dangers
• Theremay still beundiscovered weaknessesin
ECMAScript and itsmany implementations.
• Browser implementationsarechanging,
introducing new weaknesses.
• TheDOM wrappersmust beflawless.
• Wearestill subject to XSSattacks.
45. HTML ProvidesNo Modules
• It wasconceived to beadocument format.
• Weareusing it asan application format.
• Applicationsrequiresmodules.
• Modulesprotect their contents.
• Modulescommunicateby exposing clean
interfaces.
46. Vats
• Adapting Google'sGearsor Adobe'sAIR to
providecommunicating containment.
• Providescooperation under mutual suspicion.
• Heavyweight.
• Distribution isdifficult.
• Still subject to XSSattacks.
47. 3. Weneed to replaceJavaScript
and theDOM.
Aslong asweareusing insecure
languages, wewill besubject to XSS
attacks.
52. Object B provides
an interfacethat
constrainsaccess
to itsown state
and references.
Every object isamicro vat.
53. Object A doesnot haveareferenceto
Object C, so Object A cannot
communicatewith Object C.
In an Object Capability
System, an object can only
communicatewith objects
that it hasreferencesto.
54. An Object Capability System is
produced by constraining theways
that referencesareobtained.
A referencecannot beobtained
simply by knowing thenameof a
global variableor apublic class.
56. 1. By Creation
If afunction createsan object, it gets
areferenceto that object.
57. 2. By Construction
An object may beendowed by itsconstructor with
references.
Thiscan includereferencesin theconstructor's
context and inherited references.
58. 3. By Introduction
A hasareferencesto B and C.
B hasno references, so it cannot communicatewith A or C.
C hasno references, so it cannot communicatewith A or B.
65. Ultimately
• Weneed to replaceJavaScript with asecure
language.
• Thecurrent ES4 proposal isnot that language.
• Weneed to replaceHTML and theDOM with
asecureapplication delivery system.
• Thecurrent HTML5 proposal isnot that either.
66. Ultimately
• Secureprogramming languageto replace
JavaScript.
• A modular application framework to replace
theDOM and CSS.
• A common text representation and protocol to
replaceHTTPand theAjax stack.
• Otherwise, theweb may fall to newer
proprietary systems.
67. Meanwhile
• Never trust thebrowser.
• Formally validateeverything you receivefrom the
browser.
• Properly encodeeverything you send to thebrowser
or database.
• Do not circumvent what littlesecurity thebrowser
offers.
• Never put dataon thewireunlessyou want it to be
delivered.
• Don't takeineffectivemeasures.