nicht angemeldet
Referer als SIcherheitsmaßnahme?
Hallo Forum,
ich habe mir heute Folgendes überlegt: Wenn man ein Weblog programmiert, in dem man die Möglichkeit hat, zu einem bestimmten Artikel einen Kommentar zu schreiben, dann macht man das ja so, daß in dem Formular, in dem der Kommentar eingegeben wird, in einem versteckten Input-Element die ID-Nummer des Artikels steht, damit man in der Auswertung und Weiterverarbeitung der Formulardaten, sprich des Kommentars, auch weiß, zu welchem Artikel der Kommentar gehört.
Was aber, wenn jemand den Quelltext kopiert, aus dem '<input type="hidden" name="article_id" value="23">' ein '<input type="hidden" name="article_id" value="25">' macht, das Ganze auf einem anderen Server ablegt und dort ausführt? Dann werden die Kommentar-Daten ja nach der Manipulation mit Artikel 25 statt mit Artikel 23 in Verbindung gebracht.
Meine Überlegung war jetzt, dass ich mit einem '$referer=$_SERVER["HTTP_REFERER"];' vor der Weiterverarbeitung überprüfe, ob die zu übernehmenden Usereingaben auch _wirklich_ von meinem Formular, also zB von http://example.org/formular.php kommen und erst _dann_ eine Weiterverarbeitung vornehme.
Jetzt hab ich aber gelesen, daß man den Referer nicht zu sicherheitsrelevanten Zwecken auf einer Website einzusetzen soll, weil man damit auch Leute, die zB. in einer Firma hinter einem Proxyserver, der die Refererdaten wegfiltert, sitzen, ungerechterweise ausschließen würde.
Nun frage ich mich, wie man es dann elegant löst, sich von oben beschriebenen Manipulationen zu schützen. Also wie man ganz allgemein sicherstellen kann, dass Formulardaten, die verarbeitet werden, auch wirklich vom erwarteten Formular auf dem eigenen Server kommen?
MfG
Der Brombeermilchtrinker
-
Nun frage ich mich, wie man es dann elegant löst, sich von oben beschriebenen Manipulationen zu schützen. Also wie man ganz allgemein sicherstellen kann, dass Formulardaten, die verarbeitet werden, auch wirklich vom erwarteten Formular auf dem eigenen Server kommen?
du erzeugst einen prüfwert den du in eine datenbank schreibst und beim übergeben des forumlars von der auswertungsseite wieder auswerten lässt
ähnlich wie ein captcha - aber auch damit kannst du unmöglich verhindern, dass der inhalt manipuliert ist - den quelltext live im browser ändern ist keine hexerei
-
Hi Suit,
du erzeugst einen prüfwert den du in eine datenbank schreibst und beim übergeben des forumlars von der auswertungsseite wieder auswerten lässt
sowas habe ich auch schon angedacht. Aber _irgend eine_ Information gibst Du dem Formular _immer_ mit auf dem Weg - wie willst Du sonst die Eingaben verschiedener User auseinanderhalten bzw. wie sonst soll ich bei der Auswertung den von Dir vorgeschlagenen Prüfwert mit dem Formular in Verbindung bringen? Ein verstecktes Input-Element kann ich mir meines Erachtens auch hier nicht sparen. Und somit besteht erst recht wieder eine Manipulationsgefahr.
ähnlich wie ein captcha - aber auch damit kannst du unmöglich verhindern, dass der inhalt manipuliert ist - den quelltext live im browser ändern ist keine hexerei
ja eben.
MfG
Der Brombeermilchtrinker
-
Ein verstecktes Input-Element kann ich mir meines Erachtens auch hier nicht sparen. Und somit besteht erst recht wieder eine Manipulationsgefahr.
wieso? wenn der hash nicht mit dem in der datenbank übereinstimmt, wird nicht aktualisiert
ja eben.
nein, nichts eben :) dir gehts aber nicht darum, dass ich einen spezfischen datensatz manipulieren kann, sondern dass ich mit dem forumlar nicht andere daten manipulieren kann - wenn ich zb daten absende und anstatt id 1 plötzlich id 2 bearbeite
mediawiki schützt sich davor lediglich indem die revisionsnummer der bearbeitungsgrundlage mitübergeben wird - ist diese in der versionsgeschichte des zu bearbeitenden artikels nicht enthalten, schlägt die bearbeitung fehl
wenn ich den quelltext aber so manipuliere, dass ich die daten eines anderen artikels eintrage, könnte ich das umgehen - aber warum sollte ich das wollen, den anderen artikel kann ich sowieso bearbeiten - wenn ich keine rechte dazu habe, greift ohnehin eine andere logik
-
-
-
Moin
Was aber, wenn jemand den Quelltext kopiert, aus dem '
<input type="hidden" name="article_id" value="23">' ein '<input type="hidden" name="article_id" value="25">' macht, das Ganze auf einem anderen Server ablegt und dort ausführt? Dann werden die Kommentar-Daten ja nach der Manipulation mit Artikel 25 statt mit Artikel 23 in Verbindung gebracht.Das würde schonmal nicht funktionieren, da man auch "HIDDEN"_Felder beeinflussen kann. Die sind nicht sicher vor Manipulation.
Meine Überlegung war jetzt, dass ich mit einem '
$referer=$_SERVER["HTTP_REFERER"];' vor der Weiterverarbeitung überprüfe, ob die zu übernehmenden Usereingaben auch _wirklich_ von meinem Formular, also zB von http://example.org/formular.php kommen und erst _dann_ eine Weiterverarbeitung vornehme.ich frage mich wozu jemand die ID beeinflussen sollte. Ich denke nicht das dies sher relevant ist.
Gruß Bobby
--
-> Für jedes Problem gibt es eine Lösung, die einfach, sauber und falsch ist! <-
-> Nicht das Problem macht die Schwierigkeiten, sondern unsere Sichtweise! <-
ie:{ br:> fl:{ va:} ls:< fo:) rl:( n4:( de:> ss:) ch:? js:( mo:} sh:) zu:)-
Hi Bobby,
Das würde schonmal nicht funktionieren, da man auch "HIDDEN"_Felder beeinflussen kann. Die sind nicht sicher vor Manipulation.
Genau davon spreche ich ja.
ich frage mich wozu jemand die ID beeinflussen sollte. Ich denke nicht das dies sher relevant ist.
Mir ist schon bewußt, dass die Wahrscheinlichkeit, auf jemanden zu treffen, der sich das (auf einer für die Menschheit irrelevanten Seite) antut, nicht sehr groß ist.
Nichts desto trotz _könnte_ dies ein Sicherheitsproblem sein, deshalb hinterfrage ich ganz allgemein, was da der beste Schutz ist bzw. ob es einen Schutz gibt.
MfG
Der Brombeermilchtrinker
-
Hi,
ich frage mich wozu jemand die ID beeinflussen sollte. [...]
Nichts desto trotz _könnte_ dies ein Sicherheitsproblem sein,
Nein, das koennte es nicht - vorausgesetzt, die ueblichen Masznahmen zum Absichern von Eingaben in die Datenbank hast du eingehalten.
Es koennte hoechstens unerwartete Ergebnisse liefern.
Wenn jemand die existierende ID 25 auf die ebenfalls existierende 23 aendert - dann landet sein Kommentar halt beim Eintrag 23, aber nicht anders, als haette er direkt den Eintrag 23 kommentiert.
Wenn jemand die nicht existente ID 4711 eingibt - dann sieh zu, dass du das abfaengst, in dem du zunaechst ueberpruefst, ob ein Eintrag mit dieser ID existiert. Andernfalls haettest du eventuell bei zukuenftigen Eintraegen bereits Kommentare, die dann angezeigt werden, sobald du den Eintrag mit dieser ID erstellt hast.
MfG ChrisB
--
„This is the author's opinion, not necessarily that of Starbucks.“-
Hi Chris,
Nichts desto trotz _könnte_ dies ein Sicherheitsproblem sein,
Nein, das koennte es nicht - vorausgesetzt, die ueblichen Masznahmen zum Absichern von Eingaben in die Datenbank hast du eingehalten.
Also angenommen, die Sizilianische Camorra beschließt bei Ihrem monatlichen Treffen, welche Gegner dieses mal "auszuschalten" sind. Nach dem Beschluß werden, damit der Killer auch weiß, wen er besuchen muß, die Namen und Adressen der Opfer in die (als Bootsausflugsunternehmen getarnte) Camorradatenbank unter dem Punkt "Künftige Exfreunde" eingetragen. Nachdem es erst wieder in einem Monat zu einem Treffen kommen wird, wird die Eintragsmöglichkeit für die "künftigen Exfreunde" deaktiviert.
Zeitgleich plane ich einen Ausflug ins schöne Süditalien und bitte Dich, mir übers Internet einen Bootsausflug zu buchen, weil ich selbst nicht dazu komme. Du willst mir eine Freude machen, kopierst den Quellcode, änderst die ID auf eine Nummer eines Artikels, in dem man sich für Gratiscocktails anmelden konnte, wo die Eintragsmöglichkeit aber schon deaktiviert ist, weil die Aktion vorbei ist und klickst auf SENDEN.
Leider verschaust Du Dich bei den IDs und nimmst irrtümmlich, ohne es zu wissen, jene ID, die zum Camorrabereich führt, in dem ich somit mit Namen und Adresse eingetragen bin.
1 Woche später, ich denke nichts Schlimmes und öffne gut gelaunt meine Wohnungstür, steht plötzlich ein Italiener mit schwarzer Sonnenbrille und einer Walther PPK vor mir. Er wirft seine Zigarette zu Boden, drückt sie mit dem Schuh aus, sieht mich an und sagt "Addio, amico!"
Spätestens _jetzt_ würde ich die Situation aber schon als _ganz *besonderes* Sicherheitsrisiko_ einstufen. ;-)
MfG
Der Brombeermilchtrinker
-
Yerf!
Spätestens _jetzt_ würde ich die Situation aber schon als _ganz *besonderes* Sicherheitsrisiko_ einstufen. ;-)
Ja. Aber trotzdem an einer ganz anderen Stelle. Wenn die Eingabemöglichkeit für die "Exfreunde" deaktiviert wurde, sollte auch mittels "gefälschtem" Formular kein Eintragen mehr möglich sein. Dies ist rein serverseitig zu lösen, ohne die Betrachtung irgendeines möglichen Clients. z.B. als Datenbankeintrag: für die ID=42 keine Einträge und dies vor jedem Eintragsversuch überprüfen (natürlich mit der ID für die eingetragen werden soll)
Gruß,
Harlequin
--
<!--[if IE]>This page is best viewed with a webbrowser. Get one today!<![endif]--> -
echo $begrüßung;
Du willst mir eine Freude machen, kopierst den Quellcode, änderst die ID auf eine Nummer eines Artikels, in dem man sich für Gratiscocktails anmelden konnte, wo die Eintragsmöglichkeit aber schon deaktiviert ist, weil die Aktion vorbei ist und klickst auf SENDEN.
Wenn eine Aktion als geschlossen definiert ist, dann sollte, egal woher er kommt, jeder Versuch einer Eintragung grandios scheitern. Du fährst sicherlich nicht in den Urlaub und hängst nur einen Zettel an die Tür, auf dem steht, dass selbige abgeschlossen sei.
echo "$verabschiedung $name";
-
Hi dedlfix,
Wenn eine Aktion als geschlossen definiert ist, dann sollte, egal woher er kommt, jeder Versuch einer Eintragung grandios scheitern.
Ja, in dem der Link zur Kommentierung entfernt wird. Solange aber die Tabelle in der Datenbank existiert und ich dem Verarbeitungsskript eine Falsche ID unterjuble, kommt es trotzdem zum Eintrag.
Oder besteht die Möglichkeit, innerhalb einer MySQL-Datenbank eine Tabelle zu sperren?
Wobei ja auch das nichts bringen würde, weil ich ja bei 100 Artikeln nicht 100 Tabellen habe sondern _eine_ Tabelle mit den Kommentaren und der ID des Artikels, auf den sie sich beziehen.
MfG
Der Brombeermicltrinker
-
Hi,
Wenn eine Aktion als geschlossen definiert ist, dann sollte, egal woher er kommt, jeder Versuch einer Eintragung grandios scheitern.
Ja, in dem der Link zur Kommentierung entfernt wird.
Damit ist absolut nichts als (ab)geschlossen definiert.
Nochmal Zitat dedlfix:
Du fährst sicherlich nicht in den Urlaub und hängst nur einen Zettel an die Tür, auf dem steht, dass selbige abgeschlossen sei.
Dann noch mal eine andere Analogie:
Wenn du den Link zur Kommentierung entfernst, dann hast du das Adressschild von deinem Haus entfernt.
Zu glauben, dass deshalb jetzt niemand mehr durch die nicht abgeschlossene Tuer hereinkaeme, waere reichlich naiv.Solange aber die Tabelle in der Datenbank existiert und ich dem Verarbeitungsskript eine Falsche ID unterjuble, kommt es trotzdem zum Eintrag.
Dann muss entweder deine Scriptlogik oder deine Datenbank die "falsche" ID zurueckweisen.
Oder besteht die Möglichkeit, innerhalb einer MySQL-Datenbank eine Tabelle zu sperren?
Wobei ja auch das nichts bringen würde, weil ich ja bei 100 Artikeln nicht 100 Tabellen habe sondern _eine_ Tabelle mit den Kommentaren und der ID des Artikels, auf den sie sich beziehen.
Der Artikel selber koennte ein zusaetzliches Feld haben, in dem die Info hbinterlegt sind, ob zu ihm weitere Kommentare erlaubt sind oder nicht.
MfG ChrisB
--
„This is the author's opinion, not necessarily that of Starbucks.“-
Hi Chris,
Ja, in dem der Link zur Kommentierung entfernt wird.
Damit ist absolut nichts als (ab)geschlossen definiert.
das war mir schon klar.
Der Artikel selber koennte ein zusaetzliches Feld haben, in dem die Info hbinterlegt sind, ob zu ihm weitere Kommentare erlaubt sind oder nicht.
Aja, _das_ ginge. Die Tabelle mit den Artikeln bekommt zB das BOOL-Feld "comment" dazu. Solange da 1 steht, was ja das Verarbeitungsskript überprüfen kann, wird ein Kommentar zum Artikel eingetragen.
Wenn ich das (zB via phpMyAdmin) auf 0 ändere, dann lenht das Verarbeitungsskript die Speicherung ab, auch, wenn 100mal die (falsche) ID geliefert wird. Eigentlich ganz simpel!
Wie gesgat, ich hatte kein Problem, mich hat das auch nicht betroffen, ich hab mir das heute nur theoretisch mal so durchüberlegt.
MfG
Der Brombeermilchtrinker
PS: Meinen kleinen Italienischen Krimi hast gar nicht kommentiert, dabei hab ich mich _so_ bemüht.
-
-
-
-
-
-
-
-
echo $begrüßung;
Was aber, wenn jemand den Quelltext kopiert, aus dem '
<input type="hidden" name="article_id" value="23">' ein '<input type="hidden" name="article_id" value="25">' macht, das Ganze auf einem anderen Server ablegt und dort ausführt?Man kann mit der entsprechenden Browser-Erweitung auch direkt aus der 23 eine 25 machen. Dann muss man sich nicht noch nicht mal um Referrer kümmern.
Dann werden die Kommentar-Daten ja nach der Manipulation mit Artikel 25 statt mit Artikel 23 in Verbindung gebracht.
Du versuchst hier eine einzige Möglichkeit, Unfug anzustellen, zu verhindern. Wenn jemand einen Kommentar unter einen falschen Beitrag setzen will, dann kann er das auch durch Aufrufen des falschen Beitrags machen. Du versuchst, ein soziales Problem mit technischen Mitteln zu verhindern. Menschen sind viel erfinderischer als man selbst berücksichtigen kann. Dir wird es (vermutlich) nie vollständig gelingen, jeglichen Missbrauch auszuschließen.
Meine Überlegung war jetzt, dass ich mit einem '
$referer=$_SERVER["HTTP_REFERER"];' vor der Weiterverarbeitung überprüfe,Damit wird nichts überprüft, nur sinnlos eine weitere Variable mit dem bereits in $_SERVER["HTTP_REFERER"] stehenden Wert angelegt.
ob die zu übernehmenden Usereingaben auch _wirklich_ von meinem Formular, also zB von http://example.org/formular.php kommen und erst _dann_ eine Weiterverarbeitung vornehme.
Jede Angabe, die vom Benutzer kommt, ist veränderbar. Das gilt auch für den Referrer. Es ist auch nicht unüblich, dass Referrer von beispielsweise Sicherheitssoftware geändert werden.
Jetzt hab ich aber gelesen, daß man den Referer nicht zu sicherheitsrelevanten Zwecken auf einer Website einzusetzen soll, weil man damit auch Leute, die zB. in einer Firma hinter einem Proxyserver, der die Refererdaten wegfiltert, sitzen, ungerechterweise ausschließen würde.
Eben. Wie gesagt, jegliche vom Benutzer kommende Daten können manipuliert werden und sind per se nicht vertrauenswürdig.
Nun frage ich mich, wie man es dann elegant löst, sich von oben beschriebenen Manipulationen zu schützen. Also wie man ganz allgemein sicherstellen kann, dass Formulardaten, die verarbeitet werden, auch wirklich vom erwarteten Formular auf dem eigenen Server kommen?
Es geht nicht.
Du kannst nicht viel mehr machen, als auf Plausibilität zu prüfen soweit das technisch mit vertretbarem Aufwand möglich ist und für einen sicheren Transport zum DBMS sorgen. Alles weitere musst du mit deiner Intelligenz als Mensch begutachten und beurteilen und entsprechend reagieren.
echo "$verabschiedung $name";
-
Hallo
das hidden-Feld im Formular muss die "23" ja irgendwo her haben sprich das Formular wird zumindest teilweise serverseitig generiert.
Speicher doch im Formular-generierenden Skript die Artikel-ID in einer Session-Variablen und generiere einen Pseudozufallscode, der mit der Artikel-ID verknüpft ist und nur der Session und dem Formular (hidden) bekannt ist. Das zweite ist nötig für den Fall, dass der User mehrere Formulare öffnet.
Nun kann der User zwar den Code ändern, aber da Du beim Empfängerskript dessen Existens und Gültigkeit überprüfen kannst, ist Missbrauch "weitestgehend" ausgeschlossen.
Mal so ne Idee. Oder habe ich wieder was übersehen?
Gruß vom foomaker
--
Natürlich glaube ich an die Existenz von Ausserirdischen. Schliesslich gibt es ja auch das PERFEKTE SCRIPT. -
Was aber, wenn jemand den Quelltext kopiert, aus dem '
<input type="hidden" name="article_id" value="23">' ein '<input type="hidden" name="article_id" value="25">' macht, das Ganze auf einem anderen Server ablegt und dort ausführt? Dann werden die Kommentar-Daten ja nach der Manipulation mit Artikel 25 statt mit Artikel 23 in Verbindung gebracht.Das ist ein Grund, warum IDs die vorhersagbar sind, Angriffspunkte geben.
Das lässt sich aber einfach und 100% kontrolliert ändern.Meine Überlegung war jetzt, dass ich mit einem '
$referer=$_SERVER["HTTP_REFERER"];' vor der Weiterverarbeitung überprüfe, ob die zu übernehmenden Usereingaben auch _wirklich_ von meinem Formular, also zB von http://example.org/formular.php kommen und erst _dann_ eine Weiterverarbeitung vornehme.Forget it....
mfg Beat
--
><o(((°> ><o(((°>
<°)))o>< ><o(((°>o
-