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

[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