[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]

[Valle]

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:

:gruebel:

Wie machst du das? Woran merkt deine Webseite, ob du den Link selbst angegklickt hast und das Formular auch selbst ausgefüllt hast, oder ob dein Browser nur den Link in der Signatur eines anderen laden wollte und die Formular-Daten von ihm stammen aber von dir abgesendet wurden? Und komm mir nicht mit Referer! :zwinker:

Edit://

Zitat:

Zitat von alcaeus

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.

Ich habe nicht behauptet, dass POST die Lösung ist! Aber ich bin mir recht sicher, dass Post auf jeden Fall besser ist als GET. Es ist meiner Meinung nach schwerer auszunutzen und hat auch diverse andere Vorteile gegenüber GET, zum Beispiel das mit den Logfiles.

Das mit dem Logout ist mir bekannt, habe ich auch so auf meiner Webseite.

Mit freundlichen Grüßen,

Valle

[Matze]

Wie ich das mache? Na ich übergebe die Session nicht als Parameter, da wäre ich ja schön doof. ;)
Das Session-System funktioniert wie eigentlich die meisten über Cookies und diverse Session-Einträge in der Datenbank.

[alcaeus]

Moin,

Zitat:

Zitat von Matze

Wie ich das mache? Na ich übergebe die Session nicht als Parameter, da wäre ich ja schön doof. ;)
Das Session-System funktioniert wie eigentlich die meisten über Cookies und diverse Session-Einträge in der Datenbank.

sei dir da mal nicht so sicher. Du hasst ein Session-Cookie fuer www.foobar.com. Das Script /delete_user.php prueft, ob eine Session gueltig ist, und ob auch die Berechtigungen vorhanden sind. Das verhindert, dass ich (ohne gueltiges Session-Cookie) einen User loeschen kann. Ich kann dir aber immer noch die URL unterjubeln, z.B. als Bild in einem BBCode, wenn du die nicht gruendlich abgesichert hast. Der Browser sieht dann, dass er die Seite www.foobar.com/delete_user.php aufrufen soll, und schickt bei der Gelegenheit auch das Cookie mit, das er hat. Nachdem es dein Browser ist, schickt er dein Cookie mit. Das Script sieht also dass ein Cookie da ist, sieht dass die Berechtigungen passen und loescht munter darauf los.

Klar hat dieses Beispiel mehr Angriffsflaeche als ein U-Boot das an der Oberflaeche schwimmt. Es soll aber nur zeigen, dass man nichts ausser acht lassen darf. BTW, Sicherheit kommt nicht davon, zu wissen dass man auf Sicherheit achtet. Behandle deine Scripte wie Sicherheitsloecher, die darauf warten dass jemand mit ihnen spielt. Der Moment wird schliesslich kommen - XSS und CSRF sind keine Seltenheiten, sondern fast allgegenwaertig. Im phpBB gibts z.B. den Fall, dass man mit nem Avatar ne Sauerei anstellen kann, wenn ein paar Variablen erfuellt sind. Ist zwar nicht immer der Fall, aber frueher oder spaeter kann jemand in die Falle tappen, und dann ist die kacke am Dampfen ;)

Greetz
alcaeus

[Valle]

Zitat:

Zitat von Matze

Wie ich das mache? Na ich übergebe die Session nicht als Parameter, da wäre ich ja schön doof. ;)
Das Session-System funktioniert wie eigentlich die meisten über Cookies und diverse Session-Einträge in der Datenbank.

Ja und? Schließlich ist es doch dein Browser, der den Link in der Signatur des anderes aufruft. Der sendet doch deine Login-Daten mit (Auch per Cookie). Woher soll der Browser denn wissen, dass die GET-Daten in diesem Link nicht von dir gewollt sind? Ich habe mein Login-System sofern ich das herauslesen kann genauso gestaltet wie du, also auch per Cookie. Meine Webseite ist da auch nicht generell gegen geschützt.

Edit:// So, jetzt kann ich auch mal den roten Kasten anschnauzen. Hab deinen Post nicht gesehen, alcaeus. Letztendlich sehe ich das ja genau so. :cyclops:

Mit freundlichen Grüßen,

Valle

[Matze]

Ach das meinst du! Ich dachte dass andere das verursachen können sollen, ohne dass ich die Seite aufrufe. Dann hatte ich dich falsch verstanden.

Das Problem hat man jedoch immer, ob das nun ein Link von einem Forum ist oder sonst einer. Wie sollte man sowas auch verhindern? Per POST-Parameter? Gut, das würde hier geeignetersein als GET, richtig. Nur wie man das mit AJAX macht, müsste ich erstmal schauen. Auf jedenfall danke für den Hinweis. :)

Aber mal zur Ausgangsfrage: Wie geht das denn nun?

Grüße

[alcaeus]

Moin,

Zitat:

Zitat von Matze

Aber mal zur Ausgangsfrage: Wie geht das denn nun?

hab ich doch bereits gesagt:

Zitat:

Zitat von alcaeus

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

[Matze]

Hi Andy,

ich habe deinen ersten Beitrag komplett übersehen. :oops: Danke.

Grüße