Datensätze aus einem CMS löschen / bearbeiten

[markusfroehlich]

Hallo Leute!

Ich habe folgendes Problem.

Ich hab mir ein CMS gebaut mit dem ich z.B News, Termine, usw. verwalte.
Die Datensätze der jeweiligen Items zeige ich als Tabelle an.

z.B.: News Verwaltung

News 1 löschen | bearbeiten
News 2 löschen | bearbeiten

Wobei löschen | bearbeiten bei mir 2 Icons (Bilder) sind.

Nun zu meinem Problem.

die beiden Icons die ich zum löschen/bearbeiten verwende,
übergeben über Get, 2 Steuervariablen und sind Links:

Beispiel:

Löschen:
index.php?act=delete&id=21

Bearbeiten:
index.php?act=edit&id=21

Wenn man draufklickt wird der Datensatz brav gelöscht, aber man sieht
in der Browseradressleiste die übergebenen Variablen, da sie ja mit Get übergeben werden.

Irgendwie ist es aber nicht konfortabel wenn ein Benutzer die Steuervariablen sieht
bzw. zugriff darauf hat, da er sie einfach in der Leiste ändern oder refreshen kann.

Eine Möglichkeit wäre auch für jedes löschen | bearbeiten ein eigenes Formular erzeugen lassen,
dass die Id im Hintergrund per hidden speichert und die Variablen dann per Post verschickt.

Nachteil bei diese Methode:

• Generierter Code wird 4x so lang
• Formularbuttons müssen dann per Css zu Icons gemacht werden

Ausserdem habe ich gehört das, dass versenden per Post auch nicht gerade sicherer ist als mit Get.

Wie macht ma dies am besten / sichersten, hab schon viel in Foren nachgeschaut
aber nicht wirklich was brauchbares gefunden.

Wie lößt ihr das?

[Felix Riesterer]

Lieber markusfroehlich,

index.php?act=delete&id=21
[...]
Irgendwie ist es aber nicht konfortabel wenn ein Benutzer die Steuervariablen sieht
bzw. zugriff darauf hat, da er sie einfach in der Leiste ändern oder refreshen kann.

wenn Dich dieses rein kosmetische Problem stört, dann encodiere den kompletten Search-String z.B. nach Base64 und schon kann kein User mehr sehen, was da tatsächlich steht. Das Ergebnis könnte dann z.B. so aussehen:

index.php?YWN0PWRlbGV0ZSZpZD0yMQ==

Du müsstest halt prüfen, ob $_SERVER["QUERY_STRING"] irgendwie nach Base64 decodiert noch einen Sinn ergibt und dann immer dieses Ergebnis benutzen, anstatt den originalen Inhalt von $_GET...

Liebe Grüße,

Felix Riesterer.

[suit]

wenn Dich dieses rein kosmetische Problem stört, dann encodiere den kompletten Search-String z.B. nach Base64 und schon kann kein User mehr sehen, was da tatsächlich steht. Das Ergebnis könnte dann z.B. so aussehen:

index.php?YWN0PWRlbGV0ZSZpZD0yMQ==

Du müsstest halt prüfen, ob $_SERVER["QUERY_STRING"] irgendwie nach Base64 decodiert noch einen Sinn ergibt und dann immer dieses Ergebnis benutzen, anstatt den originalen Inhalt von $_GET...

Gehts dir heute nicht gut?

security-through-obscurity-FAIL

[Felix Riesterer]

Lieber suit,

Gehts dir heute nicht gut?

schlecht geschlafen (und zu wenig). Warum?

security-through-obscurity-FAIL

Habe ich etwas von Security geschrieben? Ich sprach von Kosmetik! Die Sicherheit muss an ganz anderer Stelle geleistet werden.

Liebe Grüße,

Felix Riesterer.

[suit]

Habe ich etwas von Security geschrieben?

Nein, aber du hast es unterlassen, darauf hinzuweisen ;)

Ich sprach von Kosmetik!

Hmm - ich stell mir grade vor, wie ein plastischer Chirurg einen Mixstab im Gesicht ansetzt und sagt "ach, ist doch nur Kosmetik" :p

index.php?act=delete&id=21

index.php?YWN0PWRlbGV0ZSZpZD0yMQ==

[suit]

Nachteil bei diese Methode:

• Generierter Code wird 4x so lang

Ja.

• Formularbuttons müssen dann per Css zu Icons gemacht werden

Kein Problem, ein paar Zeilen.

Wenn du schon mit GET arbeiten willst, kannst du die Adresszeile auch mit einem (i)frame verschleiern.

Ausserdem habe ich gehört das, dass versenden per Post auch nicht gerade sicherer ist als mit Get.

Richtig, es ist absolut gleichwertig, POST ist lediglich nicht so offensichtlicht.

Ein HEAD-Request würde aber auch ausreichen - POST oder GET sind nicht immer notwendig.

Wie macht ma dies am besten / sichersten, hab schon viel in Foren nachgeschaut
aber nicht wirklich was brauchbares gefunden.

Traue niemandem - prüfe im Edit- oder im Löschscript immer ob die Daten wie sie angekommen sind auch passen und ob der Absender auch die richtigen Rechte hat.

[markusfroehlich]

Danke für eure Antworten.

Wie meinst du das genau mit dem Head Request?

Die Daten selber prüfe ich in meinen Scripten eh nochmal auf rechte unsw.

Danke

lg Markus

[suit]

Wie meinst du das genau mit dem Head Request?

Wenn du die Löschaktion z.B. per AJAX ausführst kannst du anstatt GET oder POST auch einen HEAD-Request verwenden und die Response-Header auswerten anstatt einen Batzen an Zeug mitzuschicken den du nicht brauchst.

Die Daten selber prüfe ich in meinen Scripten eh nochmal auf rechte unsw.

Dann ist ja gut.

[dedlfix]

Hi!

Wobei löschen | bearbeiten bei mir 2 Icons (Bilder) sind.
die beiden Icons die ich zum löschen/bearbeiten verwende,
übergeben über Get, 2 Steuervariablen und sind Links:

Und was ist, wenn der Suchmaschinenspider vorbeikommt und mal eben allen Links folgt? Daten-ändernde Aktionen sollten immer mit POST bearbeitet werden, das ist in der Regel Linkchecker/Spider-fest.

Wie macht ma dies am besten / sichersten, hab schon viel in Foren nachgeschaut aber nicht wirklich was brauchbares gefunden.

Sicherheit ist hier nicht die Frage sondern eher Autorisation. Wer löschen darf muss sich vorher angemeldet haben und die Berechtigung dazu haben. Alle Löschversuche - egal in welchem Stadium (siehe nachfolgend zweite Möglichkeit) - sind auf die notwendige Berechtigung zu prüfen.

Wie lößt ihr das?

Kommt drauf an. Kreuzchenfelder wäre eine Möglichkeit, wenn mehrere Daten gelöscht werden können sollen. Eine andere ist, die Icons als Link zu lassen und ein per POST abzusendendes Bestätiungsformular anzuzeigen. Die Icons werden natürlich ohne Berechtigung nicht angezeigt oder zumindest deaktiviert.

Lo!

[fastix®]

Moin!

Löschen:
index.php?act=delete&id=21

Bearbeiten:
index.php?act=edit&id=21

Ich wüsste jetzt gerne mal was eigentlich so wertvoll daran ist solche großen "eierlegenden Wollmilchsau-Skripte" "index.php" zu schreiben. Warum nicht loscheArtikel.php und editArtikel.php? Kleinere Skripte lassen sich viel besser pflegen und werden auch schneller compiliert/ausgeführt, eben weil sie klein, leicht und übersichtlich sind. Das wieder bedeutet: Weniger Fehler, weniger Änderungsbedarf, weniger Aufwand und nicht zu Letzt Code der noch besser wiederverwendbar ist.

Wenn man draufklickt wird der Datensatz brav gelöscht, aber man sieht
in der Browseradressleiste die übergebenen Variablen, da sie ja mit Get übergeben werden.

Na und? Die Artikel werden von einer berechtigten Person bearbeitet und die wird sich kaum wegen des Mangels an Schönheit in der URL beschweren.

Irgendwie ist es aber nicht konfortabel wenn ein Benutzer die Steuervariablen sieht
bzw. zugriff darauf hat, da er sie einfach in der Leiste ändern oder refreshen kann.

Na und? Bei vernünfigen Shells kann man (Windows soll es ja jetzt auch können) auch in der Befehlshistorie blättern und Befehle wiederholen oder abändern und dann ausführen. Ich sehe darin kein Problem. Jedenfalls nicht so lange wie Artikel Nr. 27 nicht gelöscht wird, dann ein neuer Artikel die Nummer 27 bekommt und dieser durch ein Neuladen der Seite loescheArtikel.php?id=21 dann gelöscht wird. Also bekommt ein neuer Artikel immer eine neue Nummer.

Zu dem Überprüfen der Berechtigungen hat dedlfix schon alles gesagt.

Wie lößt ihr das?

Ich habe das erste Augenmerk auf Sicherheit und Bedienbarkeit. Die Schönheit der angezeigten URLs kümmert mich jedenfalls im "Adminland" gar nicht.

MFFG (Mit freundlich- friedfertigem Grinsen)

fastix

[Felix Riesterer]

Lieber fastix®,

Ich wüsste jetzt gerne mal was eigentlich so wertvoll daran ist solche großen "eierlegenden Wollmilchsau-Skripte" "index.php" zu schreiben.

also in meinem Falle ist es index.php, welches so wertvolle Scripts wie "loescheArtikel.script.inc" bei bedarf required. Und da ich mod_rewrite einsetze, werden eben alle Anfragen auf dieses zentrale Script umgeleitet.

Mir ist schon klar, dass es andere und vielleicht elegantere Methoden gibt, aber alleine das Vorhandensein von "index.php" garantiert noch lange nicht, dass dieses Script eine monströse eierlegende Wollmilchsau ist!

Liebe Grüße,

Felix Riesterer.

[markusfroehlich]

index.php ist bei mir auch zentral aufgebaut.

Meine Scripte wie "lösche News" sind auch extern und werden bei bedarf dann in index.php includiert

ist auch einfach zu warten und funkt bestens

[dedlfix]

Hi!

Ich wüsste jetzt gerne mal was eigentlich so wertvoll daran ist solche großen "eierlegenden Wollmilchsau-Skripte" "index.php" zu schreiben.

Es ist nicht gesagt, dass das immer eierlegende Wollmichsau-Scripte sind. Die besseren werden einen FrontController darstellen, der allgemeine Initialisierungsaufgaben erledigt und dann die eigentliche Arbeit an spezialisierte Programmteile delegiert.

Warum nicht loscheArtikel.php und editArtikel.php?

Auch das ist möglich, nur dass hier in jede Datei das Common-Script oder auch mehrere inkludiert werden muss, um Codewiederholungen bei der Initialisierung zu vermeiden.

Kleinere Skripte lassen sich viel besser pflegen und werden auch schneller compiliert/ausgeführt, eben weil sie klein, leicht und übersichtlich sind.

Pflegeleicht ist das Hauptargument. Schneller compiliert bekommt man mit einem Op-Code-Cache hin. Mit schnellerer Ausführung hat das aber nichts zu tun, denn da kommt ja nur der Code dran, der tatsächlich durchlaufen wird. Da nehmen sich beide Methoden nichts, wenn man nicht einen gravierenden Fehler eingebaut hat. Code der nur rumliegt frisst zur Laufzeit keine solche.

[...] Code der noch besser wiederverwendbar ist.

Wenn er denn immer so abstrakt geschrieben wird, beziehungsweise das überhaupt für eine individuelle Anwendung oder Aufgabenstellung möglich ist ...

Lo!