Wiring the Components

Wiring the Components

There are many ways of interfacing Web application system components with one another. Figure 6-2 shows four different ways of interfacing Web application server components with front-end Web servers and database servers.

Figure 6-2. Interfacing Web application servers

graphics/06fig02.gif

Four schemes of interfacing Web application servers are shown in this diagram. Let's take a look at each.

The Native Application Processing Environment

The first and simplest method is to write the application in the front-end Web server's native application processing environment. Web servers such as Microsoft IIS have a built-in application processing environment, such as Active Server Pages, that allows developers to write applications in the Visual Basic language and make them Web-enabled.

Web Server APIs and Plug-Ins

The second method is to develop an application by using API libraries provided by the Web server. Such applications become an extension of the front-end Web server and can be mapped with URLs through the front-end Web server's configuration scheme. Apache, IIS, and Netscape all have API through libraries that can be linked in the application. Many commercial Web application server components ship as Apache Dynamic Shared Objects (DSOs), Microsoft ISAPI extensions, or Netscape NSAPI modules. These components provide a more flexible application development and execution environment than the native environment of the front-end Web server. For example, ServletExec, which is a Java application server published by NewAtlanta, Inc., ships as an Apache DSO or a Microsoft ISAPI extension. ServletExec is used to provide a J2EE application execution framework with Java Servlets, Enterprise JavaBeans, and JSP. When operating as a plug-in with Apache or IIS, ServletExec extends the abilities of Apache and IIS to allow developers to host Java applications with both these Web servers. The application server runs on the same system as hosting the Web server and is controlled by the Web server's configuration.

URL Mapping and Internal Proxying

The third method of interfacing Web application servers with front-end Web servers is URL mapping and internal proxying. This method doesn't require the Web application server to make use of any front-end server APIs or plug-in frameworks. Instead, the Web application server operates as an independent HTTP server, listening on a TCP port other than that used by the front-end Web server. The front-end Web server is configured to map specific URLs onto the Web application server running on the other TCP port, which allows a more generic method of interfacing. The trade-off lies in performance, because the front-end Web server and the Web application server run in different process contexts, and all data exchange is via HTTP, as opposed to procedures being invoked through APIs.

Proxying with a Back-End Application Server

In this fourth method, the Web application server runs on a separate system, which is usually an IP address on an internal network accessible from the front-end Web server. The application server can be accessed only by the front-end server, not directly from the outside network. The front-end Web server acts as a proxy server to the back-end application server based on URL mappings. This method is an extension of the URL rewriting and internal proxying method. It allows an array of application servers working with one or more front-end Web servers hosting different parts of an application. Redundancy in front-end Web servers and back-end application servers allows for greater scalability, reliability, and throughput.

The following examples illustrate the differences between the various interfacing schemes.

Examples

Interfacing PHP3 with Apache

These days, PHP has almost become synonymous with Apache. Most Apache Web servers are enabled to support Web applications written in PHP. It offers a rich development framework for Web applications and is an independent application environment. PHP3 was interfaced with Apache, using Apache Dynamic Shared Objects (DSOs) and was compiled and linked as an Apache module, libphp3.so. Directives have to be added to the Apache configuration file to let files with the extension .php3 be processed by the PHP3 module. The following configuration directives are added to Apache's httpd.conf:

LoadModule  libphp3.so
AddModule  mod_php3.c
<IfModule mod_php3.c>
  AddType application/x-httpd-php3 .php3
</IfModule>
Interfacing ServletExec as an Apache DSO

ServletExec also is available as an Apache DSO for plugging into the Apache Web server. ServletExec has to be started as an independent server, listening on a TCP port other than those ports used by Apache. The mod_servletexec.so module is placed in the libexec directory under the Apache directory and is configured as an extension of Apache from within httpd.conf as follows:

LoadModule  servletexec_module  libexec/mod_servletexec.so

Next, a mapping is established to allow servlets and files ending with .jsp to be executed by ServletExec, as follows:

<Location /servlet>
  SetHandler  servlet-exec
</Location>
AddHandler servlet-exec .jsp

This results in URLs of the form: http://www.someserver.com/servlet/<servlet_name> and http://www.someserver.com/filename.jsp to be automatically handled by ServletExec.

Interfacing ServletExec as an ISAPI Extension to Microsoft IIS

The ServletExec Java application server, when installed on Microsoft Windows NT/2000, can be set up to run either as an independent Web server or as an ISAPI extension to IIS. ServletExec installs a DLL in \ Inetpub\scripts called ServletExec_Adapter.dll, which is the application server available as an ISAPI extension. The ServletExec application server runs as a Windows NT/2000 service.

The ServletExec_Adapter.dll is registered as an ISAPI filter under Microsoft IIS service properties, as shown in Figure 6-3.

Figure 6-3. Installing ServletExec as an ISAPI

graphics/06fig03.gif

This way, ServletExec will ensure that, if a URL request directed toward IIS has a reference to either a Java servlet or a JSP file, ServletExec will intercept and execute it within its own environment. The configuration and interfacing method is similar to that, which is used when interfacing ServletExec with Apache.

Interfacing IIS and Domino Servers with Netscape Enterprise Server

During one of our attack and penetration engagements, we came across an application originally written and hosted on Lotus Domino and later integrated with another application hosted on IIS using ASP. The IIS and Domino servers were running on separate systems. Because IIS and Domino can't be easily integrated, we decided that these two applications should be integrated by a front-end Web site served by a Netscape Enterprise server. In this case, the Netscape Enterprise server was configured to proxy certain URL requests to the back-end IIS and Domino servers, which lay on an internal Web server network. Figure 6-4 shows the layout of this Web application system.

Figure 6-4. Web application system served by IIS and Domino

graphics/06fig04.gif

The Netscape server runs on 10.4.3.2 and is a dual-homed system that connects to an internal 10.6.6.0 network. The secondary IP address of the Netscape server is 10.6.6.6. The IIS server is hosted on 10.6.6.5 and the Domino server on 10.6.6.4. The front-end Netscape server was configured as shown in Figure 6-5.

Figure 6-5. Configuration of the Netscape server

graphics/06fig05.gif

The default URL path, http://10.4.3.2/, maps to http://10.6.6.6/. The URLs http://10.4.3.2/content, http://10.4.3.2/graph, and http://10.4.3.2/publish map to http://10.6.6.5/content, http://10.6.6.5/graph, and http://10.6.6.5/publish, respectively, and are handled by IIS. The other two URLs, http://10.4.3.2/data and http://10.4.3.2/diagnostics, map to http://10.6.6.4/data and http://10.6.6.4/diagnostics, respectively, and are handled by the Lotus Domino server. Thus the entire Web application is available through a single front-end Web server with subcomponents being handled by other application servers in the back end. The request http://10.4.3.2/content/news_stories.asp?st=1&disp=10 will be translated to http://10.6.6.5/content/news_stories.asp?st=1&disp=10 and sent as an HTTP proxy request to 10.6.6.5. The request http://10.4.3.2/data/results.nsf will be translated to http://10.6.6.4/data/results.nsf and sent as an HTTP proxy request to 10.6.6.4.

 



Web Hacking(c) Attacks and Defense
Web Hacking: Attacks and Defense
ISBN: 0201761769
EAN: 2147483647
Year: 2005
Pages: 156

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net