Warum Schutz von Internet-Hyperlinks vor unberechtigtem Zugriff?

Der Schutz von Internet-Hyperlinks vor unberechtigtem Zugriff besteht darin, einen Hyperlink besonders zu kennzeichnen und ihn vor dem Hin-Navigieren in einem speziellen Verfahren zu bearbeiten. Es wird eine Verbindung zum gewünschten Server aufgebaut. In dieser Verbindung wird die Zugangsberechtigung des Benutzers in einer sicheren Methode überprüft. Außerdem wird die Authentizität des gewünschten Servers sichergestellt.
Der Benutzer kann sicher sein, dass er den "richtigen" Server erreicht hat.

Inhalte-Anbieter bieten kostenpflichtige Inhalte im Internet nur dann an, wenn sichergestellt ist, dass sie nur ihren zahlenden Abonnenten zur Verfügung stehen. Internet-Hyperlinks haben die Eigenschaft, dass sie entweder frei zugänglich sind und mit jedem Browser gelesen werden können oder durch ein aufwendiges Verfahren über Eingabe von Benutzernamen und Kennwort geschützt werden. Dieses Verfahren bedeutet nicht unerheblichen Aufwand für den Inhalte-Anbieter. Mit dem vorgestellten Verfahren kann eine Berechtigungsprüfung durchgeführt werden, damit nur zugelassene Benutzer auf die kostenpflichtigen Inhalte von Inhalte-Anbietern zugreifen können.
Der Anbieter kann sicher sein, dass er nur "berechtigte" Benutzer hat.

• mit diesem Verfahren besitzt der Benutzer die Sicherheit, dass es sich bei dem Anbieter der Inhalte im Internet um den gewünschten Anbieter handelt.
  Z.B. kann eine Bank ihr Online-Banking-Verfahren absichern, für den Benutzer wird damit das "Phishing" von Informationen eliminiert. Die Eingabe von TAN- oder iTAN-Nummern und anderen hochsensiblen Informationen wird nur dann durchgeführt, wenn der Benutzer sicher ist, dass er den "richtigen" Server erreicht.
• mit diesem Verfahren besitzt der Anbieter von Inhalten im Internet die Sicherheit, dass es sich bei den zugelassenen Benutzern um berechtigte Benutzer handelt.
  Z.B. kann ein Verlag sicherstellen, dass nur "berechtigte" Benutzer Zugriff auf ihr Angebot haben.

Dazu bieten sich Methoden von Challenge/Response-Verfahren an. Während des Verbindungs-Aufbaus und/oder zu vorgegebenen Zeitpunkten im Ablauf der Verarbeitung kann der jeweils nächste Schritt und folgende Schritte anhand einer sicheren Methode feststellen, ob es sich um "zuverlässge" Kommunikationspartner handelt, die miteinander verbunden werden bzw. sind.

Ein Challenge/Response-Verfahren kann für jede Client/Server-Kombination anders aufgebaut sein. Dies trifft sogar zu, wenn derselbe Client auf verschiedene Seiten eines Web-Servers zugreifen will. Einzelne Seiten eines Servers können ungeschützt sein, andere Seiten des Servers können durch unterschiedliche Challenge/Response-Verfahren geschützt sein.

• Wenn die empfangene Response übereinstimmt mit der zu erwartenden Response, gibt der Server die weitere Verarbeitung frei.
• Wenn die empfangene Response nicht übereinstimmt mit der zu erwartenden Response, bricht der Server die weitere Verarbeitung ab. Der Client hat damit keinen Zugang zu den Inhalten hinter dem Link.
• Wenn das Autorisations-Prüfungs-Verfahren eingeleitet ist und keine Response vom Client kommt, bricht der Server die weitere Verarbeitung ab. Der Client hat damit keinen Zugang zu den Inhalten hinter dem Link.
• Wenn das Autorisations-Prüfungs-Verfahren von der Client-Seite überhaupt nicht eingeleitet wird (d.h. eine geschützte Seite wird direkt aufgerufen ohne dass der Client am einem Challende/Response-Verfahren teilnimmt), sendet der Server seine Challenge, wird aber keine Response erhalten. Dann bricht der Server die weitere Verarbeitung ab. Der Client hat damit keinen Zugang zu den Inhalten hinter dem Link.

Dieses Verfahren geht natürlich auch umgekehrt. Wenn der Client eine Challenge an den Server stellt, muss dieser sie beantworten, ansonsten bricht der Client die Verarbeitung ab.

Im nachfolgenden Beispiel stellt der Server als Challenge eine beliebig lange Zahl, als Response sendet der Client die einzelnen Ziffern dieser Zahl zusammenaddiert zurück. Dies ist kein sicheres Verfahren, sondern dient nur zu Demonstrationszwecken. Für ein sicheres Verfahren bieten sich z.B. Methoden der Verschlüsselung/Entschlüsselung, Schlüsselaustauschverfahren nach Diffie/Hellmann, oder andere kryptografische Methoden an.
nach oben

Sicherstellen, dass der Client zum richtigen Server verbindet

Zum Zeitpunkt des Verbindungs-Aufbaus und/oder zu einem Zeitpunkt während der Verarbeitung stellt der Server eine Frage (die sogenannte Challenge) an den Client und wartet auf die Antwort. Kann der Client die Challenge richtig beantworten, kann der Server sicher sein, dass es sich um einen "berechtigten" Client handelt. Andererseits ist der Client sicher, dass es sich um den "richtigen" Server handelt, mit dem er in Verbindung steht.
nach oben

Sicherstellen, dass der Server mit dem richtigen Client verbunden ist

Zum Zeitpunkt des Verbindungs-Aufbaus und/oder zu einem Zeitpunkt während der Verarbeitung stellt der Client eine Frage (die sogenannte Challenge) an den Server und wartet auf die Antwort. Kann der Server die Challenge richtig beantworten, kann der Client sicher sein, dass es sich um den "richtigen" Server handelt. Andererseits ist der Server sicher, dass es sich um einen "berechtigten" Client handelt, mit dem er in Verbindung steht.
nach oben

Demonstration in einer Beispiel-Anwendung

In dieser Beispiel-Anwendung werden einige Funktionen gezeigt, die es ermöglichen, einen Schutz des Zugangs eines Clients zum Server aufzubauen. In dieser Anwendung nimmt der Client die Verbindung zum Server auf, der Server stellt eine Challenge, der Client beantwortet die Challenge und erhält Zugang zu der gewünschten Seite.
nächstes Bild
nach oben

Bild 1

Dieser Dialog dient zur Verdeutlichung der Funktion der Komponente. Sie wird hier auch "Autorisations-Komponente" genannt, der Beispiel-Dialog auch "Autorisations-Dialog".
Damit werden die Abläufe während des Verbindungsaufbaus und der Berechtigungs-Überprüfung dargestellt. In einer realen Anwendung wird ein solcher Dialog nicht sichtbar sein. Der Ablauf wird im Hintergrund durchgeführt, ohne dass der Benutzer diesen Ablauf bemerkt und auch nicht jedesmal den "Weiter"-Button drücken muss.
nächstes Bild
nach oben

Bild 2

In diesem Dialog-Schritt wird darauf hingewiesen, dass der Dialog nicht sichtbar sein muss. Der Ablauf kann (und wird es wahrscheinlich auch tun) im Hintergrund durchgeführt werden, ohne dass der Benutzer diesen Ablauf bemerkt und auch nicht jedesmal den "Weiter"-Button drücken muss.
nächstes Bild
vorheriges Bild
nach oben

Bild 3

Wenn der Ablauf lange dauert (abhängig von der Leitungs-Geschwindigkeit oder der Geschwindigkeit des Client und/oder Server), können Animationen eingeblendet werden.
In diesem Dialog-Schritt sind drei animierte Bilder zu sehen. Die angezeigten Elemente können Windows-Standard-Elemente sein, z.B. avi- oder gif-Dateien oder animierte Cursor. Sound-Dateien können währenddessen abgespielt werden, html-Seiten mit Ihrer eigenen Werbung können angezeigt werden.

Die angezeigten Elemente können direkt von Ihrem Server geladen werden.
nächstes Bild
vorheriges Bild
nach oben

Bild 4

In diesem und den nächsten Dialog-Schritten wird die Funktionalität dargestellt. Die Autorisations-DLL beginnt jetzt ihre eigentliche Arbeit, nachdem sie in diesem Beispiel durch das Anklicken eines Internet-Links gestartet wurde (das Beispiel beinhaltet den Begriff "Feed-Link", weil die zugrunde liegende Anwendung mit RSS-Feeds arbeitet).

In diesem Dialog-Schritt sind die Buttons "Zugriff erlauben" und "Zugriff verhindern" hinzugekommen, die einen schnellen Weg aus der Autorisations-DLL ermöglichen, mit dem Ergebnis, dass der Zugriff auf den Inhalt, der hinter dem Link angeboten wird, "erlaubt" oder "verhindert" wird. In einer realen Anwendung (die keinen solchen Dialog enthält) sollten solche Funktionen nicht möglich sein, aber in diesem Beispiel wird gezeigt, wie die Autorisations-DLL arbeiten kann.
nächstes Bild
vorheriges Bild
nach oben

Bild 5

Dieses Bild zeigt an, dass die Autorisations-DLL AZAuth.dll aufgerufen wurde aufgrund des angeklickten Links. Dies ist eine Einstellung im Client. Falls hier kein Name einer Autorisations-DLL angegeben wird oder der Name einer anderen Autorisations-DLL, können der Client und der Server das Challenge/Response-Verfahren nicht durchführen. Der Server muss dann von einem "unberechtigten" Zugangs-Versuch ausgehen.
nächstes Bild
vorheriges Bild
nach oben

Bild 6

In diesem Bild wird gezeigt, dass der Client eine Verbindung zum Server aufgenommen hat. Durch den angegebenen Parameter wird die Prozedur "backend.php" auf dem Server gestartet. Diese Prozedur ist auf der Server-Seite zuerst für das Durchführen der Autorisations-Prüfung zuständig. Wenn die Autorisation geprüft ist und der Zugriff gestattet wird, kann diese Prozedur die weitere Verarbeitung einleiten oder selbst durchführen.
nächstes Bild
vorheriges Bild
nach oben

Bild 7

Zur Autorisations-Prüfung stellt die Prozedur "backend.php" die Challenge "123456789".
nächstes Bild
vorheriges Bild
nach oben

Bild 8

Da die Autorisations-DLL AZAuth.dll und die Server-Prozedur "backend.php" aufeinander angepasst sind, "weiß" AZAuth.dll, wie sie aus dieser Challenge eine Response ermitteln muss.
In diesem Beispiel ist es ganz einfach: die Ziffern der erhaltenen Challenge müssen einzeln addiert werden, die Gesamtsumme der einzelnen Ziffern ist die korrekte Response, also "45".

Für ein sicheres Verfahren bieten sich z.B. Methoden der Verschlüsselung/Entschlüsselung, Schlüsselaustauschverfahren nach Diffie/Hellmann, oder andere kryptografische Methoden an.
nächstes Bild
vorheriges Bild
nach oben

Bild 9

AZAuth.dll sendet die errechnete Response an den Server zurück.
nächstes Bild
vorheriges Bild
nach oben

Bild 10

Da die Autorisations-DLL AZAuth.dll und die Server-Prozedur "backend.php" aufeinander angepasst sind, "weiß" backend.php natürlich, welche Response zu erwarten ist.
Die Prozedur "backend.php" kann aus ihrer selbst gestellten Challenge die korrekte Response berechnen und vergleicht sie mit der Response, die sie von AZAuth.dll empfangen hat.
nächstes Bild
vorheriges Bild
nach oben

Bild 11

Wenn die empfangene Response übereinstimmt mit der zu erwartenden Response, gibt die Prozedur "backend.php" die weitere Verarbeitung frei oder führt sie selbst durch.

Wenn die empfangene Response nicht übereinstimmt mit der zu erwartenden Response, bricht die Prozedut "backend.php" die weitere Verarbeitung ab. Der Client hat damit keinen Zugang zu den Inhalten hinter dem Link.

Wenn das Autorisations-Prüfungs-Verfahren eingeleitet ist und keine Response vom Client kommt, bricht die Prozedut "backend.php" die weitere Verarbeitung ab. Der Client hat damit keinen Zugang zu den Inhalten hinter dem Link.

Wenn das Autorisations-Prüfungs-Verfahren von der Client-Seite überhaupt nicht eingeleitet wird (d.h. die Seite backend.php wird direkt aufgerufen ohne dass die Autorisations-DLL aktiv ist), sendet die Prozedut "backend.php" ihre Challenge, wird aber keine Response erhalten. Dann bricht die Prozedut "backend.php" die weitere Verarbeitung ab. Der Client hat damit keinen Zugang zu den Inhalten hinter dem Link.
vorheriges Bild
nach oben

Eine Anwendung

Der Schutz von Links vor unberechtigtem Zugriff ist in der Anwendung A-Z NewsReader beispielhaft realisiert.

Zum Ausprobieren des Schutzmechanismus kann die Anwendung A-Z NewsReader heruntergeladen werden. Danach muss die heruntergeladene Datei AZNewsReader.msi auf Ihrem Rechner installiert werden. Nach der Installation wird das Programm AZNewsReader.exe gestartet (entweder direkt aus dem Installationsverzeichnis oder vom Desktop über das angelegte Symbol . Nach dem Starten muss mit dem Button die Datei "Autorisation.rss" im Unterordner "Data" des Installationsverzeichnisses geöffnet werden.

Damit haben Sie dann die Möglichkeit, die hier beschriebenen Verfahren auszuprobieren.

In ihr werden die oben gezeigten Bilder im laufenden System ausgegeben, wenn unter der Kategorie "Simulation des Schutzmechanismus" mit den Links "A-Z Technology AG Demo 1" oder "A-Z Technology AG Demo 4" die Demonstration gestartet wird. Die Links "A-Z Technology AG Demo 2" und "A-Z Technology AG Demo 3" demonstrieren fehlerhafte Situationen, die nicht zur Berechtigung zum Zugang führen.



In der Kategorie "Schutzmechanismus mit PHP-Prozedur" mit den Links "A-Z Technology AG Real 1" und "A-Z Technology AG Real 4" wird ein Zugang zu der Seite backend1.php auf dem entsprechenden Server durchgeführt. Die Links "A-Z Technology AG Real 2" und "A-Z Technology AG Real 3" demonstrieren fehlerhafte Situationen, die nicht zur Berechtigung zum Zugang führen.
nach oben