Contents:
JavaScript and Security
Security Holes and Security Hobbles
The domain Property
The Data-Tainting Security Model
Because of the wide-open nature of the Internet, security is an important issue. This is particularly true with the introduction of languages like Java and JavaScript, because they allow executable content to be embedded in otherwise static web pages. Since loading a web page can cause arbitrary code to be executed on your computer, stringent security precautions are required to prevent malicious code from doing any damage to your data or your privacy. This chapter discusses Internet security issues related to JavaScript. Note that this chapter does not cover any of the many other issues involved in web security, such as the authentication and cryptography technologies used to keep the contents of web documents and HTML forms private while they traverse the Web.
JavaScript's first line of defense against malicious code is that the language simply doesn't support certain capabilities. For example, client-side JavaScript does not provide any way to read, write, create, delete, or list files or directories on the client computer. Since there is no File object, and no file access functions, a JavaScript program obviously cannot delete a user's data, or plant viruses on the user's system, for example.
Similarly, client-side JavaScript has no networking primitives of any type. A JavaScript program can load URLs and send HTML form data to web servers and CGI scripts, but it cannot establish a direct connection to any other hosts on the network. This means, for example, that a JavaScript program cannot use a client's machine as a attack platform from which to attempt to crack passwords on other machines. (This would be a particularly dangerous possibility if the JavaScript program has been loaded from the Internet, through a firewall, and then could attempt to break into the intranet protected by the firewall.)
While the JavaScript language itself provides this basic level of security against the most egregious attacks, there are other security issues that remain. Primarily these are privacy issues--JavaScript programs must not be allowed to export information about the user of a browser when that information is supposed to be private.
When you browse the Web, one of the pieces of information you are consenting to release about yourself is the web browser that you use: it is a standard part of the HTTP protocol that a string identifying your browser, version, and vendor is sent with every request for a web page. This information is public, as is the IP address of your Internet connection, for example. But other information should not be public. This includes your email address, for example, which should not be released unless you choose to do so by sending an email message or authorizing an automated email message to be sent under your name.
Similarly, your browsing history (what sites you've already visited) and the contents of your bookmarks list should remain private. Because your browsing history and bookmarks say a lot about your interests, this is information that direct marketers and others would pay good money for, so that they can more effectively target sales pitches to you. Because this information is so valuable, you can be sure that if a web browser or JavaScript allowed this private information to be stolen, someone would be stealing it every time you visited their site. Once stolen, it would be on the market only nanoseconds later. Most users of the Web would be uncomfortable with the idea that any site they visit could find out that they are cat fanciers who are interested in women's footwear and the Sierra Club.
Even assuming that we have no embarrassing fetishes to hide, there are plenty of good reasons to be concerned about data privacy. One such reason is a pragmatic concern about receiving electronic junk mail and the like. Another is a very legitimate concern about keeping secrets. We don't want a JavaScript program to be able to start examining data behind our corporate firewall or to upload our passwords file to its web server, for example. At a more general level, we might desire that our private data be protected simply because we believe that individuals should have control over the ways that their personal data is collected and used.
Navigator and other browsers already have the ability to establish secure communication channels on the Web so that the information transferred back and forth between web server and web client remains private. By turning static HTML into dynamic programs, JavaScript opens the door to unethical web pages that steal private information and send it (through secure or insecure channels) back to the web server. It is this possibility that JavaScript must defend against. The remainder of this chapter explains how JavaScript does this, and also documents cases where it has failed to do it.
file: /Techref/language/java/SCRIPT/definitive/ch20_01.htm, 8KB, , updated: 2019/10/14 16:00, local time: 2024/8/23 19:18,
3.21.43.43:LOG IN
|
©2024 These pages are served without commercial sponsorship. (No popup ads, etc...).Bandwidth abuse increases hosting cost forcing sponsorship or shutdown. This server aggressively defends against automated copying for any reason including offline viewing, duplication, etc... Please respect this requirement and DO NOT RIP THIS SITE. Questions? <A HREF="http://piclist.com/tecHREF/language/java/SCRIPT/definitive/ch20_01.htm"> [Chapter 20] JavaScript Security</A> |
Did you find what you needed? |
![]() o List host: MIT, Site host massmind.org, Top posters @none found - Page Editors: James Newton, David Cary, and YOU! * Roman Black of Black Robotics donates from sales of Linistep stepper controller kits. * Ashley Roll of Digital Nemesis donates from sales of RCL-1 RS232 to TTL converters. * Monthly Subscribers: Gregg Rew. on-going support is MOST appreciated! * Contributors: Richard Seriani, Sr. |
Welcome to piclist.com! |
.