[Web-Security] Gegeben ist ein öffentlich erreichbarer Webservice

Aus der Aufgabenstellung geht nicht so ganz hervor, ob es wirklich gewünscht ist, dass jemand anonym auf diesen Webservice zugriff hat. Sollte dies nicht gewünscht sein, so würde sich ein htaccess Schutz der URL anbieten. Damit würde jegliche unbefugte Nutzung unterbunden.

Für die öffentliche Nutzung habe ich folge Vorschläge:

Limitierung der GET/POST Requests auf z.B. 5 pro Minute

Verhindert das maschinelle Auslesen von Profile durch einen Crawler.

Implementierung erfolgt idealerweise in der Schicht des Webservers. z.B. mod_security beim Apache2.

POST Request nur nach vorheriger Authentifizierung

Ich kann nur die Daten verändern, die meiner User ID entsprechen.

<?php

.....

if ( intval( $_POST['id'] ) !== intval( $_SESSION['user_id'] ) ) {
die( 'Access denied!' );
}

Validierung von Parametern

Verhindern von unvollständigen nicht korrekten Daten.

<?php

.....

if ( strlen( $_POST['firstname'] ) === 0 ) {
die( 'Vorname fehlt.' );
}

"Entschärfen" von Parametern

Vehindert das Einfügen von schadhaftem Code in die Persistenz-Schicht. Dieser würde bei GET Request wieder ausgelesen und eventuell ausgeführt: z.B. XSS, XSRF

<?php

.....

$_POST['firstname'] = htmlspecialchars( $_POST['firstname'] );

Die Code-Beispiele empfehlen sich nicht für die konkrete Umsetzung. Ich arbeite ausschließlich objektorientiert und hätte somit z.B. eine Request-Klasse, die das sanitizen von Inhalten kapseln würde. Auch für die Validierung von Inhalten bietet sich eine Validation-Klasse an.

grails install-plugin spring-security-core

Wer mehr codet ist selber schuld ;)

Das Überschreiben der Benutzerinformationen sollten per Benutzername/Passwort abgesichert werden. Die Authentifizierung wird wahlweise per HTTP-Authentifizierung (Basic oder Digest Access) oder per separatem Login-Webservice vorgenommen.

Bei Basic Authentication sollte auf jeden Fall die Verbindung per HTTPS gesichert werden, da das Passwort nicht verschlüsselt übertragen wird. Bei den anderen beiden Methoden ist das ebenfalls empfehlenswert um Man-in-the-Middle-Angriffe und Angriffe via DNS Poisoning abwehren zu können.

In allen Methoden muss bei jeder POST-Anfrage ein Authentifizierungstoken (Session-ID oder Benutzername und Passwort) im HTTP-Header mitgesendet werden. Dieses muss vom Server auf seine Gültigkeit geprüft werden.

Statt einer Session-ID (beim Login-Webservice) könnte alternativ auch die IP-Adresse des Clients beim Login freigeschaltet werden. Davon sollte aber abgesehen werden, da:

• sich hinter der IP-Adresse mehrere Clients befinden können (Router).
• eine IP-Adresse gefälscht werden kann (IP-Spoofing)

Zusammenfassend hier noch einmal die Vor- und Nachteile der verschiedenen Lösungen:

• HTTP Basic Authentication
• Vorteil: Standardisiert; die Überprüfung wird vom Webserver übernommen; verschiedene Passwort-Backends verfügbar
• Vorteil: client-seitig sehr einfach zu implementieren
• Nachteil: Benötigt HTTPS
• HTTP Digest Access Authentication
• Vorteil: Standardisiert; die Überprüfung wird vom Webserver übernommen; verschiedene Passwort-Backends verfügbar
• Vorteil: Passwort wird verschlüsselt übertragen
• Nachteil: client-seitige Implementierung komplexer als bei Basic Authentication
• Session
• Vorteil: Sessions werden von vielen Server-Frameworks (PHP) direkt unterstützt und sind einfach verwendbar
• Vorteil: Session läuft (im Gegensatz zu Benutzername und Passwort bei HTTP-Authentifizierung) nach einer gewissen Zeit automatisch ab. Das Ermitteln der Session-ID nach der Ablaufzeit bietet also keine Angriffsfläche.
• Nachteil: Authentifizierung muss server-seitig manuell implementiert werden, was mit zusätzlichem Aufwand verbunden ist.

Hallo,

Sicher sind eine eigene Loginmaske oder ein Login per htaccess und htpasswd eine Möglichkeit, doch auch solche Daten können bei Userbezogenen Daten ein Risiko darstellen, da Passwörter teilweise auch schlampig aufbewahrt werden.

Meine Lösung wäre eine IP Restriction! So wird gewährleistet, dass man wirklich nur aus einem bestimmten IP Bereich oder von einem direkten Computer Zugriff auf die Daten hat.

Per Code (z.B.) PHP:

function check_ip() {
	if ($_SERVER['REMOTE_ADDR']=='xxx.xx.xxx.xx' || 
		$_SERVER['REMOTE_ADDR']=='yy.yyy.yy.yy'
	) {
		return false;
	}
	header('Location: /index.html');
	die;
}

 oder in der htaccess

Allow from xx.xx.xx.xx,yy.yy.yy.yy