[AJAX/JS] Wie kaufmännisches "und" an PHP-Datei übergeben?

[Matze]

Hallo,

ich übergebe wie folgt einen längeren Text an eine PHP-Datei (Shoutbox):

Code:

my_ajax.requestFile = serverFileSubmit + '?page=sb&msg=' + encodeURI(message);

Das geht soweit ganz gut, nur wenn ein "&" in "message" enthalten ist, wird alles danach nicht mit übernommen bzw. ich denke, es wird als eigenen GET-Parameter ausgewertet. Ich könnte natürlich vor der Übergabe an das PHP-Skript die &-Zeichen ersetzen und dies in der PHP-Datei rückgängig zu machen, doch das finde ich sehr unschön.

Wie macht man dies ordentlich?

Grüße, Matze

[DeddyH]

Hast Du es mal mit urlencode() versucht?

[Matze]

Hallo Detlef!

Ich kenne urlencode() nur als PHP-Funktion.

Grüße

[Valle]

GET ist ganz schlecht! Für möglichst alle Daten, die andere Daten verändern sollte man Post nehmen. Das enthält neue Daten (Shoutboxen), löschen von Daten (Löschen in der Shoutbox) und alles andere. Grund ist die Sicherheit. Genannt wird der Vorgang des Ausnutzen der Sicherheitslücke CSRF. Einfache Erklärung:

Ein User im Forum macht in seine Signatur folgenden Code:

Code:

[img]http://www.example.com/index.php?delete_user=1[/img]

Sobald der Administrator (Der User mit der ID 1 in dem Fall) einen Post von diesen User sieht, versucht der Browser dessen Bild in seiner Signatur zu laden. Auch wenn es sich dann dabei nicht um ein Bild handelt, so wird diese Webseite trotzdem unter den Rechten des Administrators ausgeführt. Und er löscht sich selbst. ;-)

Hope it helps! :-)

Edit:// Zusätzlich muss man sagen, dass GET auch nur eine begrenzte Länge hat. Ich bin mir aber nicht ganz sicher wie groß diese ist. Für eine Shoutbox sollte es aber eigentlich reichen. ... Aber wie gesagt. Besser nicht.

Mit freundlichen Grüßen,

Valle

[Matze]

Hallo!

Also das ist Quatsch, sorry. Es ist ja nicht so, dass die Daten willkürlich weiterverarbeitet werden, sondern Berechtigungen werden in der PHP-Datei ordentlich geprüft. Und GET ist nicht unsicherer als POST, da man problemlos auch POST-Daten an eine URL senden kann.

Grüße

Edit: Ich habe mal was von 3000 Zeichen gelesen und das reicht mir.

[Valle]

Zitat:

Zitat von Matze

Hallo!

Also das ist Quatsch, sorry. Es ist ja nicht so, dass die Daten willkürlich weiterverarbeitet werden, sondern Berechtigungen werden in der PHP-Datei ordentlich geprüft. Und GET ist nicht unsicherer als POST, da man problemlos auch POST-Daten an eine URL senden kann.

Grüße

Edit: Ich habe mal was von 3000 Zeichen gelesen und das reicht mir.

Natürlich werden die Berechtigungen geprüft. Aber was bringt das, wenn der Administrator diesen Link ungewollt aufruft? Der hat doch mit Sicherheit das Recht dazu. In diesem Fall hat man zwar lediglich die Möglichkeit Posts in der Shoutbox als ein beliebiger User (u.U.) zu schreiben, aber das ist auch nicht schön.

Klar ist POST auch zu fälschen. Allerdings ist das nochmal eine andere Sache als mit GET. Ansonsten eben einen Shared Key benutzen. Dann hast du auch das Problem nicht mehr. Meiner Meinung nach ist es zumindest ein wenig sicherer, direkt POST zu benutzen. Ich mein's doch nur gut. ;-)

Mit freundlichen Grüßen,

Valle

[Matze]

Hallo

Zitat:

Zitat von Valle

Der hat doch mit Sicherheit das Recht dazu. In diesem Fall hat man zwar lediglich die Möglichkeit Posts in der Shoutbox als ein beliebiger User (u.U.) zu schreiben, aber das ist auch nicht schön.

Nein das geht auch dann nicht, denn in der PHP-Datei wird die Sitzung geprüft und somit der aktuell angemeldete Benutzer ermittelt. Es ist also nicht möglich unter anderem Namen zu posten, egal welche Rechte der jeweilige Benutzer hat.

Ich weiß, dass du es nett meinst, aber in Sachen Sicherheit bin ich so verantwortungsbewusst wie nur möglich. Gut, Fehler kann man nie ausschließen, aber solche grob fahrlässigen Dinge mache ich (normalerweise) nicht. ;)

Grüße

Edit: Übrigens geht es mit AJAX gar nicht anders als über GET/POST.

[Valle]

Zitat:

Zitat von Matze

Nein das geht auch dann nicht, denn in der PHP-Datei wird die Sitzung geprüft und somit der aktuell angemeldete Benutzer ermittelt. Es ist also nicht möglich unter anderem Namen zu posten, egal welche Rechte der jeweilige Benutzer hat.

Ich verstehe das Argument nicht. Ich glaube aber du verstehst auch meins nicht. :mrgreen: Also pass auf. Stell dir vor, du bist in deinem Forum angemeldet und surfst in den Threads rum. Jetzt hat jemand in seiner Signatur (Versteckt als "Bild") einen Link wie oben angegeben. Jetzt ruft dein Browser diese Seite auf - und zwar mit deiner Session und somit auch mit deinen Rechten! Und wenn er in diesem Link einfach per GET einen neuen Shoutbox-Eintrag anlegt, dann wird dieser natürlich auch mit deinem Namen versehen. Die ganze Sache ist natürlich mit gewissem Aufwand verbunden, aber es ist möglich!

Zitat:

Zitat von Matze

Ich weiß, dass du es nett meinst, aber in Sachen Sicherheit bin ich so verantwortungsbewusst wie nur möglich. Gut, Fehler kann man nie ausschließen, aber solche grob fahrlässigen Dinge mache ich (normalerweise) nicht. ;)

Ich versuche das eigentlich auch, aber es gibt ja so viele Dinge, auf die man achten muss...

Mit freundlichen Grüßen,

Valle

[Matze]

Zitat:

Zitat von Valle

[...] - und zwar mit deiner Session und somit auch mit deinen Rechten!

Niemals. Meine Session ist meine und da kommt so leicht keiner außer mir ran. In der Hinsicht bin ich wirklich egoistisch. :mrgreen:

[alcaeus]

Moin,

ich misch mich ganz kurz ein:

Zitat:

Zitat von Valle

Ein User im Forum macht in seine Signatur folgenden Code:

Code:

[img]http://www.example.com/index.php?delete_user=1[/img]

Sobald der Administrator (Der User mit der ID 1 in dem Fall) einen Post von diesen User sieht, versucht der Browser dessen Bild in seiner Signatur zu laden. Auch wenn es sich dann dabei nicht um ein Bild handelt, so wird diese Webseite trotzdem unter den Rechten des Administrators ausgeführt. Und er löscht sich selbst. ;-)

Sorry, aber da ist der Programmierer selbst schuld. Ein POST allein ist keine Loesung, wenn ich nicht validiere hab ich immer noch die Luecke. Ein Beispiel: der Logout im phpBB funktioniert ueber GET, damit er ueber einen Link aufgerufen werden kann. Wenn ich jetzt also die URL

Code:

http://www.delphipraxis.net/login.php?logout=true

einbetten wuerde, waere der User automatisch ausgeloggt. Aus dem Grund wird einerseits das Fragezeichen als Trennzeichen zwischen URL und Parametern blockiert, zusaetzlich wird beim Logout auch die korrekte SID verlangt (guck dir einfach den Logout-Link an, dann wirst du sehn was ich meine). Das reicht schon um das Script abzusichern, und zwar ohne eine laestige Nachfrage "willst du dich wirklich ausloggen" und ohne laestigen POST-Request.

That said, fuer bestimmte Dinge hat er natuerlich Recht. Wenn du alle Parameter in die URL reinwirfst, hast du spaetestens bei den Serverlogs ein Problem. Die Parameter werden naemlich mitgeloggt, wenn sie ueber GET reinkommen; wenn sie ueber POST kommen werden sie nicht geloggt. Das ist einerseits wichtig, um Passwoerter nicht zu kompromittieren, andererseits haelt es auch die Logfiles klein. Stell dir vor jeder Beitrag in der DP wuerde ueber GET reingehn, die Logfiles waeren uebelst gross.

Um auch eine sinnvolle Antwort zu geben: du verwendest encodeURI(). Guck in selfHTML einfach mal ein Kapitel tiefer auf encodeURIComponent() und du wirst feststellen, dass die Funktion auch das &-Zeichen kodiert, was encodeURI nicht macht.
encodeURI wird verwendet, um eine komplette URI zu escapen, und die Parameter dabei heile bleiben sollen. encodeURIComponent wird verwendet, um einen einzelnen Parameter so zu escapen, dass ein &-Zeichen keinen Schaden mehr anrichten kann.

Greetz
alcaeus

[add]

Zitat:

Zitat von Matze

Zitat:

Zitat von Valle

[...] - und zwar mit deiner Session und somit auch mit deinen Rechten!

Niemals. Meine Session ist meine und da kommt so leicht keiner außer mir ran. In der Hinsicht bin ich wirklich egoistisch. :mrgreen:

Sag das nicht zu laut - es gibt einen Grund warum bei Attachments das Download-Fenster kommt (um olle Kamellen aufzuwaermen). Du willst nicht dass ich dir ein Beispiel liefere.[/add]