Keywords: main

Subsections

- 4.1 W3-mSQL
  - 4.1.1 Funktionalität
    - 4.1.1.1 Script Tags
    - 4.1.1.2 Form Data
    - 4.1.1.3 Sicherheitsrelevante Funktionen
    - Private Scripts
    - Lite Libraries
  - 4.1.2 W3-Auth - Benutzerauthentifizierung für W3-mSQL
    - Anforderungen an den Web-Server
    - Prinzip von W3-Auth
  - 4.1.3 Installation
    - 4.1.3.1 W3-mSQL
    - 4.1.3.2 W3-Auth
  - 4.1.4 Konfiguration
    - Konfiguration der Zugriffskontrolle mit W3-Auth
  - 4.1.5 Test
    - 4.1.5.1 W3-mSQL
    - Allgemeine Handhabung
    - Tabelleninhalte ansehen, anlegen, ändern oder löschen
    - Tabellen anlegen
    - Tabellen löschen
    - Tabellen editieren
    - Datenbank anlegen und löschen
    - 4.1.5.2 W3-Auth
  - 4.1.6 Bewertung
  - 4.1.7 W3-mSQL mit Apache 1.2
    - 4.1.7.1 W3-mSQL
    - 4.1.7.2 W3-Auth
- 4.2 PHP/FI
  - 4.2.1 Funktionalität
  - 4.2.2 CGI oder Apache Modul ?
  - 4.2.3 Installation
  - 4.2.4 Verwendung von PHP/FI mit der Datenbank mSQL
  - 4.2.5 Verwendung von PHP/FI mit der Datenbank PostgreSQL
    - 4.2.5.1 Test
    - Allgemeine Handhabung
    - Tabelleninhalte ansehen, anlegen, ändern oder löschen
    - Tabellen anlegen, löschen oder editieren
    - Datenbank anlegen und löschen
    - 4.2.5.2 Bewertung

# 4 Datenbank-Web-Interfaces

Nachdem die Standard-Installationen der verwendeten Web-Server und Datenbanken erklärt wurden, blicken wir jetzt auf die Anbindung der Datenbank an das Internet. Dabei kamen die folgenden Datenbank-Web-Interfaces zum Einsatz:

- W3-mSQL
- PHP/FI

# 4.1 W3-mSQL

W3-mSQL wird in der Version 2.0 im Source-Code von Mini SQL 2.0 mitgeliefert. Es ist ein sogenanntes WWW-Interface das als Schnittstelle zwischen HTML-Dateien und der Datenbank mSQL dient. Hierbei bedient es sich einer einfachen Programiersprache - genannt Lite - die in HTML-Dateien eingebettet wird und die gesamte Funktionalität von mSQL nutzen kann. Auf diese Weise wird der zweistufige Ansatz - eine Kombination von HTML-Dokumenten und Shellskripten zur Datenbankanbindung umgangen. Man erspart sich nicht nur eine separate CGI-Programmierung, die fundierte Kenntnisse in der Shell-, C- bzw. Perl-Programierung voraussetzt, sondern hat auch HTML-Code und Datenbankansteuerung in einer einzigen Datei parat. Dies erleichtert die Übersicht über die Dateien einer Web-Site ungemein und verringert somit den Verwaltungsaufwand.

Zweiter, wichtiger Bestandteil des W3-mSQL Paketes ist W3-Auth , eine Zugriffssteuerung und -verwaltung für W3-mSQL. Dazu jedoch mehr in Kapitel 4.1.2 (S. ).

## 4.1.1 Funktionalität

### 4.1.1.1 Script Tags

Um die Funktionen von W3-mSQL zu nutzen, wird Lite-Code (die Skript-Sprache von W3-mSQL) in den HTML-Code eingebunden. Dabei unterscheidet sich dieser von normalen HTML-Code dadurch, daß er innerhalb von <! ... > Tag's steht. Diese Tags werden vom Browser als Kommentare interpretiert und nicht angezeigt. Es spielt weder eine Rolle, wieviele solcher Tag's in einer Datei stehen, noch wieviele Zeilen Code (die einzelnen Anweisungen sind dabei durch ``;'' zu trennen) ein Tag beinhaltet. Hierzu ein kleines Beispiel:
In einer HTML-Datei (z.B. test.html) steht folgende Zeile:
`<! echo(``Hello World!n'');>`
Wird diese Datei ganz normal in den Browser geladen (http://host.domain/test.html), so zeigt zwar der Browser diese Zeile nicht an, weil er sie als Kommentar interpretiert, im HTML-Source-Code ist sie jedoch enthalten.

Lädt man die Datei test.html jedoch über das W3-mSQL Interface in den Browser (http://host.domain/cgi-bin/w3-msql/test.html), so wird `Hello World` angezeigt. w3-msql wurde vom Web-Server geladen, hat die Datei test.html geparst, den echo-Befehl ausgeführt und das Ergebnis an den Browser weitergeleitet. Vom original HTML-Source-Code, mit Lite Befehlen, sieht der Browser nichts mehr.

Schon jetzt wird die erste sicherheitsrelevante Lücke sichtbar. Jeder Benutzer kann die Datei sowohl als auch laden. Somit ist es ihm möglich - sofern er Interesse am Source-Code hat - diesen durch umgehen des w3-msql Interfaces zu laden.

Für bestimmte Anwendungen ist diese Lücke nicht hinnehmbar. Daher bieten einige Web-Server an, Dateien mit bestimmten Endungen (wie z.B. .msql) nur durch die dafür vorgesehenen CGI-Programme zu laden. Heißt die Datei nun test.msql und ist der Web-Server entsprechend konfiguriert, so kann der Source-Code nicht mehr durch einen Browser geladen werden. Alle Dateien mit Datenbankzugriffen sollten dann die Endung .msql tragen.

Für die Konfiguration dieser Funktion beim Apache Web-Servers siehe Kapitel 4.1.7 (S. ).

### 4.1.1.2 Form Data

Wenn man eine Datenbank an das Internet anbindet, so will man nicht nur vorgefertigte SQL-Abfragen mit festen Parameterwerten an die Datenbank stellen, sondern Interaktivität. Man möchte also möglichst den gesamten Funktionsumfang einer Datenbank im Netz zur Verfügung stellen; oder zumindest die Parameterwerte der SQL-Abfragen selbst bestimmen können.

Zu diesem Zweck eignen sich besonders gut die Formulare in HTML. Die darin eingegebenen Daten lassen sich mit der POST-Methode auf einfache Weise an den http-Server schicken.

Werden die somit übermittelten Daten an ein CGI-Script übergeben, so kann jenes diese verwerten. Im Falle des W3-mSQL Interfaces werden die Feldnamen des HTML-Formulars als Namen für die globalen Variablen des CGI-Scriptes übernommen. Die Werte eines jeden Form-Elements werden automatisch den neu erzeugten globalen Variablen zugewiesen.
Nachstehendes Beispiel soll dies verdeutlichen:

> `<FORM ACTION=/cgi-bin/w3-msql/test.html METHOD=POST>
> <INPUT NAME=username SIZE=20>
> <INPUT NAME=password SIZE=20 TYPE=PASSWORD>
> <FORM>`

In diesem Beispiel wurden zwei Eingabefelder (username, password) im HTML-Formular definiert. Beim Übermitteln der eingebenen Daten durch die festgelegte ACTION an die Datei test.html werden die Felder durch das W3-mSQL Interface geschleust und zwei globale Variablen erzeugt. Die Variablen lauten dann $username und $password und können durch den in test.html integrierten Lite-Code verarbeitet werden.

### 4.1.1.3 Sicherheitsrelevante Funktionen

W3-mSQL unterstützt einige Funktionen, die zur Sicherheit der Datenbankanbindung beitragen. Doch bevor diese hier erläutert werden, sind ein paar grundlegende Sicherheitslücken anzusprechen.

Niemand sieht es gerne, wenn der Source-Code seiner Applikation entführt wird. Dies ist in diesem Fall jedoch möglich, wenn die HTML-Dateien (mit integriertem Lite-Code) ohne das W3-mSQL Interface in den Browser geladen werden. W3-mSQL bietet dafür zwei integrierte Alternativen an; Private Scripts (S. ) und vorkompilierte Bibliotheken ( Lite Libraries, S. ). Eine dritte Möglichkeit kann auch der verwendete Web-Server bieten (beschrieben unter Kapitel 4.1.1.1, S. ).

Doch wie sieht es bei (z.B. für firmeninterne Zwecke) gesperrten Web-Verzeichnissen aus? Sind solche Verzeichnisse durch denn Web-Server gesperrt, können auf normalen Weg keine darin befindlichen HTML-Dateien in den Browser geladen werden. Der Web-Server meldet, daß dies verboten ist. Über einen kleinen Umweg durch das W3-mSQL Interface jedoch sind auch diese geschützten Dateien ladbar. Hierzu muß der Anwender nur das w3-msql CGI-Programm mit dem geschützten Pfad als Parameter aufrufen und schon wird ihm die gewünschte Datei geliefert.
Ein ``Access-Control'' durch den http-Server ist also beim Einsatz von W3-mSQL nicht mehr möglich. Es ließe sich zwar der Zugriff auf das w3-msql CGI-Programm durch den Web-Server z.B. auf IP-Adressbereiche begrenzen, aber auch innenhalb dieser Bereiche ist es oft nicht wünschenswert, daß jeder jedes Web-Verzeichnis lesen kann. Außerdem ist ein ``Access-Control'' durch den Web-Server mit hohem administrativem Aufwand verbunden und benötigt zudem einen Account auf dem Server.
Das W3-mSQL Interface Paket löst jenes Problem mit einem eingebautem Autorisierungsmechanismus, genannt W3-Auth (Kapitel 4.1.2, S. ).

### Private Scripts

Ein schon erwähntes Problem ist, daß der eingebettete Source-Code in HTML-Dokumente nicht für jedermann öffentlich zugänglich sein soll. Dies ist solange kein Problem, solange das w3-msql CGI-Programm die Datei parst, bevor sie zum Browser geschickt wird.

Um nun zu unterbinden, daß das Dokument ohne das w3-msql CGI-Programm geladen wird, wurden sogenannte Private Scripts eingeführt.

Private Scripts sind HTML-Dateien, die sich nicht innerhalb des durch den Web-Server erreichbaren Verzeichnissbaumes befinden. Sie stehen außerhalb in einem separaten Verzeichnis das durch den Parameter Inst_Dir in der Datei msql.conf (Kapitel 3.1.2.1, S. ) festgelegt ist.
siehe dazu auch Anhang A.1 (S. )
Wie behandelt nun W3-mSQL diese Skripts?
Wird eine Datei namens test.html angefordert, so schaut w3-msql erst an der angegebenen URL nach; findet es dort keine Datei mit dem Namen test.html, so sucht w3-msql im Verzeichnis für Private Scripts nach der angeforderten Datei.
Somit wird das Private Script-Verzeichnis zu einem erweiterten Web-Verzeichnis, welches nicht ohne die Hilfe des W3-mSQL Interfaces gelesen werden kann. Der Source-Code der Dokumente ist dadurch geschützt.

### Lite Libraries

Eine weitere Möglichkeit, seinen Source-Code vor fremden Blicken zu schützen ist, vorkompilierte Bibliotheken zu benutzen. Hierbei stehen dem Anwender alle Lite-Funktionen auch als Bibliotheksfunktionen zur Verfügung.

Diese Möglichkeit schützt nicht nur den Source des Dokumentes, sondern steigert auch die Performance von W3-mSQL, da die Datei nicht mehr zur Laufzeit übersetzt werden muß.

Tiefergreifende Informationen mögen bitte im Benutzerhandbuch[6] von Mini SQL 2.0, Kapitel Lite Libraries nachgelesen werden.

## 4.1.2 W3-Auth - Benutzerauthentifizierung für W3-mSQL

Ein großes Problem bei der Anbindung von Datenbanken an das Internet stellt die Zugriffskontrolle der Applikationen dar. Eine Datenbankanwendung hat nicht nur die Eigenschaft, Daten auszulesen und anzuzeigen, sondern diese auch zu verändern. Deshalb ist es notwendig, den Zugriff auf die Applikationen zur Datenmanipulation zu kontrollieren.

Die meisten Web-Server unterstützen eine Benutzername/Passwort Funktion, um den Zugriff auf einzelene Verzeichnisse des Dokumentenbaumes zu kontrollieren. Dies hat aber einen (vor allem bei einer sehr großen Anzahl verschiedener Anwendungen) hohen Administrationsaufwand zur Folge, zumal die Administration durch Editieren von Dateien vom UNIX-Prompt aus geschehen muß.

Um diesem Problem zu begegnen, beinhaltet das W3-mSQL Interface Paket eine Authentifizierungsfunktion. Diese nutzt das HTTP Authentifizierungs-Protokoll, um den Benutzernamen und das Passwort zu bestimmen. Wenn diese Funktion aktiviert ist, dann prüft das w3-msql CGI-Programm automatisch den Benutzernamen und das Passwort eines jeden, der eine Seite, die durch das W3-mSQL Interface generiert wird, anfordert.

Außerdem benutzt W3-Auth keine Dateien auf dem http-Server und benötigt zur Administration auch keinen UNIX Promt. Alle Einstellungen können durch das Web-Interface w3-auth , welches alle Daten in einer mSQL Datenbank speichert, vorgenommen werden.

### Anforderungen an den Web-Server

Um den Benutzernamen und das Passwort eines Cients zu bestimmen, muß der Web-Server die vom Client erhaltenen Daten an das w3-auth CGI-Programm weitergeben. Gewöhnlich geschieht dies über eine UNIX Environment Variable.

Leider unterstützten dies die meisten http-Server nicht, da die Entwickler es als eine Sicherheitslücke ansahen. Auch der hier verwendete Apache-Server gehört zu dieser Gruppe. Eine Möglichkeit um ihn trotzdem zu verwenden wird in Kapitel 4.1.7 (S. ) beschrieben.

### Prinzip von W3-Auth

Das Prinzip von W3-Auth umfaßt drei Bereiche; Namensräume (Namespaces), Bereiche (Areas) und Gruppen (Groups). Mit Hilfe dieser verwaltet W3-Auth seine Zugriffskontrolle.
Im weiteren werden nun die drei Bereiche genauer erläutert.

- Namespace
  Ein Namespace ist eine logische Gruppe von Benutzernamen, Areas und Groups.
  Ein Beispiel: Ein Provider richtet für jeden seiner Kunden einen eigenen Namespace ein, mit dem Kunden als Administrator. Der Kunde kann dann innerhalb dieses Namespaces die Benutzer, Areas und Groups selbst verwalten. Dadurch wird es möglich, gleiche Benutzernamen durch Zuordnung zu ihrem Namespaces zu unterscheiden. Ebenso verhält es sich mit Areas und Groups.
- Area
  Als Area wird ein zu schützendes Segment des Web-Verzeichnisses bezeichnet und durch dessen URL definiert. Beim Anfordern einer URL bestimmt immer die längste erkannte URL die Area (z.B. area1 ist definiert durch /firma1, area2 durch /firma1/admin; durch Anfordern der URL /firma1/admin wird also area2 erkannt).
  Der Zugriff auf eine Area kann auf Groups und IP-Pattern beschränkt werden.
- Group
  Group faßt verschiedene Benutzer eines Namespaces zu einer Einheit zusammen. Durch Zuordnung zu einer (oder mehreren) bestimmten Area wird den Mitgliedern der Group der Zugriff gestattet.

## 4.1.3 Installation

Auch wenn die Installation des WWW-Interfaces hier zweigeteilt beschrieben ist, so ist es in der Praxis aus Sicherheitsgründen nicht ratsam, das w3-msql CGI-Programm ohne das w3-auth CGI-Programm zu installieren. Gründe dazu ergeben sich aus dem vorangegangenen Kapitel.

Die für das WWW-Interface benötigten Dateien wurden bereits bei der Installation von Mini SQL 2.0 mit ins Verzeichnis /soft/msql-2.0.1 kopiert.

### 4.1.3.1 W3-mSQL

Damit das CGI-Programm w3-msql für den Einsatz zur Verfügung steht, muß die Datei w3-msql in das cgi-bin Verzeichnis des http-Server kopiert (verschoben oder gelinkt) werden. Hierfür kann die Befehlszeile nach dem Wechsel in das Verzeichnis /soft/msql-2.0.1 wie folgt aussehen:
`mv bin/w3-msql ../apache-1.2/html/cgi-bin/`

Wird das w3-msql CGI-Programm mit dem Apache Web-Server benutzt, so sind noch die Abweichungen von der Standard Konfiguration des Server aus Kapitel 4.1.7 (S. ) durchzuführen.

### 4.1.3.2 W3-Auth

Für die Installation von w3-auth wird genauso verfahren. Zuerst muß die Datei w3-auth in das cgi-bin Verzeichnis des Servers kopiert (verschoben oder gelinkt) werden. Dies kann wie folgt geschehen:
`mv bin/w3-auth ../apache-1.2/html/cgi-bin/`
Bei der weiterführenden Installation - dem Einrichten der benötigten Datenbank - hilft ein kleines Script. Leider kann es nicht ohne ein paar kleine Änderungen verwendet werden. Nach dem Wechsel in das Verzeichnis /soft/msql-2.0.1 kann in der Datei ./misc/setup_w3auth die Zeile
`#!/usr/local/Hughes/bin/lite`
in
`#!/soft/bin/lite`
geändert werden und die Zeile
`if (system("/usr/local/Hughes/bin/msqladmin create w3-msql") != 0)`
in
`if (system("/soft/bin/msqladmin create w3-msql") != 0)`

Nach diesen Änderungen kann der mSQL-Server gestartet werden und das Skript ./misc/setup_w3auth ausgeführt werden. Dadurch werden die für die Zugangs-Identifizierung benötigten Datenbanken angelegt und ein Super-User für die Verwaltung der Zugriffsrechte festgelegt.

Weiter müssen die von w3-auth benötigten Graphik-Dateien aus ./www/graphics im neu erzeugten Verzeichnis ./Hughes/graphics im "root" des Web-Directories vorhanden sein. Das kann durch nachstehende Kommandozeile geschehen:
`mv www/graphics/ ../apache-1.2/html/Hughes/`

Für die Verwendung von W3-Auth mit Apache sind die unter Kapitel 4.1.7 (S. ) aufgelisteten Änderungen am Source-Code des Web-Servers durchzuführen.

## 4.1.4 Konfiguration

Eine Konfiguration im altbekannten Stil muß für das W3-mSQL Interface Paket nicht durchgeführt werden. In gewissen Fällen kommt man jedoch nicht umhin, ein paar kleine Einstellungen vorzunehmen.

Dazu sind im Abschnitt [w3-msql] der Datei ./msql.conf im Installations Verzeichnis von Mini SQL die in der Tabelle 4.1 (S. ) beschriebenen Laufzeitvariablen zu ändern.

Tabelle 4.1: Laufzeitvariablen in der Datei ./msql.conf (Abschnitt [w3-msql])
Parameter | default Wert | Beschreibung
Auth_Host | NULL | Bezeichnet den Host, auf dem die mSQL Datenbank
|  | mit den W3-Auth Identifizierungsdaten zu finden
|  | ist. Ist der Parameter auf NULL gesetzt, so ist die
|  | Datenbank auf dem Local Host zu finden.
Hughes_Footer | True | Kontrolliert das Anhängen der standard Fußzeile
|  | von Hughes Technologies an Web-Seiten.
Private_Only | False | Wird der Parameter Wert auf True gesetzt, zwingt
|  | man das W3-mSQL Interface dazu, nur
|  | Private Scripts auszuführen (siehe auch
|  | Anhang 4.1.1.3, S. )
|  | Dies kann dazu benutzt werden, um absolute
|  | Sicherheit zu schaffen; also dem Remote User
|  | zu verbieten, normale HTML-Seiten durch das
|  | w3-msql CGI-Programm zu laden.
Private_Dir |  | NICHT im Standard Source-Code von Mini SQL 2.0
|  | enthalten. (siehe dazu unbedingt Kapitel A.1, S. ]
|  | Legt das Private Script Verzeichnis fest

Soll das w3-msql CGI-Programm Private Scripts (Kapitel 4.1.1.3 (S. )) verwenden, empfiehlt es sich auch Anhang A.1 (S. ) zu lesen.

### Konfiguration der Zugriffskontrolle mit W3-Auth

Am leichtesten läßt sich die Konfiguration von W3-Auth durch ein kleines Beispiel erklären. In diesem Beispiel heißt der originale Super User 'teddy'. Er legt jetzt einen neuen Namespace (genannt 'Firma_1') an und den Administrator (genannt 'admin1') für diesen Namespace. Dazu geht er wie folgt vor:

- Schritt eins:
  Es muß ein neuer Super User , mit eingeschränkten Rechten im Namespace 'SuperUser' und vollen Rechten in dem Namespace, für den er zuständig sein soll, angelegt werden. Dies geschieht durch Auswählen des 'SuperUser' Namespaces im Hauptmenü. Daraufhin erscheint das Super User Management Menü (Abbildung 4.1, S. ). Durch auswählen der Option User Management erscheint eine Liste der zur Zeit festgelegten Benutzer (momentan nur 'teddy'). Über die Option Add und den Button Execute kann der neue Benutzer hinzugefügt werden. Nach Ausfüllen des Formulars und Abschicken mit Execute ist der Benutzer angelegt.
- Schritt zwei:
  Damit nun der neue Benutzer Super User wird und W3-Auth benutzen kann, muß er dem Namespace 'SuperUser' zugeordnet werden. Durch anklicken der Namespace Management Option im Super User Management Menü (Abbildung 4.1, S. ) erscheint eine Liste der aktuellen Namespaces (zur Zeit nur 'SuperUser'). Über die Option Edit und Auswahl des Namespaces 'SuperUser' kann nun 'admin1' dem Namespace als Administrator hinzugefügt werden.

  Abbildung 4.1: W3-Auth: Super User Management Menu

- Schritt drei:
  Weiter müssen noch die Rechte von 'admin1' am Namespace 'SuperUser' festgelegt werden. Dies erfolgt durch Auswahl von Privilege Management in Abbildung 4.1 (S. ). Dadurch wird eine Liste der aktuellen Benutzer angezeigt. Nach Anklicken von 'admin1' und Edit muß in der folgenden Liste der Namespace 'SuperUser' gewählt werden. Anschießend können die Rechte vergeben werden (Abbildung 4.2, S. ). Für den Namespace 'SuperUser' erhält 'admin1' keine Rechte.

  Abbildung 4.2: W3-Auth: Privilege Management Menu

  ACHTUNG !!!
  Auch der originale Super User 'teddy' kann sich somit alle Rechte am Namespace 'SuperUser' nehmen. Existiert kein zweiter Super User mit vollen Rechten, so ist W3-Auth nicht mehr konfigurierbar. Die einzige Möglichkeit, daß 'teddy' wieder alle Rechte am Namespace 'SuperUser' erhält, besteht darin, daß der UNIX Systemadministrator händisch in der Datenbank 'w3-msql' nachstehenden Update-Befehl ausführt.
  `UPDATE perms SET level=255
  WHERE uname='teddy'AND namespace='SuperUser'`
- Schritt vier:
  Über Namespace Management und der Option Add kann jetzt der neue Namespace ( 'Firma_1') angelegt werden. Als Administrator wird dem Namespace 'admin1' zugeordnet.
- Schritt fünf:
  Es müssen nur noch die Rechte des Benutzers 'admin1' am Namespace 'Firma_1' definiert werden. Das geschieht ähnlich wie in Schritt drei, nur das als Namespace 'Firma_1' selektiert wird. 'admin1' werden für 'Firma_1' alle Rechte zugeteilt.
- Schritt sechs:
  Als nächstes meldet sich 'admin1' durch Auswahl des Namespaces 'Frima_1' beim Authentification Management an (Abbildung 4.3, S. ). Ähnlich wie in Schritt eins beschrieben, legt er jetzt durch Auswahl der Option User Management die Benutzer seines Namespaces an. Zum Beispiel 'user11' und 'user12'.

  Abbildung 4.3: W3-Auth: Authentification Management Menu

- Schritt sieben:
  Dann legt er unter Group Management zwei Gruppen (z.B. 'admin' und 'users') an und setzt sich selbst als Administrator für diese ein. Der Vorgang ist derselbe wie beim Anlegen eines Namespaces.
- Schritt acht:
  Über Group Member Management verteilt er die Benutzer auf die einzelnen Gruppen (z.B. 'user11' zu 'admin' und 'user11', 'user12' zu 'users'). Dabei kann ein Benutzer auch mehreren Gruppen zugehören. Durch Selektieren einer Gruppe und der Option Add werden alle verfügbaren Benutzer angezeigt. Nach Auswahl eines (oder mehrerer) Benutzer und bestätigen mit Execute sind die Benutzer der Gruppe zugeordnet.
- Schritt neun:
  Im letzten Schritt werden noch die mit W3-Auth zu schützenden Bereiche (Web-Verzeichnisse) konfiguriert. Über Area Management (Abbildung 4.3, S. ) erscheint wiederum eine Liste mit den verfügbaren Bereichen. Die Option Add öffnet das Menü Add Area (Abbildung 4.4, S. ) und fordert zur Eingabe eines Names für den Bereich auf (z.B. 'Users').

  Abbildung 4.4: W3-Auth: Area Management Menu

  Als nächstes wird die URL des Bereiches (z.B. /firma1/intern) eingegeben. Dazu genügt es, die Pfadangabe der URL einzugeben und nicht die gesamte URL ( http://host.domain kann weggelassen werden).
  Im Anschluß daran stehen fünf Elemente für die Zugriffskontrolle des Bereiches zur Verfügung. Jedes ist auf Inactive geschaltet. Um es zu aktivieren wird nur der Index Wert von Inactive in einen numerischen Wert (1bis 5) geändert. Die Aktivierung der Elemente erfolgt von oben nach unten, wobei keines ausgelassen werden darf.
  Soll der Zugriff für diesen Bereich nur der Gruppe 'users' erlaubt werden, so ist das erste Element zu aktivieren und unter Access Group die Gruppe 'users' auzuwählen.
  Über das Acces Control Feld kann der Zugriff auf IP Adressen oder Domains beschränkt werden. '*' erlaubt den Zugriff der Gruppe 'users' von allen IP Adressen aus. Soll der Zugriff auf Hosts einer bestimmten Domain beschränkt werden, so ist '*.domain' anzugeben. Durch Angabe einer bestimmten Domain im Access Control Feld und der Access Group '** Public **' wird allen Clients der angegebenen Domain der Zugriff auf diesen Bereich (ohne Passwortkontrolle) gewährt.
- Letzter Schritt:
  Zu guter Letzt muß noch in jedem der geschützten Bereiche (Verzeichnisse) eine Datei namens .w3-auth existieren. Da der Inhalt und die Größe dieser Datei egal ist, kann sie ganz einfach mit
  `touch .w3-auth`
  erzeugt werden.
  Das CGI-Programm w3-msql sucht beim Laden einer Datei nach .w3-auth. Wird .w3-auth gefunden, so überprüft w3-msql die Zugriffsrechte auf das Verzeichnis in der Datenbank, und verlangt gegebenenfalls eine Authentifizierung. Fehlt jedoch .w3-auth, behandelt w3-msql diese Verzeichnis als ungeschützt.
  ACHTUNG !!
  Es muß sichergestellt sein, daß alle Dateien des geschützten Verzeichnisses zwingend über w3-msql geladen werden (siehe dazu auch Kap. 4.1.7, S. ). Dateien, die nicht zwingend über w3-msql geladen werden, unterliegen nicht dem Schutz der W3-Auth Authentifizierung. Sie müssen gegebenenfalls andersweitig geschützt werden.

## 4.1.5 Test

Der Test dieses WWW-Interface Paketes ist in zwei Teilen beschrieben, um die beiden Module W3-mSQL und W3-Auth besser voneinander abzugrenzen. Bei der Durchführung wurden jedoch immer beide Module gemeinsam eingesetzt

### 4.1.5.1 W3-mSQL

Um sich einen Test des gesamten Funktionsumfangs von W3-mSQL zu ersparen, wurden folgende Testkriterien festgelegt.

- Allgemeine Handhabung beim Einbetten von SQL-Befehlen in HTML-Dateien
- Tabellen-Handling (Anlegen, Löschen, Tabelleneinträge hinzufügen, etc ...)
- Datenbank-Handling (Anlegen, Löschen)

Hierbei wurde untersucht, ob und wie sich die Funktionen realisieren lassen. Dabei wurde kein besonderer Wert auf eine schöne optische Ausgabe der generierten Web-Seiten gelegt. Auch auf einen sinnvollen Applikationscharakter der Seiten wurde verzichtet.
Ferner sei noch vermerkt, daß nachstehend nur die eigentliche Syntax zum Ausführen der Funktion kurz erklärt wird. Eine detailierte Beschreibung aller, auch nebenbei erwähnten Funtionen (z.B. Verbindung zum Datenbank-Server herstellen), ist im Benutzerhandbuch[6] von mSQL zu finden

Eine Struktur über das Dateisystem zum Testen von W3-mSQL zeigt Abbildung 4.5 (S. ).

Abbildung 4.5: Struktur der Testdateien für W3-mSQL

Kurze Beschreibung:
Als Wurzel des Testbaumes dient index.html, welches für die Tests keine weitere Bedeutung hat. Hierüber gelangt man in die beiden Äste deren Hauptmenü admin.html bzw. index.msql heißen. admin.html stellt die Funktionen Datenbank anlegen, löschen und editieren (eingeben ganzer SQL-Statements) zur Verfügung. Über index.msql lassen sich die Daten der bereits bestehende Tabelle 'bestand' in der Datenbank 'simpletest' verändern, löschen und einsehen (Aufbau der Tabelle 'bestand' siehe Tabelle 4.2, S. ).

Tabelle 4.2: Struktur der Tabelle 'bestand'.
Field | Type | Length | Not Null | index
art_nr | char | 10 | yes | -
art_bez | char | 30 | no | -
stueck | int | 4 | yes | -
nummer | index | - | - | yes

exec.msql führt die vom Benutzer in der Interaktionsschnittstelle menu.msql definierten Operationen aus.
bestand_neu.msql legt einen neuen Datensatz in der Tabelle 'bestand' an. Mit bestand.msql lassen sich vorhandene Datensätze verändern oder löschen.

### Allgemeine Handhabung

Mit dem W3-mSQL Interface ist es sehr leicht, Datenbankabfragen in HTML einzubetten. Wie auch schon in Kapitel 4.1.1.1 (S. ) beschrieben geschieht dies über sogenannte Scripting-Tags. Diese beginnen mit '<!' und enden mit '>'. Alle darin eingebetteten Kommandos der Skriptsprache Lite werden vor dem Ausliefern der Datei an den Client von w3-msql geparst und interpretiert. Der Client erhält nur noch reinen HTML Code.

Im Allgemeinen ähnelt die Skriptsprache sehr der Programmiersprache C, so das der Einstieg für jeden Menschen mit C Kenntnissen sehr leicht ist.

### Tabelleninhalte ansehen, anlegen, ändern oder löschen

In einem kleinen Beispiel soll der Inhalt der Tabelle 'bestand' zur Ansicht gebracht werden. Dabei kann der Benutzer über ein Formular entscheiden, ob er die ganze Tabelle oder nur eine bestimmte Auswahl von Artikelnummern sehen will (z.B. alle Nummern beginnend mit 356). Dazu gibt er ' 356% ' ein, wobei '%' als Wildcard für beliebig folgende Zeichen steht. Diese Eingabe wird mittels der POST Methode an die eigentliche Datei mit der Datenbankabfrage übermittelt. Dort wird für den übergebenen Parameter (z.B. select) eine Variable namens $select angelegt.

Nach dem Verbinden mit dem Datenbank-Server und dem Öffnen der Datenbank, holt nachstehender Lite Code die gewünschten Daten aus der Tabelle und bereitet sie im HTML Format auf.
`<!
msqlQuery($sock, ``SELECT * FROM bestand WHERE art_nr LIKE '$select''');
$res = msqlStoreResult();
$row = msqlFetchRow($res);
while (# $row != 0)
{ echo(``$row[0] ... $row[1] ... $row[2]'');
$row = msqlFetchRow($res);}
msqlFreeResult($res);
>`
Beschreibung:
msqlQuery stellt das in Hochkomma stehende SQL-Statement an die zuvor geöffnete Datenbankverbindung $sock.
msqlStoreResult speichert das Ergebnis der Abfrage in der Variablen $res.
msqlFetchRow nimmt die erste Zeile des Ergebnisses im Array $row auf und schaltet den internen Zeilenzähler um eins weiter.
Solange die Größe des Arrays ungleich 0 ( while-Schleife), werden die einzelnen Felder ausgegeben. Hierbei steht $row[0] für die erste Spalte der Tabelle 'bestand' (also art_nr), $row[1] für die zweite ... usw. Nach der Ausgabe mit echo(`` ... ``) wird die nächste Zeile geholt, bis keine mehr vorhanden ist.
msqlFreeResult gibt das Ergebnis in $res wieder frei.

Beim Browser des Clients kommt nur noch die von echo(`` ... ``) erzeugte Ausgabe an. Zur besseren optischen Aufbereitung (z.B durch Tabellen) kann selbstverständlich jeder beliebige Standard HTML Code innerhalb von echo(`` ... ``) mit ausgegeben werden.
Für das Anlegen, Ändern und Löschen von Tabelleninhalten kommen auch wieder Standard SQL Befehle zum Einsatz. Nachstehend drei kleine Beispiele dafür:
Anlegen:
`<!
msqlQuery($sock, ``INSERT INTO bestand (art_nr, art_bez, stueck) VALUES ('000456001', 'Artikel 123', 100)'');
>`
Ändern:
`<!
msqlQuery($sock, ``UPDATE bestand SET art_bez='Artikel 200'
WHERE art_nr='000456001''');
>`
Löschen:
`<!
msqlQuery($sock, ``DELETE FROM bestand WHERE art_nr='000456001''');
>`

### Tabellen anlegen

Auch das Anlegen von Tabellen ist nicht weiter schwierig. Dazu muß lediglich - wiederum nach dem Verbinden mit den Datenbank-Server und dem Öffnen der Datenbank - folgender w3-mSQL Befehl angewendet werden:
`<!
msqlQuery($sock, ``create table Tabelle_1 (Spalte_1 char(10) Not Null, Spalte_1 int)'');
>`
Beschreibung:
Es wird eine Tabelle namens 'Tabelle_1' erzeugt. Die Spalten heißen 'Spalte_1' und 'Spalte_2' und sind einmal eine 10 elementige Zeichenkette sowie ein Integer Feld.

### Tabellen löschen

Ähnlich wie das Anlegen einer Tabelle gestaltet sich auch das Löschen dieser.
`<!
msqlQuery($sock, ``drop table Tabelle_1'');
>`

### Tabellen editieren

Leider lassen sich mit dem W3-mSQL Angebot von SQL-Statements keine Tabellen verändern. Ein SQL Befehl wie ``ALTER TABLE'' fehlt leider. Somit kann eine Tabelle nur über einen Umweg verändert werden; also neue Tabelle erzeugen Inhalt der alten Tabelle in die Neue kopieren alte Tabelle löschen.

### Datenbank anlegen und löschen

Der erste Blick auf die Syntax von W3-mSQL läßt vermuten, daß über das Interface keine Datenbank anlegt werden kann. Auch ein Befehl zum Löschen einer Datenbank schien zu fehlen. Erst auf den zweiten Blick konnte man erkennen, daß mit Hilfe eines kleinen Tricks auch diese Funktionen realisierbar sind.
Zum Anlegen einer Datenbank betrachte folgende Zeile:
`<!
system(``/soft/bin/msqladmin drop $dbname-q'');
>`
Was geschieht ?
Mit dem W3-mSQL Befehl system() können beliebige Kommandos am System Prompt abgesetzt werden. Sie werden dann in einer Subshell ausgeführt. Jedwelche Ausgabe des übergebenen Kommandos erscheint dann in der erzeugten HTML Datei. Der Exit Status des Kommandos wird zudem an den Aufrufer zurückgegeben.
Es kann also auch das Programm msqladmin für die Administration von Mini SQL gestartet werden. Leider werden jedoch alle durch system() gestarteten Programme unter dem Usernamen des Web-Servers (z.B. NOBODY) ausgeführt. Deshalb muß in der Datei msql.conf (Kapitel 3.1.2.1, S. ) der Parameter Admin_User von 'root' auf 'nobody' geändert werden, wodurch die Kontrolle der Administrationsgewalt aus der Hand gegeben wird.
Dies hat jedoch eine schwere Sicherheitslücke zur Folge:
Jeder Benutzer, der auf dem Web-Server ein eigenes HTML Verzeichnis besitzt und darauf einen Ftp-Zugang hat, kann eine Datei uploaden, mit der er jede beliebige Datenbank löschen kann. Die Namen aller Datenbanken kann er sich vorher jederzeit mit dem W3-mSQL Befehl msqlListDBs() anzeigen lassen.

Der Schaden, der damit angerichtet werden kann, ist nur zu vermeiden, wenn man die Ausführrechte des Programmes msqladmin in der Datei msql.conf weiterhin nur einer einzigen Person (z.B. root) gestattet.

### 4.1.5.2 W3-Auth

Für den Test der Zugriffsauthentifizierung wurde die in Abbildung 4.6 (S. ) dargestellte Testumgebung simuliert. Ein Service-Provider stellt den beiden Firmen Web-Space zur Verfügung und richtet für jede Firma einen Namespace ein.

Abbildung 4.6: Simulierte Testumgebung

Abbildung 4.7: Namespace-Konfiguration der Testumgebung

Abbildung 4.8: URL-Baum der Testumgebung

Dabei untergliedert sich der URL-Baum für die Web-Sites beider Firmen wie ihn Abbildung 4.8 (S. ) zeigt. Ihren Namespace konfigurieren sich die Firmen wie in der Abbildung 4.7 (S. ) veranschaulicht.

Die Konfiguration der simulierten Testumgebung mit w3-auth (Kapitel 4.1.4, S. ) verlief für die erste Firma problemlos. Das Einrichten von Benutzern, Areas und Groups war äußerst einfach. Bei der zweiten Firma aber mußte ein gravierender Fehler in w3-auth enttarnt werden.

Laut Funktionsbeschreibung können innerhalb eines Namespaces nur die dazu gehörenden Areas verwaltet werden. Überraschenderweise konnte aber der Administrator des Namespaces der zweiten Firma auf die Areas des Namespaces der ersten Firma zugreifen. Und nicht nur das, auch eine Änderung der Areas war möglich. Diese Änderungen führten jedoch dazu, daß danach die ganze Zugriffssteuerung nicht mehr richtig funktionierte und sich als unbrauchbar erwies.

Erst eine Analyse des Source-Codes von w3-auth schaffte Abhilfe. Siehe dazu auch Anhang A.2 (S. ). Danach konnte die Konfiguration ohne weitere Probleme fertiggestellt werden.

Für den anschließenden Test der Zugriffsberechtigung mußte dann aber noch in jeden Zweig des URL-Baumes eine Datei mit der Endung .msql kopiert werden. Dazu wurden beliebige, bereits existierende HTML Dateien verwendet. Lediglich ihre Endung wurde geändert.

Im Ergebnis dieses Tests ließen sich alle Zweige des URL-Baumes nur mit den dafür vorgesehenen Benutzernamen und Paßwörtern betreten. Die Einschränkung verschiedener Zweige auf bestimmte IP-Adressen funktionierte tadellos.

Alles in Allem wurden die Erwartungen nach Beseitigung des oben erwähnte Problemes zur Zufriedenheit bestätigt.

## 4.1.6 Bewertung

Wie sich gezeigt hat, hat das Web-Interface W3-mSQL sowohl seine guten als auch schlechten Seiten, die größtenteils auch von der Datenbank herstammen. Dabei ist wohl der größte Nachteil, daß die Datenbank mSQL keine Benutzerauthentifizierung beim Zugriff auf den Datenbankserver durchführt. Dies hat dann zur Folge, daß über gutgemeinte Funktionen (z.B. msqlListDBs()) jeder Benutzer der Datenbank sich die Namen anderer Datenbanken des Server verschaffen kann, und danach auch in für ihn nicht bestimmte Tabellen Einsicht nehmen kann bzw. diese manipulieren kann.

Ein Abschalten dieser Funktionen beim Kompilieren (C Kenntnisse sind dafür notwendig !) schränkt dann zwar den Funktionsumfang des Interfaces etwas ein, würde aber die Sicherheit erhöhen.

Für die Festlegung, was nun gut oder schlecht ist, kommt es jedoch auch sehr auf die Art der Nutzung des Interface an.

Innerhalb eines abgeschlossenen Intranet, in dem zwei bis drei Administratoren mit der Pflege beauftragt sind, ist Mini SQL und das W3-mSQL Interface eine gute wie auch kostengünstige Lösung. Da hier nur ein kleiner Kreis von Personen Administrtionsrechte hat, und ein Angriff von außen nicht zu erwarten ist, sind die vorhandenen Sicherheitslücken vernachlässigbar. Es müssen jedoch vor der Installation am Source Code der Version 2.0.1 noch ein paar kleine, bereits erwähnte Bugs beseitigt werden.

Für einen Service Provider hingegen, der Web-Space mit Datenbankanbindung vermietet, ist W3-mSQL weniger oder überhaupt nicht zu empfehlen.
Er kann seinen Kunden eine einfache, leicht zu bedienende Datenbankanbindung zur Verfügung stellen und auch eine durch den Kunden selbst administrierbare Zugriffsteuerung auf den gemieteten Web-Space. Leider öffnet er aber auch dem Kunden Tür und Tor für Vandalismus auf dem Server, wenn er seinen Administrationsgewalt und den damit verbundenen Aufwand auf jenen überträgt. Denn schwarze Schafe befinden sich überall.
Wer also seinen Kunden eine Datenbankanbindung mit Eigenverwaltung zur Verfügung stellen will, dem sei von Mini SQL und dem W3-mSQL Interface abzuraten.
Übernimmt der Provider selbst die Administration der Datenbanken (inclusive der Tabellen) und stellt diese dem Kunden entsprechend seiner Wünsche zur Verfügung, so ist das Interface als kostengünstige Alternative durchaus empfehlenswert.

Jedoch sollten seine Kunden nicht unbedingt sensible Daten in der Datenbank ablegen, da sie von allen anderen Kunden, die auf dem gleichen Server Web-Space besitzen ebenfalls gelesen werden können.

Abschließend lassen sich noch einmal alle wesentlichen Leistungen des Softwarepaketes zusammenfassen:

- Gut: kostengünstige Alternative zu großen Datenbanksystemen wie Oracle.
- Gut: die einfache C ähnliche Skriptsprache, mit der sich schnell und leicht Datanbankanbindungen innerhalb von HTML realisieren lassen.
- Gut: das W3-Auth Modul zur Zugriffssteuerung (sowohl die Funktion, als auch die Administration), mal abgesehen von dem kleinen Bug !
- Mangelhaft: versteht nur eingeschränkte SQL Befehle. Nützliche Befehle wie ``ALTER TABLE'' und ähnliche stehen nicht zur Verfügung.
- Schlecht: keine Benutzerverwaltung für die Datenbank vorhanden - Zugriff entweder alle oder (k)einen. Dadurch nicht (oder nur bedingt) geeignet für den Einsatz im WorldWideWeb.

Obwohl das W3-mSQL Interface - laut Benutzerhandbuch[6] - Web-Server unabhängig ist, empfiehlt es sich trotzdem den Apache Web-Server einzusetzen. Auch wenn dieser für den Gebrauch des W3-Auth Modules erst einmal gepatched werden muß.

## 4.1.7 W3-mSQL mit Apache 1.2

Für den Einstz des W3-mSQL Interface Paketes mit dem Web-Server Apache 1.2 genügt dessen Standard-Installation nicht ganz. Die hier beschriebenen Änderungen bei der Konfiguration sind noch durchzuführen.

### 4.1.7.1 W3-mSQL

Soll das W3-mSQL Interface mit (oder ohne) dem w3-auth CGI-Programm verwendet werden, so ist in der Datei ./conf/srm.conf im Apache-Installationsverzeichnis folgende Zeile einzufügen:
`ScriptAlias /cgi-bin/ /soft/apache-1.2/html/cgi-bin/`
Sie bezeichnet das Directory, welches die Server- bzw. CGI-Skripten enthält. Ohne diesen Eintrag kann Apache keine CGI-Scripten ausführen.

Als nächstes sollte die in Kapitel 4.1.1.1 (S. ) beschriebene Sicherheitslücke geschlossen werden. Hierzu sind in der Datei ./conf/srm.conf die Zeilen
`AddHandler w3-msql .msql
Action w3-msql /cgi-bin/w3-msql`
hinzuzufügen. Damit wird erzwungen, daß Apache alle angeforderten Dateien mit der Endung .msql nur über das CGI-Programm w3-msql ausliefert. Diese Sicherheitslücke wäre somit geschloßen.

### 4.1.7.2 W3-Auth

Source-Quellen: http://www.Hughes.com.au
Damit w3-auth überhaupt mit dem Web-Server Apache funktioniert, muß diesem eine bereits ausgetriebene Sicherheitslücke (so sehen es zumindest die Entwickler von Apache) wieder beigebracht werden. Dies geschit am einfachsten durch einen Patch, der bei der oben angegebenen Adresse gesaugt werden kann.

In seiner aktuellen Version gibt der Web-Server die an ihn (über das HTTP Authorisierungs-Protokoll) übergebenen Variablen aus der Browser Authorisierungfunktion nicht an CGI-Skripten weiter. Somit wird unterbunden, daß durch Hacker in das cgi-bin Verzeichnis eingepflanzte ``Trojanische Pferde'' die Passwörter der Benutzer ausspionieren.

Die Entwickler von Apache sahen dies als großes Sicherheitsrisiko. Für die Entwickler von Mini SQL dagegen stellt das kein so großes Problem dar. Sie sind der Meinung, daß wenn es einem Hacker gelingt, ein ``Trojanisches Pferd'' zu setzten, das ganze UNIX-System nicht sicher genug sei.
Wirkungsweise des Patches:
Durch den Patch wird die Datei ./src/mod_cgi.c im Source-Code Verzeichnis von Apache so modifiziert, daß der kompilierte Web-Server die Variablen aus dem HTTP Authorisierungs-Protokoll an bestimmte CGI-Programme weitergibt.

In der Datei ./conf/srm.conf im Installations-Verzeichnis des Web-Servers wird festgelegt, an welche Programme er die Variablen weiterleiten soll. Hierzu sind die folgenden Zeilen einzufügen:
`PassAuthHeaders /cgi-bin/w3-auth
PassAuthHeaders /cgi-bin/w3-msql`
Soll der Server die Variablen noch an andere CGI-Skripten weiterreichen, so sind diese hier mit anzugeben.

# 4.2 PHP/FI

Source-Quellen: http://php.iquest.net
PHP/FI ist als Freeware im Source-Code unter oben angegebenen Adresse zu beziehen. In seiner derzeitigen Version 2.0b12 ist PHP/FI sowohl als CGI-Skript als auch als direktes Apache Modul einsetzbar.

Bis heute hat es sich von seiner ursprünglichen Funktion - als Parser für eingebettete Skripten in HTML-Dateien - zu einer komplexen Schnittstelle zur Datenbankanbindung entwickelt. Dabei unterstützt es inzwischen die Anbindung verschiedener Datenbanksysteme (z.B. mSQL, Postgres95, mySQL, Solid, Sybase und sogar Oracle).

Genau wie bei W3-mSQL wird hier die gesammte Steuerung der Datenbankanbindung durch eine in HTML-Dateien eingebettete Skriptsprache realisiert. Eine gesonderte CGI-Programmierung ist auch hier nicht erforderlich.

Da die Installation von PHP/FI für alle unterstützten Datenbanksysteme analog geschieht, ist in Kapitel 4.2.3 (S. ) stellvertretend für alle die PostgreSQL spezifische Installation beschrieben.

## 4.2.1 Funktionalität

Durch den Einsatz von PHP/FI und der damit zur Verfügung stehenden Funktionalität lassen sich auf einfache Weise anspruchsvolle Web-Anwendungen realisieren.

Hierzu werden die von PHP/FI zur Verfügung gestellten C ähnlichen Sprachelemente einfach in HTML Dateien eingebettet. Diese unterscheiden sich von Standard-HTML dadurch, daß sie innerhalb von <? > Tags stehen. Dabei können in einer HTML Datei mehrere solcher Tag's stehen; innerhalb eines Tag's können mehrere Anweisungen durch ``;'' getrennt untergebracht werden.

Bei der Anforderung durch einen Web-Browser werden diese Dateien dann von PHP/FI geparst, interpretiert und das Ergebnis an den Client weitergeleitet. Dieser sieht dann nur noch das Ergebnis. Der Source Code der eigentlichen Datei bleibt dabei verborgen.

Damit dies immer gewährleistet ist, und niemand die Dateien (und damit den Source Code) durch Umgehen von PHP/FI laden kann, sollten diese Dateien eine gesonderte Endung erhalten (z.B. *.phtml). Beim Einsatz von PHP/FI als CGI-Programm muß deshalb der Web Server angewiesen werden, alle Dateien mit der entsprechenden Endung nur über das CGI-Programm php.cgi auszuliefern. Für den Einsatz als Apache Modul siehe Kapitel 4.2.3 (S. ).

## 4.2.2 CGI oder Apache Modul ?

Ein großer Vorteil von PHP/FI ist, daß es sowohl als CGI-Programm (einsetzbar auf jedem Web-Server) als auch als integriertes Apache Modul eingesetzt werden kann. Aber dieser Vorteil birgt auch einige Nachteile.

Beim Einsatz als CGI-Programm kann die große Funktionalität von PHP/FI schnell zu einer Gefahr werden. Informationen aus entsprechenden Mailinglisten[3] zu Folge kann damit das ganze System von Hackern lahmgelegt werden. Die Empfehlung lautet daher immer wieder, PHP/FI nur als Apache Modul einzusetzen.

Dies ist nicht nur sicherer, sondern bringt auch noch andere Vorteile mit sich.

- Performance
  Als Apache Modul werden die entsprechenden *.phtml Dateien direkt als Server Prozeß ausgeführt. Dies ist wesentlich schneller als herkömmliche CGI Methode.
- Sicherheit
  Wenn PHP/FI als Modul betrieben wird, werden vor dem Parsen der Dateien die Zugriffsbeschränkungen der normalen Apache conf Dateien sowie der .htaccess Dateien beachtet. Ebenso kann PHP/FI die httpd-basierende Authentifikation kontrollieren. Passwort geschützte Web-Verzeichnisse können somit von PHP/FI als Apache Modul nicht eingesehen werden. Als CGI-Programm hingegen werden all diese Regeln und Einschränkungen mißachtet.
- Konfigurierbarkeit
  Da PHP/FI immer innerhalb des Web Server Prozesses residiert, kann es über die Konfigurationsdateien des Web Servers bzw. über die .htaccess Dateien in den einzelnen Verzeichnissen mittels eigener PHP/FI Konfigurationsanweisungen konfiguriert werden.

Für alle weiteren Tests wurde deshalb PHP/FI auch nur als Apache Modul eingesetzt.

## 4.2.3 Installation

Wie bereits einleitend erwähnt, sei hier nur die für PostgreSQL spezifische Installation beschrieben.

- Nach dem Entpacken der Sourcen wurde der in Anhang A.3 (S. ) beschriebene Patch ausgeführt. Danach wird im Source Code Verzeichnis das Installationsprogramm ausgeführt:
  `./install`
  Dabei werden ein paar Fragen zum aktuell verwendeten System gestellt. Für diese Installation wurden sie wie folgt beantwortet:
  `Do you have mSQL installed on this system? [yN] y
  Top of your mSQL install tree? [/usr/local/Minerva]
  /soft/postgresql-6.2
  Do you have Sybase libraries installed on this system [yN]
  Do you have Postgres installed in this system? [yN]
  Do you have mysql installed on this system? [yN]
  Do you have Solid installed in this system? [yN]
  Do you have Oracle installed in this system? [yN]
  Would you like to compile PHP/FI as an Apache module? [yN] y
  Are you compiling for an Apache 1.1 or later server? [Yn]
  Are you using Apache-Stronghold? [yN]
  Does your Apache server support ELF dynamic loading? [yN]
  Apache source directory (which has httpd.h)? [/usr/local/etc/httpd/src]
  /usr/src/packages/apache_1.2.3/src
  Would you like to include access control support? [yN]
  Would you like to include page logging support? [Yn] n
  Would you like to include file upload support? [Yn]
  Would you like to build an ELF shared library? [yN]
  Additional directories to search for .h files []:
  Additional directories to search for library files []:`
  Jetzt wird das plattformspezifische Makefile generiert. Zum Schluß wird noch eine Frage zur regexp Library gestellt;
  `Would you like the bundled regex library? [yN]`
  Dabei ist die einfachste und sicherste Lösung, die vorgeschlagene Antwort mit Return zu bestätigen.
- Anschließend wird in das ./src Verzeichnis gewechselt. Dort befindet sich eine Datei namens ./php.h. Sie beinhaltet einige gut beschriebene Optionen die vor dem kompilieren nocH geändert werden können. Für diese Installation wurde nichts geändert.
- Jetzt wird der Kompiliervorgang mit
  `make`
  gestartet. Dabei wird das CGI-Programm php.cgi erzeugt, und, falls PHP/FI als Apache-Modul eingesetzt werden soll, auch die Datei libphp.a.
- Nicht als Apache Modul .....
  php.cgi in das cgi-bin Verzeichnis des Server kopieren.
  aus breits erwähnten Gründen (Kapitel 4.2.2, S. ) nicht ratsam ....
  Als Apache-Modul .....
  Wurde beim obigen Installationsvorgang das Source-Verzeichnis des Web-Server bereits richtig angegeben, so sind die Dateien lib_php.c, lib_php.h sowie libphp.a bereits dorthin kopiert worden. Wenn nicht, so ist dies noch zu erledigen.
  Nach dem Wechsel in das Apache-Source-Verzeichnis, müssen in der Datei Configuration noch die am Ende von `make` ausgegebenen Änderungen in der EXTRA_LIBS Zeile vorgenommen werden. Bei dieser Installation lautete die Änderung
  `EXTRA_LIBS=-L. -lphp -lgdbm -L/soft/postgresql-6.2/lib -lpq -lm`
  In die letzte Zeile der Konfigurationsdatei ist dann noch
  `Module php_module mod_php.o`
  hinzuzufügen.
  Jetzt kann der Apache Web Server neu kompiliert werden.
- In der Datei ./conf/srm.conf muß nach der Installation des neu kompilierten Web-Servers die Zeile
  `AddType application/x-httpd-php .phtml`
  hinzugefügt werden, um den Server anzuweisen, daß alle Dateien mit der Endung *.phtml durch das neue Modul PHP/FI geparst werden müssen. Dabei kann die Endung frei gewählt werden.

## 4.2.4 Verwendung von PHP/FI mit der Datenbank mSQL

Da PHP/FI zur Anbindung von mSQL an das Internet denselben Funktionsumfang wie W3-mSQL zur Verfügung stellt, kommt man auch ohne einen Test zu folgender Erkenntnis.

Wie in Kapitel 4.1.6 (S. ) beschrieben, liegen die meisten Schwachstellen (Sicherheitslücken) in der Datenbank mSQL selbst. Der Einsatz von PHP/FI in Verbindung mit mSQL ist demnach genauso zu bewerten wie der Einsatz von W3-mSQL.

## 4.2.5 Verwendung von PHP/FI mit der Datenbank PostgreSQL

Für die Zusammenarbeit von PHP/FI mit PostgreSQL wurden die Sourcen von PHP/FI gepatched (siehe Anhang A.3, S. ). Dies war notwendig, um auf passwortgeschützte Datenbanken zuzugreifen.

Der anschließende Test, sowie auch die Bewertung beziehen sich auf die gepatchte Version von PHP/FI.

### 4.2.5.1 Test

Um für die Bewertung dieses Web-Interfaces eine gemeinsame Grundlage zu schaffen, wurde der Test von PHP/FI analog zu Kapitel 4.1.5.1 (S. ) aufgebaut.
Auch hier ist der Test auf die folgenden Testkriterien beschränkt.

- Allgemeine Handhabung beim Einbetten von SQL-Befehlen in HTML Dateien
- Tabellen-Handling (Anlegen, Löschen, Tabelleneinträge hinzufügen, etc ...)
- Datenbank-Handling (Anlegen, Löschen)

Für den Test wurden die Testdateien aus oben genannten Kapitel für den Gebrauch von PHP/FI umgeschrieben, so daß die gleiche Dateistruktur (mit gleichem Funktionsumfang) wie in Abbildung 4.5 (S. ) zum Einsatz kam. Auch die verwendete Datenbank hatte den gleichen Aufbau (Tabelle 4.2, S. ); jedoch wurde der Zugriff auf diese Datenbank Passwort geschützt und nur einem einzigen Benutzer gestattet.

Somit kann also ein direkter Vergleich der zwischen den beiden Interfaces ermöglicht werden.

### Allgemeine Handhabung

Mit etwas C Kenntnissen ist es mittels PHP/FI sehr einfach Datenbankinteraktionen in HTML Dateien einzubetten. Hierbei grenzen sich die PHP/FI Anweisungen von normalem HTML durch die Tag's '<?' und '>' ab. Alle innerhalb dieser Tags stehenden Anweisungen werden vor dem Ausliefern an den Client interpretiert, und nur das Ergebnis an den Client weitergeleitet. Dieser sieht von den ursprünglichen Anweisungen nichts mehr.

### Tabelleninhalte ansehen, anlegen, ändern oder löschen

Es soll nun genauso wie beim Test von W3-mSQL der Inhalt der Tabelle 'bestand' angezeigt werden. Die Ausgabe kann ebenfalls auf bestimmte Artikelnummern beschränkt werden.
Mit den folgenden PHP/FI Code kann dies auf einfachste Weise bewerkstelligt werden.
`<?
$sock = pg_sconnect("localhost","5432","simpletest","firma2","test");
$sel_result = pg_Exec($sock, "select * from bestand where art_nr like
'$select_art_nr' order by art_nr");
$rows = pg_NumRows($sel_result);
$index = 0;
while ($index < $rows)
{
$row[0] = pg_result($sel_result, $index, "art_nr");
$row[1] = pg_result($sel_result, $index, 1);
$row[2] = pg_result($sel_result, $index, "stueck");
echo $row[0], `` ... ``, $row[1], `` ... ``, $row[2], ``<br>'';
$index++;
}
pg_Close($sock);
>
`
Beschreibung:
pg_sconnect stellt eine Verbindung zur Datenbank 'simpletest' über den Datenbank Server auf dem 'localhost' über Port '5432' her. Da die Datenbank Passwort geschützt ist, wird noch der Benutzername 'firma2' und das Passwort 'test' übergeben. Kommt eine Verbindung zustande, steht ihr Ergebnis in der Variablen $sock.
pg_Exec führt auf der bestehenden Datenbankverbindung $sock das in Hochkomma stehende SQL-Statement aus.
Wird ein Ergebnis zurückgeliefert, so gibt pg_NumRows die Anzahl der zurückgelieferten Treffer an. In der darauffolgenden while Schleife erfolgt dann die Ausgabe der Treffer; dazu holt pg_result aus der Ergebnismenge $sel_result aus der Zeile $index das Feld ``art_nr''.
pg_Close schließt die Verbindung zum Datenbank Server.
Beim Browser des Client kommen nur die mit echo ausgegebenen Daten an.
Auch das Anlegen, Ändern und Löschen von Tabelleninhalten wird über die von PostgreSQL unterstützten Standard SQL Befehle ausgeführt. Im Folgenden drei Beispiele:
Anlegen:
`<?
pg_Exec($sock, ``INSERT INTO bestand (art_nr, art_bez, stueck)
VALUES ('000456001', 'Artikel 123', 100)'');
>`
Ändern:
`<?
pg_Exec($sock, ``UPDATE bestand SET art_bez='Artikel 200'
WHERE art_nr='000456001''');
>`
Löschen:
`<?
pg_Exec($sock, ``DELETE FROM bestand WHERE art_nr='000456001''');
>`

### Tabellen anlegen, löschen oder editieren

Hierzu werden mittels pg_Exec() die Standard SQL-Statements zum Anlegen (CREATE TABLE), Löschen (DROP TABLE) oder Editieren (ALTER TABLE) von Tabellen an die entsprechende Datenbank geschickt.

### Datenbank anlegen und löschen

Da die Datenbank PostgreSQL die SQL Befehle CREATE DATABASE und DROP DATABASE unterstützt, kann über pg_Exec() auf einfache Weise eine neue Datenbank erzeugt bzw. gelöscht werden. Dazu ist es aber notwendig, daß der Benutzer nicht nur Zugriffsrechte auf eine Datenbank besitzt, sondern mit den vollen Administratinsrechten ausgestattet ist.

Wenn dies nicht allen Benutzern gestattet wird, kann das Datenbank Management System PostgreSQL mittels PHP/FI durchaus auch über das Internet verwaltet werden.

### 4.2.5.2 Bewertung

Weil PostgreSQL als Datenbank Management System alle wichtigen Funktionen - wie z.B. einen Zugriffschutz auf Datenbanken mittels Passwortabfrage - unterstützt, und PHP/FI fast den ganzen Funktionsumfang für die Anbindung an das Internet zur Verfügung stellt, kann die Bewertung für das Zusammenspiel beider nur positiv ausfallen.

Ein kleiner schwarzer Fleck in PHP/FI mag sicherlich sein, daß es in seiner Version 2b12 einen Zugriff aus passwortgeschützte Datenbanken noch nicht unterstützt, aber ein kleiner Patch in Anhang A.3 (S. ) löste dieses Problem zur Zufriedenheit.

Ohne diesen Patch würde der Zugriff auf Datenbanken durch den User des Web-Servers (z.B. nobody) erfolgen. Dafür müßte dieser alle relevanten Rechte erhalten. Dies hätte die selben Probleme zur Folge, wie bei mSQL und dem W3-mSQL Interface.

Durch die neue Funktion pg_sconnect(), die dieser Patch hinzufügt, ist auch ein Zugriff auf geschützte Datenbank möglich. Der Zugriff erfolgt dabei unter dem Namen des entsprechenden Benutzers. Somit ist also auch eine Benutzerverwaltung möglich und ein Abschotten der Datenbanken vor unberechtigtem Zugriff über das Internet möglich.
PostgreSQL mit PHP/FI sind daher gut für einen Service Provider geeignet, wenn er Web-Space mit Datenbankanbindung vermieten will. Jedoch sollte er administrative Aufgaben, wie das Anlegen und Löschen von Datenbanken nicht an den Kunden weitergeben. Weiter sollte er beachten, daß er für jeden Kunden mit Datenbankanbindung eine eigene Passwortdatei anlegt, und jede Datenbank eines Kunden damit schützt. Nur so kann gewährleistet werden, daß andere, die auf demselben Server Web-Space besitzen, einen unzulassigen Zugriff auf die Datenbank tätigen können.

Zu guter Letzt sollte das oberste Gebot an seine Kunden sein, daß sie ihre *.phtml Dateien für alle anderen schreib- und leseschützen.
Zusammenfassend lassen sich also folgende Merkmale feststellen:

- Gut: kostengünstigste Datenbankanbindung an das Internet, da beide Software Pakete als Freeware zu erhalten sind.
- Gut: die einfache C ähnliche Skriptsprache, die sich schnell in HTML Dateien einbetten läßt.
- Gut: beim Einsatz als Apache Modul kann die bewährte Zugriffskontrolle des Web-Servers für Web-Verzeichnisse voll genutzt werden.
- Gut: PostgreSQL versteht SQL Befehle des SQL-3 Standards.
- Mangelhaft: als CGI-Programm kann PHP/FI zur Eintittskarte für Hacker werden.