Inhalt Abbildung PDF Source SCWCD
 |<    <     >    >|  Generated by CoCoDiL

7 Web Application Security

7.1 Begriffsbestimmungen

Based on the servlet specification, compare and contrast the following security mechanisms: (a) authentication, (b) authorization, (c) data integrity, and (d) confidentiality.

Authentication

Darunter versteht man den Prozeß die Identität eines Clienten bzw. Anwenders festzustellen. Das einfachste Mittel ist durch Eingabe von Benutzernamen und Passwort. In Zukunft könnten das Scannen von Fingerabdruck, Augen Iris sein. Die Authentication beschäftigt sich nicht mit Rechtevergabe ist aber die Vorraussetzung dazu.

Authorization

Ist die Identität des Benutzers festgestellt, so ist der nächste logische Schritt die Authorization. Hier geht es darum festzustellen ob der Anwender die Rechte hat, auf die angeforderten Ressourcen zuzugreifen.

Data Integrity

Data Integrity ist der Prozeß zu versichern, dass während der Übertragung sich die Daten nicht verändert haben. Dies kann z.B. durch Prüfsummenbildung geschehen.

Confidentialy

Confidentialy sichert, dass kein unerlaubter Anwender vertrauliche Daten lesen kann. Während Authorization versucht den Zugang zu Daten zu regeln, versucht Confidentialy die Daten selbst dann zu schützen, falls ein Unbefugter die Daten schon bekommen hat. Dies geht durch Verschlüsselungsstrategien.

7.2 security constraint und login configuration

In the deployment descriptor, declare a security constraint, a Web resource, the transport guarantee, the login configuration, and a security role.

Eine Security Constraint definiert welche Ressourcen auf welche Art geschützt werden sollen. Sie besteht aus i.a. drei Unterelementen


Abb. 7.1: Aufbau einer SecurityConstraint

web-resource-collection

Mit einem URL-Pattern spezifiziert man, welche Ressourcen zu schützen sind. Zusätzlich können noch Angaben zu den für den Zugriff auf die jeweiligen Ressource erlaubten HTTP-Methoden gemacht werden.

auth-constraint

Alle Benutzer, die die angegebene Rolle innehaben, können auf die geschätzten Web-Ressource zugreifen. Die Rollen müssen in der Datei web.xml in dem Element security-role definiert sein.


Abb. 7.2: Security Role

Beispiel:

Statt eines bestimmten Rollennamens kann auch der Matchcode '*' verwendet werden, soll die Ressource für alle der Anwendung bekannten Rollen freigegeben werden. Wird dagegen keine der Rollen angegeben, ist dieser Teil der Wbanwendung für alle Benutzer gesperrt.

user-data-constraint

Das Unterelement transport-guarantee kann folgende Werte annehmen:

NameBedeutung
NoneKeine Anforderung (Default Wert)
IntegralDaten dürfen beim Versenden nicht verändert werden
ConfidentialDaten dürfen beim Versenden nicht von Dritten eingesehen werden

Beispiel:

Dieses security Constraint schützt alle Ressourcen deren UI mit /admin anfängt. Es dürfen nur Benutzer mit der Rolle admin auf diese Ressourcen zugreifen. Ausserdem kann der Zugriff nur über die get Methode erfolgen. Bei der Übertragen der Daten muss garantiert sein, dass diese nicht von Dritten einsehbar ist.

login-config

Mit dem Element login-config wird in der Datei web.xml bestimmt welche Typ zur Authentifizierung genommen wird (siehe weiter unter).


Abb. 7.3: Login-config

Beispiel:

Das Element auth-method kann eine der Methoden BASIC,DIGEST,FORM oder CLIENT-CERT annehmen. Der realm-name wird bei dem Formalar das der Brwoser zur Eingabe von Benutzer und Passwort eingibt, angezeigt.

Wird die Authentifizierung FORM benutzt, muss die Seite zur Login Eingabe und die Fehlerseite falls der Login fehlerhaft ist angegeben werden.

7.3 Authentifizierungs Typen

Compare and contrast the authentication types (BASIC, DIGEST, FORM, and CLIENT-CERT); describe how the type works; and given a scenario, select an appropriate type.

Es werden 5 Möglichkeiten angeboten, wie man einen Anwender indentifizieren kann.

NameBedeutung
BASICHTTP-Authentifizierung auf der Basis von Benutzername und Passwort
DIGESTVerschlüsselte Übergabe des Passworts
FORMBasis Authentifizierung, über ein benutzerdefiniertes Login-Formular
CLIENT-CERTHttps-Client-Authentifizierung

HTTP BASIC Authentication

Die Identitifizierung läuft folgendermassen ab.

HTTP DIGEST Authentication

Die Identifizierung läuft fast identisch mit der Methode BASIC ab. Allerdings gibt es einen Mechanismus um das Passwort zu verschlüsseln.

HTTP FORM Authentication

Dies ist die einzigste Typ indem der Programmierer die Anmeldeseite selber gestalten kann. Folgende Konventionen gelten für eine selber formulierte Anmeldeseite:

HTTPS CLIENT-CERT Authentication

Es wird das HTTPS Protokoll (SSL-Verbindung) verwendet und die Daten werden mit einem Public-Key Verfahren verschlüsselt. Dies ist die sicherste Methode benötigt aber eine Zertifizierung von einer autorisierten Stellen. Genaue Kenntnisse über das Verfahren, ist für die Zertifizierung wahrscheinlich nicht notwendig.

Die Vor- und Nachteile habe ich in einer Tabelle zusammengefasst

TYPVORTEILENACHTEILE
BASICJeder Browser unterstützt esAussehen der Login-Page nicht wählbar
Sehr einfach zu konfigurierenSehr unsicher Passwort und Benutzername nicht verschlüsselt
DIGESTSehr einfach zu konfigurierenAussehen der Login-Page nicht wählbar
Sicherer als BASIC. Es wird Passwort verschlüsseltNicht jeder Browser unterstützt es
FORMAlle Browser unterstützen esNicht sicher da Benutzer und Passwort nicht verschlüsselt
Look and Feel Login-Page wählbarSollte nur im Zusammenhang mit HTTPS oder Cookies verwendet werden
Einfach zu konfigurieren
HTTPS CLIENT CERTDas sichertse aller VerfahrenZertifizierung durch autorisierte Stelle notwendig
Wird von allen Browser unterstütztteuer
Inhalt Abbildung PDF Source SCWCD
 |<    <     >    >|  Generated by CoCoDiL