Chapter 20: Using JavaScript to Create Dynamic HTML (DHTML) Effects

The Problem with JavaScript Security

A Web page is always downloaded to the client's computer prior to being displayed in the browser. This means that even if a Web browser does not allow a visitor to view the source of a site, all a visitor would have to do is look in his temporary Internet folder for the source, and all your hard work is for naught.

It is possible to tell the browser to not download the Web page to a file before displaying it. This would alleviate the problem of having the password stored in every client's temporary Internet folder. I will not provide an example of doing this because it is a very convoluted process, and it still doesn't close up every security hole. For instance, if your client was dedicated enough, he might download or create a memory searcher that can find the password stored somewhere in the memory of the browser. Although this is relatively unlikely, it can be done, as Figure 18.4 proves.

Figure 18.5 shows a program that I wrote in a matter of hours that found the password in memory in less than a second. That brings me to the fundamental problem of JavaScript security—the password is always sent to the client's computer. No matter how you try, you will never manage to protect that password completely once it's on the client's computer. If you try to encrypt the password, the encryption algorithm is sent to the client, and he can reverseengineer it. If you store the given password in the cookie file and use a second page to verify it, the client will still receive the source for the second file.

Figure 18.5: The potential misnomer of describing JavaScript as secure.

But rest assured, there is a perfectly simple way to create a secure Web site using only JavaScript.