Schongar P.VBScript unleashed.1997

all your needs, only to have those needs completely change a week after you put everything together, and none of the vendor's partners ever come through on their original promises to develop what you need for the system you bought. While good planning can reduce the real instances of this nightmare, the underlying problem of technological obsolescence is anything but easily solvable through traditional methods. Scalability is what's needed, but it's often hard to scale a software solution because vendors change, new technology emerges, and everyone always wants what he or she read about that's currently not even in beta form yet. And, oh yes, it all has to work together with his or her existing stuff seamlessly.

ActiveX components give you the ability to say "No problem." What you're really building around when relying on ActiveX is a scalable software component architecture, like a modular server. Every time a new need arises, you've got plug-and-play expansibility by adding new components, and you know that each ActiveX component can communicate with the others easily and efficiently. You can even write custom code to integrate disparate elements in your own unique way, if you need to. This means that one department's need to have terminal emulation in a Web browser (shudder) and another department's need to integrate a proprietary legacy database format can both be accommodated, and even that some outside development company may already have done it for you with a component you can purchase.

Standards

When Microsoft decides to make a standard, and puts as much marketing power behind it as they have with ActiveX, you can be sure that it's not going to disappear in the near future. Before you bring up the inevitable subject of Microsoft's original failed foray into UNIX (called Xenix, for those of you who have forgotten that unfortunate incident), remember that ActiveX comes at a time and in a form that lots of people, especially Windows-centric developers, want very badly. They want to be able to make their applications Internet-ready with the addition of a file or two. They want to add other people's functions to their software without pain and frustration. And they want it right now. ActiveX delivers on all of those things and promises to deliver compatibility with Java as well.

That's what it comes down to, though, isn't it? Whose standard is going to become the one to follow, and which technologies are going to become tagalongs? Java made a splash the size of a tsunami when it first came out, and the rush continues. Why? Its goal in life is cross-platform compatibility and portability. This makes it a good choice for network computers and companies with diverse system types and the desire to program in a language slightly less cumbersome than C++, while still maintaining an object-oriented approach. Microsoft, however, is intent on making sure that if they can't conquer Java, they'll embrace it with ActiveX.

The first sign of this was the ActiveX scripting extensions that Microsoft built into Internet Explorer. Not just support for VBScript, their own scripting language, but support for JavaScript as well. In the same manner, scripting languages can communicate with ActiveX objects, and ActiveX objects should be able to communicate with Java classes and functions like Java Database Connectivity (JDBC). Countless companies are either already working on Java and ActiveX integrated solutions, have preliminary versions out, or have announced that they're going to pay very close attention to the marketplace.

Even in the worst case, where ActiveX competes with Java and causes a standards rift akin to the old Mac versus Windows debate, thousands of development houses whose bread and butter is made on Windows programming will be cranking out ActiveX components all the time. That adds up to a significant number of development resources that will continue to use ActiveX no matter what happens, which is better than what can be said for a variety of other new technologies that have fallen by the wayside in recent years.

Investment Protection

How many Windows programmers are there? How many Visual Basic developers are there? If you're a large corporation, chances are pretty good that you have one, the other, or both classes of those developers in-house. If you're a small company with a smaller budget, the chances of having a VB or Windows C++ programmer in-house are even higher, percentage-wise. If you, as a company or an individual, have invested significant time and effort into learning a certain programming language, the cost to switch you over to a new environment can be pretty high. ActiveX and VBScript aim to change that.

Because VBScript is a subset of Visual Basic, it's no trouble at all for a VB programmer to switch "down" to VBScript and learn what functions are no longer available to him, as well as learn ActiveX object syntax. Rather than a reduction in the toolset, it's an extension of what the programmer can already do, with no toolkits to buy, no distribution licensing to worry about, and plenty of possibilities.

While creating ActiveX controls isn't exactly a walk in the park, experienced C++ programmers (especially those with OLE and COM object experience) are just extending their knowledge base, not retraining themselves on a new language or a new set of tools. The same environments that they have on their systems, be they from Borland, Microsoft, or anyone else, will undoubtedly gain ActiveX built-in functions to make the development process easier, so future upgrades will roll in the ActiveX cost already.

In all cases, training and software resource costs for employees are kept to a minimum. This is bottom-line good news for any company, regardless of size. No need for extensive training, combined with the ability to maintain familiar development environments, means that ramp-up time for development is also kept to a minimum, yielding more profits sooner.

Employee Efficiency

Two choices: a huge pile of unorganized papers, or a filing cabinet that you know is organized and updated on a regular basis. While the former may aptly describe my desk, most of us would choose the latter as the best place to hunt down a specific piece of information that should already be stored there.

Distributed applications and client-side processing using ActiveX mean less time wasted when network traffic is high or a server is being obstinate, less time spent trying to figure out how the data presented on a page corresponds to the original information, and more time available for interpreting that original data in the way it was intended. Most important, employees will have increased the rate at which they can locate the information they need, when and how they need it.

Company Image

You're on the phone with someone at Company X, and you ask what you're sure is a question that he or she is not going to be able to handle. Expecting "Umm, let me transfer you..." or dreading the possible use of canned hold music while they hunt down someone from another department, you're shocked when he or she says it'll be no problem to look that up for you, continues discussing other tidbits with you, and then relays the answer you were looking for, and even offers to e-mail further documentation to you right now. Inspired, you ask a couple of other questions that some other companies you called last week still haven't gotten back to you on. Issue after issue, it's the same-the person you're talking to has all the information you need and then some.

What kind of image would you have of that company if you called them? Probably the same kind you'd want your customers to have of you-prompt, efficient, knowledgeable, and very well organized. The benefits of a corporate intranet don't stop at the company doors. If employees know they can track down the information they need, at times when they're the most desperate, they'll be more confident. Customers may not know you have an intranet, but they'll know you've got your stuff together, and it'll inspire confidence in them as well. All of these bolster your company's image to both employees and customers, which is in and of itself one of the most valuable returns you can get. A 10-person company can do business like it has a thousand employees, and a large company can provide a single point-of-contact to give customers a personal touch.

Review

This idealized version of the intranet is far from being just a daydream. New developments and a constant flood of interested consumers keep the desire for companies to develop intranet solutions very high. HTML itself was a good stepping stone for information, but intranets are becoming more than just static pages. They're now hosts for distributed applications and client-side data processing, with the need to represent the latest and greatest information on a minute-by-

minute basis. ActiveX and VBScript can be combined to meet the needs of your corporate intranet easily, effectively, and cost-efficiently.

Chapter 21

Safety and Security

by Bill Schongar and Paul Lagasse

CONTENTS

●A Matter of Trust…

Can VBScript Security Hold Up?

●VBScript's Built-In Safeguards

●Flirting with Danger-ActiveX Components

Authentic Controls-Friend or Foe?

Rogue Controls

Defending Against Friendly Fire and Nasties

●Paranoia, Self-Defense, and Reasonable Risk

It's hard to protect yourself against every possible thing that could happen. To give ourselves a feeling of security, we surround ourselves with walls. Of course we have to get in and out, so we put doors in those walls. Because the doors become the weak link, we put locks on them. Now our wall is not as strong as the original wall, but it's more convenient, and we feel okay about it. But, we also feel a little claustrophobic, so we need some windows to get light inside. That puts more holes in the walls, albeit with a little glass standing between us and the outside world, but it's definitely no deterrent to someone who wants to get in. And we still feel secure? It's a sacrifice of security for convenience.

Dealing with computers, and most definitely dealing with the Internet, is a little like a house. You can be pretty certain that when you first get your computer set up it doesn't have anything nasty lurking in it. As you start opening up more connections to the outside world and bringing back things you've found, you're taking a chance. Is that chance worth it for the convenience you gain? Is there too much danger? Well, take a look.

VBScript and ActiveX are two recent entries into the exuberant chaos of the Internet, and as new visitors there's a lot that you might or might not know about their potential for causing trouble. We're now going to examine all the possible hazards you could be facing, and show you that although the potential for danger is there, a great deal of effort has been put into making VBScript and ActiveX as safe and secure as possible. You'll look at the following:

●Trust and the Internet

●VBScript's built-in safeguards

●Internet Component Download

●Authenticode

●Paranoia, self-defense, and reasonable risk

One thing to keep in mind while going through this chapter is that there's inherent danger in everything you do. There's always a chance something can be misused, that something can go wrong. But risks are normally weighed against benefits, and the same needs to hold true when dealing with VBScript and ActiveX. Much has been done to make both elements of Microsoft's Internet plans as safe as possible, but it's better for you to know all the possibilities so you can be prepared.

A Matter of Trust…

Who do you trust? Whether you're considering buying a used car, investing in some financial venture, or buying software, the decision ends up being a combination of a number of factors. What's the reputation of the person or group you're dealing with? What do you know about the product, service, or information you're getting? What's your gut instinct? There's a lot to consider.

The wide and often weird world of the Internet makes trust a more difficult commodity to come by. There's now a lot of distance between you and whomever you're dealing with. You might or might not have the benefit of knowing the reputations of the folks on the other end of the arrangement, or even if you're dealing with whom you think you are. Anonymous remailers, purloined passwords, and the inherently insecure nature of an unsecured public network are all just parts of the chances you're taking.

Don't think that you're alone, though. If you're on one end of the conversation, think about what's going on if there's another person like you on the other side. They feel they're trustworthy, but what do they know about you? How can they be sure that you're who you say you are? If you're writing any kind of software code for them, how can they be absolutely sure there's nothing nasty hidden in it? What about things such as unforeseen circumstances, like bugs in the code that weren't tested or encountered?

Can VBScript Security Hold Up?

Sounds ominous, but don't get your knickers in a twist just yet. At the time of this writing, there were no publicly known security holes, but the same was true of JavaScript and Java for a while, too. It stands to reason that somewhere, sometime, someone will discover a trick or a bug that manifests itself as a nasty possibility for security breach. They might or might not make it public, depending on if they're well-known security researchers at a university or someone with something slightly less ethical driving their hunt for such a "feature."

The software is continuously changing, as well. Not necessarily VBScript, but what's used to run it. The basic premise of VBScript is that with a few DLLs or some source code, some other application could run VBScript code. Depending on how someone else implements VBScript functionality, the security features of VBScript could end up being compromised, either due to errors, incompatibility, or just the need of the other application for more functionality. NCompass Labs was the first company to dare tread those waters by developing ScriptActive, a plug-in that allows VBScript to function in Netscape Navigator. While it's unlikely that any adverse interactions could happen in ScriptActive's use of VBScript, it's just an example that VBScript language and functions will find their way into a variety of operating systems and general environments. That leaves a lot of room for an open door.

If you've followed the plans of Microsoft and the other big industry players, you've also seen that one of the big pushes is to integrate the Internet and everyone's machines. Microsoft plans an integrated desktop, where you're browsing the Net and your hard drive at the same time. You can bet that will mean more built-in functions that could possibly be accessed by scripting languages. And that means more possibilities for dangerous situations. The hope is that new security technologies and the basic built-in safeguards of VBScript will make Net surfing safe for a long time yet to come. So far, it doesn't look too scary.

VBScript's Built-In Safeguards

Safety and security in VBScript would seem to be a dead-end topic. After all, didn't Microsoft say in all their original VBScript documentation that "all potentially unsafe operations have been removed from the language"? The following list shows some commonly used Visual Basic function categories that you won't find in VBScript.

File I/O (all of it)

DDE

Object Instantiation

Direct Database Access (DAO)

DLL execution

While certainly not an exhaustive summary, you can see that a lot was removed in the name of security. You can't create an object, you can't do real file input and output-what could possibly be potentially harmful or unsafe? Well, because you ask, take a look.

Safety in VBScript is a relative term. The good news is, you really can't purposefully do anything that will have a significant harmful effect on any user's system. That's because of the language limitations we just looked at in the previous list. If File I/O had been left in, or even some of the other inter-application communications processes, there would be a lot that you might need to worry about. However, it's still easily possible to annoy people. For example, we'll show you an obnoxious implementation of a Message Box. It would certainly be a way to discourage people with VBScript-enabled browsers from visiting your page, but other than that its actual practical use is pretty much nil. So don't try this at home, unless you really want to inconvenience yourself.

Listing 21.1. VBScript Inconvenience Script-What not to do in VBScript.

1:<script language="vbscript">

2:<!--

3:' Don't run this in your browser!

4:' The purpose of this script is just to show how even

5:' basic "safe" functions in VBScript can cause

6:' problems...

7:while (1=1)

8:{

9:value = MsgBox("Yuck.", 1 + 16 + 4096)

10:}

11:-- >

12:</script>

If you had run the script in Listing 21.1, you would get a screen that looks similar to that shown in Figure 21.1, where a message box pops up on the screen with the message and style that had been selected with the MsgBox function. The problem here is that this function is in an endless loop; every time you click OK in the message box, another message box comes up. No problem; just switch pages and kill the task. Nice try, but one of the reasons this is so inconvenient is that you can't do that.

The parameters on the end of the MsgBox function do more than just control the appearance, they include a parameter (the 4096 part of the MsgBox statement, to be specific) that makes the Message Box System-Modal. For those of you

who haven't done much in the realm of Windows programming, this means that everything else on the system stops until this message box is cleared. Under Windows 95, you're not completely stuck-you can go into your other applications and save files, open files, and go about your business as normal, but that annoying message box will still remain on top of your other tasks. Because it's in an infinite loop, it doesn't stop with just one message box, which means your system is somewhat stuck until you very explicitly tell it to stop.

This is just an annoyance example, one that doesn't do anything to your system that's permanent or really disruptive (other than tying up your computer and possibly causing you to reboot, of course), but demonstrates unsafe code. It does something that isn't harmful, but doesn't function as intended, and was probably never tested if it's part of a larger script. Remember, "safety" is a relative termbeing "safe" to run a piece of code might mean complete security to one person, and bug-free code to another.

As a general rule, though, VBScript by itself can't do any significant damage. Microsoft was very careful to remove potentially unsafe elements, and without those elements in place the VBScript code is trapped within the confines of the browser. It's certainly possible that new additions to the browser could change that, or that a bug or security hole could open up, but that possibility is about as small as it can reasonably be expected to be.

Flirting with Danger-ActiveX Components

Microsoft is pushing ActiveX components like a bulldozer moves dirt and small rocks: relentless and unstoppable. This created an immediate response from vendors of OLE-capable controls that had previously been developed for C++ and Visual Basic use. The number of ActiveX controls on the market and in development just exploded over a short period of time. You already know the reason-the capability to integrate ActiveX components with VBScript adds a lot of possibilities to the list of what can be done with an otherwise limited scripting environment. They open almost every door that was closed by limiting VBScript operations in the first place. Don't have File I/O? Make use of an ActiveX component. Can't tell the system to do things? You got itÉActiveX to the rescue.

With this proliferation of controls on Web pages, more and more sites will be adding functional controls to their internal and external sites. From a functionality standpoint, having this cornucopia of controls is great, but from a security standpoint, the same proliferation is frightening. You're talking about legions of controls that are automatically downloaded onto your system, installed, configured, and there for anyone to use in their VBScript code. All any VBScript author needs to do is look for the unique CLASSID number that corresponds to the object, and hey, presto! They now have instant access to that control within their VBScript code, or through another ActiveX control. With so many controls popping up at once, it's hard to believe that no one will find bugs or even as-designed features, which let someone get away with something that you might not want them to.

Imagine for a moment that you want to prevent someone from doing something. Isolating them will normally make some progress on that front because they can only affect their immediate surroundings. That is, unless you provide them with a method of communicating to someone or something outside their isolation. Give someone a phone and a capable outside accomplice that they can call, and all you've done is prevented the isolated person from doing the dirty work themselves. The same holds true for the seemingly incarcerated VBScript and its ActiveX cohorts. If someone can find a way to get a control of theirs on your system, or knows of a legitimate control that can be coerced into doing something that suits their purposes, you could be in trouble.

Looking at the basic array of ActiveX controls, you might scoff at first. What can someone do, toss an extra button on your browser screen? Shove unwanted streaming video at you? Spawn unwanted URLs in new windows? Hmm, doesn't sound too terribly frightening, does it? Before you doze off into peaceful dreams of the safe world VBScript lives in, you might want to try looking under the bed.

Authentic Controls-Friend or Foe?

In the race to inspire confidence in online consumers, the software industry constantly looks for the best way to assure people that what they're getting hold of is authentic and safe. People like going into a store and knowing they're not buying some cheap copy of something when they're paying the price for the original, and they like feeling that they can

trust the vendor of the software. But how do you assure people over the Internet?

You start by giving them something reasonably tangible. The Internet is an anonymous place, where people can pretend they're anyone they want, because you can't see them. If you need to convince consumers that your software is safe, you first need to convince them that you're who you say you are. The tangible proof that someone can get when an ActiveX control comes into play arrives in the form of an authentication certificate. While it's just one item to the user, there's a lot more behind this certificate than just one step.

Internet Component Download

The first step that precedes the certificate is Internet Component Download. Unlike the traditional plug-ins, but like Java applications, ActiveX components can be automatically downloaded, installed, configured, and run on an end-user's machine, all automatically. The HTML <OBJECT> tag that outlines what the ActiveX control is, as well as what parameters the object has, includes support for specifying a location through a CODEBASE parameter. If the unique class ID (CLSID)of the object isn't found on the user's system, the browser goes out to the site specified in the CODEBASE parameter and downloads the required file or files.

When the component is downloaded, a few basic checks are made on the integrity of the file to ensure that it isn't immediately doing something it shouldn't, but it can't possibly test the component exhaustively. What Microsoft and other vendors would like to accomplish is giving end users the same sense of security and assurance that they have when buying a shrink-wrapped piece of software in a store. You know who it's from, you know what it's supposed to be, and you know who to yell at if it doesn't perform as expected. To make us all feel safe, components are secured using what's called Authenticode technology.

Authenticode

Knowing that you're getting what you asked for is where Authenticode kicks in. Part of the mechanism for downloading the ActiveX component seamlessly involves a basic security check on the thing that's being obtained. One of the best ways to promote security in these transactions is to have a piece of code digitally "signed" by the manufacturer, so you know it's reasonably authentic, and not just someone claiming to be IBM or Microsoft, or some modification of their code. Besides that, it can check the integrity of the download, making sure that the transfer didn't get corrupted along the way.

The hows and whys behind the general use of Authenticode are pretty simple. You create a piece of code, and then you tag it with a digital signature that contains information about the file, including a cryptographic checksum. A what? A Cryptographic checksum is basically a summary of the file itself, such as how big it is and some interior inherent data, which is then encoded and stored. When the file integrity is checked, the same information is gathered and encrypted again. If the two encrypted portions match, it's a pretty sure bet that the code hasn't been tampered with or corrupted during download.

But what if someone else tries to sign a name that's not theirs to a piece of code? Well, that's where a signing authority steps in.

Signing Authority

To prevent digital forgery, a signing authority is used in conjunction with the Authenticode process to ensure that the person or company signing the code is legitimate. The first signing authority entrusted with this task of keeping signatures intact is VeriSign, Inc. For a fee, they'll check your company out and provide a way for you to uniquely identify your products electronically, preventing tampering. What this buys you, as an established vendor, is the capability to provide a reasonable level of assurance to customers and visitors that you are who you say you are, the code is what you say it is, and someone else will vouch for you.

So, if you, as a software author, develop a component or a series of components, you'd prove to a Signing Authority that you are who you say you are. They might ask for a Dun and Bradstreet number, some tax information, or other

documents, just to be certain. When they're convinced, they give you a unique digital stamp that you can use to encrypt your software. When you stamp your software this way, someone on the other end will see a certificate that contains the public information contained in that stamp-who your company is, what the software is, and who vouches for you. While all possibilities of forgery can't be avoided, the combination is pretty effective, and enough to inspire a reasonable level of confidence in erstwhile consumers. After all, that's the goal-you're downloading only "friendly" components that have been checked and that someone takes responsibility for.

They Do What They Were Meant To

Don't be fooled into thinking that ActiveX controls are harmless, even the ones that do what you think they do and come from people you can trust. Someone you trust could give you a knife set as a present, but if someone breaks into your house they could still use it against you. The danger isn't necessarily in the original source of the object in question, but any subsequent use of that object could potentially be by someone you don't trust.

As an example, imagine an ActiveX-based FTP control. Great for automated download pages, especially in intranets. You could branch your VBScript application to different files based on questionnaires, or any number of other choices, and process it in the background so users could continue to do other things on the page. While the control itself is extremely useful, imagine the possibilities for abuse. Someone could download any file they want to your system, possibly even bypassing prompts to check and see what you want to do with the file. Far worse, FTP is a two-way streetthey could bundle and upload a variety of system files from your machine, or other random files that could be of use to them. If they were really devious, they could just replace a typical system file with a copy of their own, to capture passwords and other data.

Rogue Controls

Pretend, for a moment, that you're a computer whiz with a desire to experiment, and have temporarily misplaced any ethical qualms about doing weird things to other people's systems. Oh go on, we won't tell anybody about your dark side. From this new (hopefully) vantage point, ActiveX could be a big temptation to play with. You've got millions of people downloading software that they've never even heard of, often times without even realizing it. Sure, it's harder than making a virus or following a how-to guide for packet-based denial-of-service attacks, but, oh, the possibilities. And you were looking for a real challenge for your free time, anywayÉso you decide to hack some ActiveX controls.

Threats from the Outside

There are a lot of highly skilled individuals out there who aren't pretending. They know code inside and out, backwards and forwards, and they could easily see mucking about with ActiveX and its associated security as a great thing to add to their resume. There are also distinct groups of them. Some are in it just for the challenge, not for the damage-to them it's not a question of malice or ethics, but something new and cool to figure out and understand. They might make a few controls that do things they shouldn't, but they'll probably give them to friends, or show them off. Another group might follow that path slightly further, being interested in just what they can do, and where that knowledge gets them. They'd probably build something to collect tidbits about you from your hard drive, send it back to them, and bounce you an anonymous e-mail saying they've done it.

Other groups end up with far more malicious intents-they might want to trash your hard drive, get financial data, or break into your corporate network to get things that will ruin your whole day. Some of it might be subtle, planted for later, and other things could be blatant, but for them the challenge isn't just to know how to do it, it's to do it, use it, and get away with it.

The popularity of ActiveX makes it too tempting a target to be ignored. No matter who does it first, or how they do it, someone will create controls that are designed to breach the security of your system. These "rogue" controls could take any form, but the most obvious ones have already been mentioned-system corruption, private information gathering, and stepping stones for further security breaches.

Can you defend against these kinds of people? Sure, don't download anything, ever. This is paranoid, fatalistic, but

unfortunately, true. Insidious hostile controls, like those that serve a real purpose but have hostile code embedded deep within, will be the worst. While it inspires a sense of paranoia to think you have to question everyone, it's just part of the cost you pay for the convenience of the Internet.

Threats from Within

The worst possible case of rogue controls would be that of intentional tampering of a company's controls by a member of that company. This would be someone who could change the code, or switch it for something else entirely, and authenticate the new code. Because the trust in authenticode technology is geared more towards trusting a company, rather than an individual, dissent within the ranks hits the consumers through what they thought was a safe back door. As mentioned in the "Authentic Controls" section of this chapter, users might have already established that future; authenticated source code from a particular company or agency should not inform them of future component downloads. So, if someone tampers with what is already registered as a "friendly" product.

Another possibility would be the cracking of the authenticode scheme on either the signing end or the user end. Imagine what someone could do if they got hold of Microsoft's signing key-suddenly you're prompted to download the latest version of an Internet Explorer control, and the certificate looks perfectly valid, if you see it at all. This breach of the underlying security would cause a real break of faith in the trust that Authenticode and other digital signing technologies want to inspire in end users.

Defending Against Friendly Fire and Nasties

Preventing your system from these kinds of attacks is pretty tough to do all by yourself. Sure, you can disable the use of ActiveX controls, but that's the "stick your head in the sand" approach to safety, and won't move you into the next generation of functionality very quickly. Your real best defense is to put only those controls on your system that you need, and keep up with the latest versions of browsers and controls. This gives you the best chance to have the properly functioning versions of controls and the latest security measures available in your browser.

Be sure to take advantage of the security measures wherever possible. Don't disable them because they're annoying or inconvenient-they're built in for a reason. A common trap is to disable the certificate checking for other software packages from the same company or signing authority. Give yourself a fighting chance-let yourself know what people are shoving on your system.

Remember, though, that at the heart of the legitimate controls are people with safety and functionality as their primary goals. They're not out to mess your system up or give people a way to cause you problems. They want to give you functions that you want and need. It's in their best interest to give you a sense of confidence in what they produce and not let you be scared off by possible threats. This means you've got a lot of people behind the scenes working for your security and safety, both by improving the reliability of their own controls and security and by fending off attacks on the ActiveX security mechanisms by outside sources. It's like having your own personal Internet Police Force-and it's a good thing to have.

Paranoia, Self-Defense, and Reasonable Risk

Combining functionality and safety is a tough job. In Biotechnology and other fields, you often encounter the term Best Available Technology (BAT) when dealing with potential risks and their solutions. It means that a better solution may come along in the future, but if you're dealing with the issue right now, a better solution doesn't come to mind. VBScript and ActiveX take advantage of the Best Available Technology for protecting themselves and for protecting you. Like any security measures, there is always a way around them, but just like putting doors and windows in your house, you sacrifice complete security for convenience, aesthetics, and functionality.

Don't box yourself in without an opening into the functionality that VBScript and ActiveX provide. As a developer, you can't afford not to think about security, but you can't hope to have a 100% secure solution. If problems and security breaches occur, your duty to the end users is to protect them from potential problems that are within your control, and try to keep your use of controls reasonable, so as not to crowd their systems and possibly breach their defenses. As an end