Eigene PHP SOAP Api und die Sicherheit

Hallo,

ich arbeite mich gerade in die Api-Programmierung mit PHP und SOAP ein. Dazu habe ich ein paar sicherheitstechnische Fragen.

Ich habe mir eine Klasse für einen SOAP-Server Programmiert und einen passenden Client dazu, der auf die Methoden des Servers zugreifen kann und sich dort die Daten abholen kann.

Wie aber mache ich die Datenübertragung möglichst sicher? Der Client bekommt einen API-Key, den er dem Server bei jedem Request als Parameter für die Methode mitliefern muss. Der Server prüft den Key und gibt dann die Daten aus?

So wird aber bei jedem Request der API-Key mitgesendet. Stellt dies nicht ein Sicherheitsrisiko dar? Könnte der Key nicht irgendwie abgefangen werden und wie kann ich das am besten umgehen?

Danke und Gruß
Oneside

Schau dir das mal an:
http://docs.oasis-open.org/wss/2004/...rofile-1.0.pdf

Edit:
+ SSL

Nochmal Edit:
Mist, Amica war schneller

Hallo,

wenn dir SSL zur Verfügung steht, würde ich das empfehlen, ansonsten HTTP Digest Authentication. Infos und Beispiele stehen im Handbuch zu SoapClient::SoapClient.

Gruß,

Amica

Danke schonmal für die Antworten :-)

Also durch das UsernameToken Profile 1.0 blicke ich auf die Schnelle nicht wirklich durch. SSL will ich eigentlich nicht einsetzen, weil die Daten die übertragen werden keine wirklich sensiblen Daten sind. Durch die Autentifizierung will ich nur verhindern, dass unbefugte die Schnittstelle nutzen können.

Zitat von oneside

SSL will ich eigentlich nicht einsetzen, weil die Daten die übertragen werden keine wirklich sensiblen Daten sind. Durch die Autentifizierung will ich nur verhindern, dass unbefugte die Schnittstelle nutzen können.

Ob Token, Session-ID oder Auth-Credentials - das was den Befugten vom Unbefugten unterscheidet, ist ein sensibles Datum.

Was meinst du mit sensiblem Datum?

Na jegliche Anmeldeinformationen: "Ob Token, Session-ID oder Auth-Credentials - das was den Befugten vom Unbefugten unterscheidet"

Zitat von oneside

Was meinst du mit sensiblem Datum?

Datum ist der Singular von Daten.
Sensible Daten sind solche, die nicht in falsche Hände geraten dürfen.

Ein sensibles Datum ist z.B. das Passwort eines Emailpostfachs, die private Handynummer von Frau Merkel oder die Kombination für dein Fahrradzahlenschloss.

Bleiben wir mal bei dem letzten Beispiel, dem Zahlenschloss. Wenn ich die Kombination erfahre, klaue ich dir dein Fahrrad.
Spätestens jetzt wird dir auch klar, wie viel die Information (= die Zahlenkombination, das "Datum") mindestens wert war.
Durch böswillige Handlung kann ich deinen Verlust aber noch steigern. Ich könnte dein Rad aus dem 3. Stock auf einen teuren Porsche fallen lassen. Die Polizei wird das Rad zu dir zurückverfolgen und dann wirds teuer für dich! Spätestens jetzt wird dir klar, dass du in Zukunft vorsichtiger (sensibler) mit deiner Zahlenschlosskombination (Daten) umgehen musst.

SSL will ich eigentlich nicht einsetzen, weil die Daten die übertragen werden keine wirklich sensiblen Daten sind. Durch die Autentifizierung will ich nur verhindern, dass unbefugte die Schnittstelle nutzen können.

Da werden also Authentifizierungsdaten übertragen. Die sind sensibel! Also solltest du doch SSL einsetzen.

Ich hoffe nun ist klar was ich sagen wollte.

Einfach toll, du solltest für die Sendung mit der Maus schreiben

Zitat von onemorenerd

Da werden also Authentifizierungsdaten übertragen. Die sind sensibel! Also solltest du doch SSL einsetzen

Wenn lediglich die Authentifizierungsdaten, jedoch nicht die Payload sensibel sind, ist das UT schon ein ganz brauchbares Verfahren.

Ich hab die genaue Implementierung von UT nicht mehr im Kopf aber ich glaub es läuft ungefährt so ab:

Clientseitig wird ein Hash aus dem Passwort, Datum-Zeit und einer Zufallszahl erzeugt. An den Server wird der Hash, sowie das verwendete Datum-Zeit und die Zufallszahl übertragen - nicht jedoch das Passwort selbst.

Der Server prüft dann zunächst ob Datum-Zeit innerhalb einer bestimmten Toleranz liegt (Datum-Zeit von gestern wird z.B. von vornherein ungültig), danach wird aus den übermittelten Datum-Zeit und Zufallszahl zusammen mit dem Server bekannten Passwort der Hash erzeugt und mit dem übergebenen verglichen.

Stimmt alles zusammen wird noch überprüft, ob die Daten bereits innerhalb der erlaubten Zeitspanne verwendet wurden - wenn nicht, wird die Anfrage durchgewunken, falls doch kann davon ausgegangen werden, dass der Traffic abgehört wurde und versucht wurde mit den Daten eine weitere Anfrage zu starten - also Ende.

Es muss aber klar sein, dass ohne SSL die transportierten Daten für jedermann lesbar bleiben - es kommt also stark auf die Anwendung an, ob man auf SSL vielleicht grad noch verzichten kann.

Zitat von Quetschi

Wenn lediglich die Authentifizierungsdaten, jedoch nicht die Payload sensibel sind, ist das UT schon ein ganz brauchbares Verfahren.

Ich kenne UT nicht, aber wenn es über HTTP läuft, muss in der Anfrage irgendwas drin sein, um die Zustandslosigkeit von HTTP zu überwinden. Ich nenne es jetzt der Einfachheit halber mal das Token
Der Server weiß, dass eine Anfrage mit diesem Token berechtigt ist, führt sie aus und schickt die Antwort zurück. So hast du es ja gerade beschrieben.

Zitat von Quetschi

Stimmt alles zusammen wird noch überprüft, ob die Daten bereits innerhalb der erlaubten Zeitspanne verwendet wurden - wenn nicht (Anm.: also wenn das Token gültig ist), wird die Anfrage durchgewunken

Sollte ein Angreife in den Besitz des Token kommen, kann er die Anfrage manipulieren oder zumindest man in the middle sein und die Antwort mitlesen.
Läuft die ganze Kommunikation über SSL, ist das ausgeschlossen.

Jetzt noch einmal das Zitat vom TO, um das es geht:

SSL will ich eigentlich nicht einsetzen, weil die Daten die übertragen werden keine wirklich sensiblen Daten sind. Durch die Autentifizierung will ich nur verhindern, dass unbefugte die Schnittstelle nutzen können.

Wie eben dargestellt kann ohne SSL eben nicht verhindert werden, dass Unbefugte die Schnittstelle nutzen. Sie könnten nämlich ein Token abfangen oder die Nutzung eines Befugten belauschen oder sogar manipulieren.

Um es mal weniger technisch aufzurollen: Die Anforderung lautet "will ich nur verhindern, dass unbefugte die Schnittstelle nutzen können". Der TO glaubt, das "durch die Autentifizierung" erreichen zu können. Das ist ein Irrglaube! Wer das nicht einsieht, soll mir mal eine Bank zeigen, die Online-Banking mit Authentifizierung ohne SSL betreibt.

Zitat von onemorenerd

Sollte ein Angreife in den Besitz des Token kommen, kann er die Anfrage manipulieren oder zumindest man in the middle sein und die Antwort mitlesen.

Dazu müsste er die ursprüngliche Client-Anfrage vorm Server abfangen und (schnell) manipulieren, da das Token nur einmalig und zeitlich begrenzt gültig ist. Das mitlesen der Antwort ist dann freilich eine andere Geschichte.

Hallo und vielen Dank für die ganzen Infos.

Ich habe das zwischenzeitlich ungefair so gelöst, wie Quetschi mit dem Token beschrieben hat.

Ich erstelle einen Token aus einem nicht zu übermittelnden (also geheimen) Schlüssel, der TextID und einem Zeitstempel. Den erzeugten Token, den Zeitstempel und die TextID übermittel ich beim Api Aufruf mit. Die Api reproduziert den Token, prüft dann, ob der Token echt ist und ob die Zeitspanne noch innerhalb X liegt.

Die Situation ist vereinfacht diese:

Die API soll dafür genutzt werden soll, um Texte aus einer Datenbank auslesen zu können. Diese Texte sind sowieso öffentlich auf einer Webseite, also keine wirklich sensiblen Daten.

Mit dem Aufruf der Api wird eine ID übergeben und man bekommt dann einen Text zu dieser zurückgeliefert. Pro Aufruf kann nur ein Text ausgelesen werden.

Wenn jemand also den Token bzw die Parameter abfängt, kann er höchstens den Text abfangen/auslesen, der gerade angefordert wurde. Klaut also jemand den Token, kann er nur für eine minimale Zeitspanne einen einzelnen Text abfangen. Da könnte er sich auch einfach den Text von der Website kopieren und so klauen...

Verhindern will ich lediglich, dass jemand einfach die übermittelte TextID in den abgefangenen Parametern ändern kann und dann jeden beliebigen Text durch ändern der TextID auslesen kann.

Gruß
Oneside

Zitat von oneside

Diese Texte sind sowieso öffentlich auf einer Webseite [...]. Da könnte er sich auch einfach den Text von der Website kopieren und so klauen...

Welche Aufgabe hat dann die API? Sowas wie ein "Witz des Tages"- oder Zitat-Server?