Connecting with the Database

Connecting with the Database

The client server software paradigm was instrumental in bringing about flexibility and standardization in database integration. The database management systems (DBMSs) of the 1970s and early 1980s were massive monolithic beasts. An application had to be written in a host language supported by the particular system. Each DBMS had its proprietary way of letting applications use it. The advent of SQL made it easy for developers to standardize data definition and data manipulation and most database administrators adopted SQL as their query language. However, application and database segregation was achieved only with the advent of the client-server programming paradigm. No longer does an application that makes use of data served by a DBMS need to reside on the same system as that hosting the DBMS. The application interfaces with the database by means of database connector APIs provided with the programming language used to develop the application. These database connector APIs are able to store database connection information and credentials, and they have the ability to send SQL queries to the database, retrieve the results from the query, and hand them back to the application.

The Craftiest Hack of Them All

All access to the Web application was controlled by the Netscape Enterprise server. However, looking at the various types of URLs, we easily figured out that parts of the application were being served by IIS (evident from references to .asp files) and that other parts were being served by Lotus Domino (evident from .nsf files). Issuing a HEAD/HTTP/1.0 request to 10.4.3.2 showed that the Web server was a Netscape Enterprise server. Nothing made sense, until it dawned on us that the Netscape Enterprise server was being used to proxy requests to the back-end IIS and Domino servers.

The attack on the internal IIS system was quick and deadly. A single URL, as shown in the following code snippet, achieved remote command execution on the IIS system on 10.6.6.5, using the IIS Unicode vulnerability:

http://10.4.3.2/content/../scripts/..%c0%af../winnt/system32/cmd.exe?/c+set

Figure 6-6 shows a screen shot of the browser after this URL request was issued.

Figure 6-6. Unicode attack on 10.6.6.5 through a Netscape Enterprise server

graphics/06fig06.gif

Can you figure out how this attack worked? The Netscape server was configured to translate any URLs beginning with /content/ to http://10.6.6.5/content/. Upon receiving the initial URL, the Netscape server translated it to:

http://10.6.6.5/content/../scripts/..%c0%af../winnt/system32/cmd.exe?/c+set

This URL was sent internally as an HTTP request by the Netscape server to IIS on 10.6.6.5. Once IIS had received this request, it substituted /scripts/ for the /content/ path internally because of the ".." between the two strings. The URL then transformed itself to the familiar Unicode attack URL:

http://10.6.6.5/scripts/..%c0%af../winnt/system32/cmd.exe?/c+set

As a result, the browser displayed the output of the "set" command being run on the Windows 2000 server on 10.6.6.5. The effects of this attack were deadly. A single URL resulted in the compromise of an application server on an internal network, even though it was shielded by a firewall and a front-end Web server.

The three most popular ways in which Web applications interface with back-end databases are:

         Native database APIs

         ODBC

         JDBC

Using Native Database APIs

Web application programming languages such as ASP, PHP, and Perl have APIs that provide the ability to perform database operations with popular database servers such as Oracle, DB2, SQL Server, Sybase, and MySQL. The application developers would use the appropriate API calls when connecting with a back-end database of their choice, as allowed by the programming language. Let's consider a couple of examples where database APIs are used within Web applications.

Examples

Calling the SQL Server from Active Server Pages

The following code snippet shows how queries can be performed with a Microsoft SQL Server from an ASP file:

<%"
Set db_connection = Server.CreateObject("ADODB.Connection")
db_connection.Open "Provider=SQLOLEDB;
  Data Source=192.168.7.246;
  Initial Catalog=customers;
  User Id=dbuser;
  Password=$ql+u$Er"
Set record_set = db_connection.Execute("select name,address from profiles")
db_connection.Close
%>

The code is almost self-explanatory. A database connection object, db_connection, is instantiated and subsequently used to establish a connection with an SQL Server instance on 192.168.7.246. Next, an SQL query is executed via the db_connection object, and the connection is then closed. ASP provides support for database connection objects and a native ability to interface with databases such as the SQL Server.

Calling Oracle 8i from PHP

The next code snippet shows the PHP OCI Oracle Connection Interface. Using OCI calls within PHP allows developers to write PHP code that interacts with an Oracle database server:

<?php
PutEnv("ORACLE_SID=ORCL");
PutEnv("ORACLE_HOME=/u01/app/oracle/product/8.1.5");
 
$connection = OCILogon("scott","tiger");
$query = "insert into email_info values ('$fullname', '$email')";
$cursor = OCIParse($connection, $query);
$result = OCIExecute($cursor);
OCICommit($connection);
OCILogoff($connection);
?>

This method is more or less the same as the one used in the preceding example.

Using ODBC

Managing database connections with native database APIs of programming languages is quite cumbersome. At times, an application may need to interact with different database systems from different vendors. Sometimes an application may need to be ported to another platform on which the programming language is different. In such cases, database handling via native database APIs poses a lot of problems. The Open Database Connectivity (ODBC) standard was proposed to create a universal method for interfacing with any database system. Now database drivers conforming to ODBC standards provide a common interface for programming languages to interact with databases. To establish a database connection requires an ODBC driver that matches the database system being connected to. Replacing a database system only involve using a different ODBC driver to connect to the database, without any change in the program code.

Many operating systems provide ODBC support, including Microsoft Windows, which supports ODBC natively. The burden on storing database connection information and credentials now lies on the ODBC management component. This way, user credentials and connection information need not be hard-coded into the application. Instead, a DSN that contains this information is created. The application code now refers only to the DSN.

Figure 6-7 shows a DSN, sqlserver1, being created for connection to an SQL Server database running on 192.168.7.246.

Figure 6-7. DSN configuration

graphics/06fig07.gif

Using JDBC

Java Database Connectivity (JDBC) is the Java application framework equivalent of ODBC. The JDBC and ODBC concepts are the same. The only difference between the actual frameworks is that JDBC is standardized along with the J2EE framework and is used exclusively with Java Web applications. Popular Java application servers such as BEA WebLogic, IBM WebSphere, Allaire JRun, Tomcat, and Resin use JDBC to provide database connectivity for applications.

Figure 6-8 shows a screen shot of configuring a JDBC data source for MySQL from within Allaire JRun 3.0.

Figure 6-8. JDBC configuration

graphics/06fig08.gif

 



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