Security of Web Browser Scripting Languages: Vulnerabilities, Attacks, and Remedies

The following paper was originally published in the Proceedings of the 7th USENIX Security Symposium San Antonio, Texas, January 26-29, 1998 Security of Web Browser Scripting Languages: Vulnerabilities, Attacks, and Remedies Vinod Anupam and Alain Mayer Bell Laboratories, Lucent Technologies For more information about USENIX Association contact: 1. Phone: 510 528-8649 2. FAX: 510 548-5738 3. Email: [email protected] 4. WWW URL:http://www.usenix.org/ Security of Web Browser Scripting Languages: Vulnerabilities, Attacks, and Remedies Vino d Anupam Alain Mayer Bel l Laboratories, Lucent Technologies 600 Mountain Avenue Murray Hil l, NJ 07974 fanupam,alaing@bel l-labs.com we discovered do es not lead to full system p enetra- Abstract tion where an attacker can access a user's resources While conducting a security analysis of JavaScript les, pro cesses at will. It might thus be argued and VBScript, the most popular scripting languages that such aws are less serious. However, security on the Web, we found some serious aws. Moti- and privacy concerns see, e.g., cover story of Time vated by this outcome, we propose steps towards a Magazine, dated 8/15/97 have b een the single most sound de nition and design of a security framework imp ortant barrier to electronic commerce achieving for scripting languages on the Web. We show that if its multi-billion dollar p otential. In this light, at- such a security framework had been integrated into tacks on a user's security and privacy, are a matter the respective scripting languages from the very be- of serious concern. ginning, the probability of preventing the multiple Motivated by the ab ove considerations, we pro ceed security aws, that we and other research groups to show necessary steps towards a general security identi ed, would have been greatly increased. framework for scripting languages on the Web. We put forward the notion of a safe interpreter. A safe interpreter must assure: 1 Intro duction Data Security. Data provided by the user p os- JavaScript and VBScript are p opular scripting lan- sibly encrypted b efore it is transmitted can guages used for Web-page design. A user accessing only b e accessed by the intended recipient; the a JavaScript/VBScript enhanced Web-page causes p ossibility that credit-card data, transaction scripts to be downloaded onto the user's machine details, etc. may b e obtained by someone else and to b e executed by the interpreter of the user's is highly damaging. browser. Scripts typically cannot directly access the user's le-system or the network. This is prob- User Privacy. Information ab out the user ably the reason that, in contrast to the Java pro- should not be given out unless explicitly al- gramming language, no formal security mo del and lowed by the user; this protects against un- hence no explicit rules were ever do cumented on wanted tracking, identi cation dossiers, junk e- what is and what is not allowed by scripts. A mail, surreptitious le uploads, etc. string of serious security aws discovered by sev- As a concrete example, we give excerpts from Se- eral research groups, including successful attacks on cure JS, our prop osal for a more secure version of patches issued to x original aws, shows that this JavaScript. In this pap er, our treatmentcovers se- is a dangerous omission. In particular, we found curity issues of scripting languages up to Naviga- aws which allow private data supplied by a user tor 4.* and IE 4.*. However, we do not address e.g., credit card numb ers, passwords, e-mail ad- co de signing, a topic that transcends scripting lan- dress, etc in a Web transaction to b e captured by guages. Also, to day's browser environment allows an attacker. Suchanintrusion works even when a emb edded scripts to communicate with entities like user employs encryption e.g., SSL, since the data applets and plug-ins, outside the scripting languages is captured either b efore it is encrypted or after it prop er, adding a lot to the scop e of what scripts can is decrypted. In contrast to some of the security do via these entities. This "comp osition" of di erent aws found in Java see [MF97], the vulnerability entities with di erent security p olicies and frame- from Netscap e Corp. JScript, Microsoft Corp.'s works is not well understo o d; other safe scripting implementation, is a clone that is interpreted in environments, such as Safe-Tcl see [B94,OLW96], Microsoft's Web browsers. In the rest of this pa- do not allow such comp osition. We can only touch p er, we use JavaScript to refer to b oth strains. up on this issue; a thorough treatmentisbeyond the JavaScript is ob ject-based in the sense that it uses scop e of this pap er. built-in and user de ned extensible ob jects, but The notion of a secure op erating system, which pro- there are no classes or inheritance. The co de is integrated with, and emb edded in, HTML. By de- vides safe containers for di erentWeb technologies Java, plug-ins, JavaScript would help in achiev- fault, JavaScript provides an ob ject-instance hier- ing the ab ove goals. However, we emphasize that archy that mo dels the browser window and some most of the uncovered vulnerabilities of scripting browser state information. E.g., the navigator ob- languages originate within the language itself. For ject provides information ab out the browser to a instance, a rogue site may contain attack scripts script, and the history ob ject represents the brows- which can access and send back data obtained ing history in the browser window. Also, through a from other do cuments without any p enetration of pro cess called 're ection', JavaScript automatically creates an ob ject-instance hierarchyof elements of the underlying op erating system or concurrent application. the script's HTML do cument when it is loaded by Finally,we show that if our framework had b een de- the browser. The location ob ject represents the URL of the current do cument, while the document signed and integrated when either JavaScript or VB- Script were conceived, the probability of preventing ob ject encapsulates HTML elements forms, links, the string of security aws, that were identi ed byus anchors, images etc. of the current do cument. This de nes a unique name space for each HTML page and other research groups, would have b een greatly increased. This motivates the need for future de- and thus for each collection of scripts emb edded in that page. Variable data typ es are not declared, signs of scripting languages to explicitly consider security asp ects during initial design. However, secu- i.e., loose typing. Ob ject references are checked at rity is never absolute. Implementation errors, even runtime, i.e., dynamic binding. in a sound security design, are not unlikely and can VBScript see, e.g., [L97] is an application script- be exploited by an attacker. Such aws, however, ing language that lo oks a lot like Visual Basic. It are harder to identify by an attacker. is lo osely typ ed and ob ject based. It can be used for scripting Microsoft's browser, Internet Explorer, Organization of the Pap er: In Section 2 we re- with whichit communicates using ActiveX Script- view the basic concepts of browser scripting, and ing. ActiveX Scripting allows host applications, brie y intro duce JavaScript and VBScript, the two like browsers, to compile and execute scripts, and most p opular scripting languages for Web browsers. manage the name-space exp osed to the script. The Section 3 presents the essence of our attacks on ActiveX Scripting Ob ject Mo del SOM creates an JavaScript and VBScript capable browsers. We ob ject instance hierarchy containing, among other then prop ose, in Section 4, a security framework things, window, navigator and history ob jects as de- for scripting languages on the Web. We illustrate scrib ed ab ove. Also, the location ob ject represents this framework with concrete notions and examples the current URL, and the document ob ject re ects taken from our prop osal of SecureJS. In Section 5, the current HTML do cument. VBScript scripts are we discuss our attack in more detail and p oint out emb edded in HTML do cuments, and are interpreted how our framework would have help ed in prevent- automatically when the do cument is loaded. ing it. Section 6 concludes. In the App endix, we discuss attacks designed by other groups and again showhow our framework would have help ed in preventing them. 3 Our Attack While conducting a security analysis of JavaScript 2 Browser Scripting Languages: An we discovered a serious vulnerabilityinJavaScript- Overview capable browsers. We subsequently analyzed VB- Script, and discovered that the vulnerability could b e exploited equally e ectively using VBScript. The vulnerability in Microsoft browsers was thus also in JavaScript see [F97, KK97] is a simple pro cedu- the ActiveX Scripting Ob ject Mo del - JScript and ral language that is interpreted by Web browsers VBScript interpreters are front ends that communi- do cument itself can b e sub jected to analysis, yield- cate with the underlying ActiveX SOM ob jects. ing information ab out di erent elds, options and their corresp onding values. Particularly serious is the fact that this exploit bypasses security provided 3.1 Overview by secure so ckets or HTTP authentication, since manyWeb servers and other business platforms are On the Web, scripts emb edded in multiple browser administered over the Web nowadays.

Load more