[AJAX] Worauf muss ich achten?

[Matze]

Hallo,

ich spiele gerade mit AJAX herum und spontan fallen mir 2 Dinge ein, über die ich gerne mehr erfahren würde:

Muss ich die JS-Dateien irgendwie speziell "sichern", um Sicherheitslücken zu vermeiden?
Ich kann mir momentan nicht vorstellen, dass man damit groß was anrichten kann, da alles auf der Clientseite abläuft, doch ich möchte lieber nochmals nachfragen. Beispielsweise gebe ich HTML-Code mittels JS aus und könnte mir vorstellen, dass man die XML-Antwort von PHP manipulieren könnte.

Da wären wir auch beim 2. Anliegen: Nehmen wir an, ich habe eine AJAX-Shoutbox.
Nun sollen berechtigte Personen einen Link zum Löschen von Einträgen bekommen. Diesen Link muss ich dann natürlich auch mit JS ausgeben. Da weiß ich nicht genau, wie man vorgehen soll. Ich es sinnvoll, ein XML-Item zurückzugeben, das den Lösch-Link enthält?

Das Problem wäre, wenn sich die XML-Daten - wie oben erwähnt - manipulieren ließen, dass dann das Skript generell das ausgibt, was im entsprechenden XML-Item steht. Ob das nun von meiner PHP-Datei kommt oder nicht, wäre prinzipiell egal, denn JS weiß das ja nicht.
Dass ich im PHP-Skript, das die Einträge löscht, eine Berechtigungs-Überprüfung benötige, ist mir klar.

Grüße, Matze

[Khabarakh]

Zitat von Matze:

Dass ich im PHP-Skript, das die Einträge löscht, eine Berechtigungs-Überprüfung benötige, ist mir klar.

Gut, aber was ist dann die Frage ? Dass jemand die Antwort vom Server an den Client manipulieren könnte? Ich sehe nicht, wie das bei AJAX ein größeres Problem sein sollte als bei statischem HTML . Wenn ein Dritter deinen Server perfekt simuliert, bist du wohl mit jeder Technologie chancenlos. Und solange nur der User und nicht dein Server angegriffen wird... .

Zitat von Matze:

Ich es sinnvoll, ein XML-Item zurückzugeben, das den Lösch-Link enthält?

Könntest du ihn nicht direkt in HTML-Code für die Shouts einbetten? Wenn die serverseitige Validierung stimmt, lässt sich damit kein Schabernack treiben.

[Phoenix]

Nein, du brauchst das AJAX-Script nicht nochmal zu sichern, sofern Du folgende Regel beachtest:

Ausnahmslos alles, was vom Client kommt, ist böse.

Du musst sowieso jede Eingabe, auch wenn Du die schon durch ein Javascript geprüft hast, nochmal vom Server validieren lassen bevor Du sie verarbeitest. Der User kann nämlich a) ganz einfach Javascript deaktiviert haben. Dann fand auf Clientseite erst gar keine Überprüfung statt. Oder b) (worst case) deine Javascript Funktionen mit Hausmitteln (Firefox + Firebug) zur Laufzeit im Browser beliebig ändern und auch deinen Ajax-Aufrufen beliebige Payloads mitgeben, die der Server so gar nicht erwartet oder noch schlimmer: beliebige Daten unterjubeln.

Das geht übrigens in beide Richtungen: Der User kann nicht nur dein JS dazu benutzen, beliebige Daten an den Server zu schicken - er kann auch alle Daten die vom Server kommen vorher durch sein eigenes JS schleusen, beliebig ändern und dann erst an Dein Script übergeben. Oder es auch gleich ganz sein lassen und nur selber handeln.

Der Punkt ist: Ist Dein Javascript einmal an den Client übertragen, sind das Script selber und die Daten die es verarbeitet prinzipiell nicht mehr vetrauenswürdig.

Zu dem Löschen-Button:
Beim Löschen - das hattest Du ja schon angesprochen - wird die Berechtigung Serverseitig nochmal geprüft.

Von daher handhabe ich es so: In AJAX ist letzlich alles erlaubt / richtig, sofern es dem großen Ziel dient: Die Seite für den Benutzer besser bedienbar / schneller / eleganter zu machen bzw. übertragene Datenmengen / Roundtrips möglichst klein zu halten.

Wie Du dieses Ziel erreichst ist letzlich egal. Du kannst den Link zum löschen gleich mit im html rausrendern wenn der User berechtigt ist, oder den erst später via asynchronem Aufruf an den Client übertragen und dann anzeigen. Du kannst ihn auch immer unsichtbar mit rausrendern und nur durch JS anzeigen, wenn es Sinnvoll ist.

Mach es einfach so, wie es für den User am konfortabelsten / schnellsten ist (also auch die dafür übertragene Datenmenge mit beachten - bei einem Link ist es ggf. im Schnitt weniger Traffic, den IMMER gleich unsichtbar in die Seite zu rendern als bei berechtigten Usern dann nochmal den SOAP-Header und extra XML drum zu packen).

Ansonsten gilt bei AJAX: Function follows form. Du machst das Gedöns schliesslich nur, um den User zu betüdeln damit sich Deine Seite für ihn besser 'anfühlt', nicht aus reinem Selbstzweck dass Du AJAX einsetzt.

Und da Du selbst Deinem eigenem Script nicht trauen kannst wenn es einmal beim (böswilligen) User ist, ist es auch vollkommen unnötig, viel Arbeit in die Absicherung von etwas zu stecken, was per se nicht Absicherbar ist. Also mach es einfach so, wie es am elegantesten oder auch nur am einfachsten ist, solange es seinen Zweck erfüllt.

[Daniel]

Ich würde es clientseititg jedoch noch soweit absichern, dass es wenigstens grob in der Lage ist, valide Daten zu erkennen und ggf. eine Fehlermeldung auszuwerfen. Das ist allerdings "nur" ein Aspekt, der in die Usability reinreicht und nichts mit der Sicherheit zutun hat.

[Matze]

Hi,

danke für die Antworten. Dann muss ich mir vermutlich keine Sorgen machen. PHP verarbeitet die eingegebenen Daten und dort prüfe ich auf gültige IDs und ähnliches. Da ich bisher nur zum Testen mit AJAX herumgespielt habe, war ich mir nicht sicher, worauf man genau achten muss.

Ich habe nur den Hinweis bekommen, dass es möglich wäre, Cookies mit JS auszulesen oder sowas. Das hat mich dann letztenendes auch dazu veranlasst, hier zu fragen.

@Daniel: Das könnte ich natürlich machen. Aktuell übergebe ich die eingegebenen Daten direkt an PHP und kann dort zuverlässig prüfen. Aber mal schauen, ob ich durch Fehleingaben unschöne Meldungen erreichen kann.

Grüße