$K(Web Application Security)
$KK(Begriffsbestimmungen)
$R(Objective)
Based on the servlet specification, compare and contrast the following security mechanisms:
(a) authentication, (b) authorization, (c) data integrity, and (d) confidentiality.
$R\
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.
$KK(security constraint und login configuration)
$R(Objective)
In the deployment descriptor, declare a security constraint, a Web resource, the transport guarantee,
the login configuration, and a security role.
$R\
Eine Security Constraint definiert welche Ressourcen auf welche Art geschützt werden sollen.
Sie besteht aus i.a. drei Unterelementen
* web-resource-collection - Enthält Liste von schützenswerten Ressourcen
* auth-constraint - Besagt wer darauf zugreifen kann
* user-data-constraint - Spezifiziert auf welche Art und Weise Ressourcen zum Clienten gesendet wird.
$B(Bilder,securityConstraint.gif,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.
$B(Bilder,securityRole.gif,Security Role)
Beispiel:
$S()
Mitglied der Controlling-Abteilung
controller
$S\
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:
$T(caption,cl)
Name | Bedeutung ||
None | Keine Anforderung (Default Wert) ||
Integral | Daten dürfen beim Versenden nicht verändert werden ||
Confidential | Daten dürfen beim Versenden nicht von Dritten eingesehen werden ||
$T\
Beispiel:
$S()
admin
/admin/*
GET
admin
CONFIDENTIAL
$S\
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).
$B(Bilder,loginConfig.gif,Login-config)
Beispiel:
$S()
BASIC
Protected pages
$S\
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.
$S()
FORM
/login/login.html
/login/error.html
$S\
$KK(Authentifizierungs Typen)
$R(Objective)
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.
$R\
Es werden 5 Möglichkeiten angeboten, wie man einen Anwender indentifizieren kann.
$T(caption,cl)
Name | Bedeutung ||
BASIC | HTTP-Authentifizierung auf der Basis von Benutzername und Passwort ||
DIGEST | Verschlüsselte Übergabe des Passworts ||
FORM | Basis Authentifizierung, über ein benutzerdefiniertes Login-Formular ||
CLIENT-CERT | Https-Client-Authentifizierung ||
$T\
HTTP BASIC Authentication
Die Identitifizierung läuft folgendermassen ab.
* Der Anwender sendet eine Anfrage.
* Der Servlet Container erkennt dass die angeforderte Ressource geschützt ist.
* Der Servlet Container sendet eine Antwort zurück, diese Antwort hat folgenden Inhalt
** StatusCode 401 UNAUTHORIZED
** Es wird mitgegeben welche Authentication Methode benötigt wird. in diesem Fall BASIC
** Es wird mitgegeben unter welchem Context(realm) die Authentication erfolgt.
* Der Browser des Anwenders liest die Antwort, und generiert einen Dialog. Der Dialog enthält
** den Context String realm
** Ein Eingabefeld für den Benutzernamen
** Ein Eingabefeld für Passwort
** Buttons zur Bestätigung der Eingaben bzw. Abbruch.
* Der Anwender gibt Benutzernamen und Passwort ein.
* Die ursprüngliche Anfrage wird nochmals gesendet, allerdings ist nun Benutzernamen
und Passwort in den Header der Anfrage eingebaut.
* Der ServletContainer empfaengt die Anfrage, überprueft ob Passwort und Benutzername
korrekt ist.
* Ist Passwort und Benutzername nicht korrekt, so gibt er wieder eine Antwort mit StatusCode
401 UNAUTHORIZED mit. Die beschriebene Prozedur wiederholt sich.
* Ist Passwort und Benutzername korrekt, so erhält der Anwender die Ressource
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:
* Es benötigt 2 Eingabefelder j_password und J_username
* Es benötigt ein Action Attribut j_security_check
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
$T(caption,cll)
TYP | VORTEILE | NACHTEILE ||
BASIC | Jeder Browser unterstützt es | Aussehen der Login-Page nicht wählbar ||
| Sehr einfach zu konfigurieren | Sehr unsicher Passwort und Benutzername nicht verschlüsselt ||
DIGEST | Sehr einfach zu konfigurieren | Aussehen der Login-Page nicht wählbar ||
| Sicherer als BASIC. Es wird Passwort verschlüsselt | Nicht jeder Browser unterstützt es ||
FORM | Alle Browser unterstützen es | Nicht sicher da Benutzer und Passwort nicht verschlüsselt ||
| Look and Feel Login-Page wählbar | Sollte nur im Zusammenhang mit HTTPS oder Cookies verwendet werden ||
| Einfach zu konfigurieren | ||
HTTPS CLIENT CERT | Das sichertse aller Verfahren | Zertifizierung durch autorisierte Stelle notwendig ||
| Wird von allen Browser unterstützt | teuer ||
$T\