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 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. ![[*]](icons/cross_ref_motif.gif){kind=icon}
).
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. ).
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>
<
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.
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. ).
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.
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.
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.
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.
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.
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.
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.
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.
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.
| 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.
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:
).
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.
) 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. ). 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. ).
Ä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'.
)
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').
).
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.
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
Um sich einen Test des gesamten Funktionsumfangs von W3-mSQL zu ersparen, wurden folgende Testkriterien festgelegt.
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. ).
).
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.
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''');
>
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.
Ähnlich wie das Anlegen einer Tabelle gestaltet sich auch das Löschen
dieser.
<!
msqlQuery($sock, ``drop table Tabelle_1'');
>
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.
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.
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.
) 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.
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:
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ß.
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.
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.
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.
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.
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. ).
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.
Für alle weiteren Tests wurde deshalb PHP/FI auch nur als Apache Modul eingesetzt.
Wie bereits einleitend erwähnt, sei hier nur die für PostgreSQL spezifische Installation beschrieben.
) beschriebene Patch ausgeführt. Danach
wird im Source Code Verzeichnis das Installationsprogramm ausgeführt:
aus breits erwähnten Gründen (Kapitel 4.2.2, S.
) nicht ratsam ....
Da PHP/FI zur Anbindung von mSQL an das Internet denselben Funktionsumfang![[*]](icons/foot_motif.gif){kind=icon}
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.
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.
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.
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.
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.
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''');
>
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.
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.
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:
Christian Eibisch
