$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\