Patrick meinte gerade ob ich mir schonmal Gedanken darüber gemacht hätte, das man mit Firebug im Prinzip ja auch jedes Formularfeld einer Seite beliebig manipulieren könnte. Ja, darüber hatte ich auch schon des öfteren Nachgedacht.
Die Frage ist nur, was kann man dagegen tun? Ich stelle mir gerade ein Praxisbeispiel vor: Ihr habt eine ein <select> dessen <option>-Werte aus einer Datenbank generiert werden. Relativ üblich oder? Wenn nun ein Bösewicht daher kommt und dem <select> z.B. via Firebug eine <option> unterjubelt die es so in der Datenbank nicht gibt, was macht in dem Fall das PHP-Script? Wird der Wert im Nachheinein nicht nochmal überprüft würde ich davon ausgehen das evtl. ein neuer Datenbank-Eintrag erzeugt wird der auf ein Feld verweist das es gar nicht gibt oder das nicht genutzt werden dürfte.
Ich bin mir sicher das ein Großteil der Programmierer gegen solche externen Eingriffe gar keine Mechanismen einbauen, also Validierungen die prüfen ob der eingegebene Wert evtl. manipuliert wurde. Bei einer kleinen Applikation mag das noch mit relativ wenig Aufwand möglich sein, indem man einfach überprüft ob der übermittelte Wert den überhaupt zu den Werten in der Datenbank passt, doch bei komplexeren Gebilden kann das doch sehr schnell in viel Arbeit ausufern oder was meint ihr?
Habt ihr euch darüber evtl. auch schon Gedanken gemacht bzw. Lösungen gefunden? Ich meine es gibt ja auch nützliche Manipulationen die durch DOMScripting erzeugt werden, doch wie unterscheiden?
Kommentare zum Thema Hacken mit Firebug und Formularfeldern?:
Es ist eigentlich ganz einfach indem mach einfach prüft ob die Werte innerhalb eines vorgegebenen Wertebereichs liegen.
Das kann man wirklich einfach mit if und/oder switch erledigen.
Denn eigentlich wird doch jedem Entwickler gepredigt – Vertraue KEINEN Daten die vom Benutzer kommen.
Sicherlich, Firebug hat die Möglichkeit des direkten modifizierens nicht erfunden, nur erheblich einfacher gemacht bzw. populär.
Der Post soll eigentlich auch die Leute erreichen die über das Thema (zugegeben, so wie ich oftmals auch) noch nicht nachgedacht haben. XSS und Co. sind derzeit in aller Munde, nur solch etwas nahe liegendes spricht kaum jemand an… Ich werde auf jeden Fall versuchen das in Zukunft zu beherzigen, aber ich denke es wird auch Fälle geben wo die Richtigkeit der Daten nicht so einfach bestimmt werden kann.
@Christian: Inwieweit solche Angriffe mit Firebug populär werden sei mal dahingestellt, denn der Anteil von Mozilla-Browsern ist der geringere. Dieser Anteil wird nochmal verkleinert, wenn man alle die abzieht, die kein Firebug installiert haben. Und wenn man dann nochmal die abzieht, die sich keine Gedanken darüber machen, Firebug für böswillige Zwecke zu verwenden, dann ist man imho von „populär“ wirklich entfernt.
Ich wüsste jetzt so spontan aber keinen Fall, bei dem „die Richtigkeit der Daten nicht so einfach bestimmt werden kann“. Entweder ich habe freie Eingabefelder (Text, Password, Textarea) bei denen ich ohne Firebug eh alles mögliche einfügen kann, oder ich habe vordefinierte Felder (Select, Radio, Checkbox), bei denen ich nach dem Abschicken noch einmal serverseitig überprüfen kann, ob der übermittelte Wert in dem erlaubten Wertebereich liegt.
Als Developer weiß ich doch vorher immer, was ich dem User anbiete & daher weiß ich auch was zurück kommen soll. Ein Abgleich der Daten ist einfach und selbst Textinput lässt sich mit RegEx gut validieren.
Zum Debuggen unsicherer Formulare eignet sich übrigens das Tamper Data – Plugin für Firefox sehr gut: https://addons.mozilla.org/de/firefox/addon/966 . Es ist nur dafür da, um oben beschriebene Injections zu machen. Ich selbst finde Firebug nämlich recht unhandlich und bevorzuge lieber mehrere Plugins, die jeweils auf Einzelbereiche fürs Development spezialisiert sind.
Jeder der sich Gedanken darüber macht, dass Firebug eine Gefahr für seine Applikationen darstellt, sollte aufhören Web-Anwendungen zu entwickeln – XSS ist altbekannt und damit ist eine Validierung der Daten auch ohne Firebug Pflicht.
Also irgendwie mache ich mir langsam ernsthafte Sorgen, was alles möglich ist…Ist überhaupt noch etwas sicher?
Gruß
Diomira
Zum PlugIn:
Firebug ist eines der PlugIns die das können.
Über die Webdeveloper-Toolbar kann man auch Daten verändern.
Und die alte Methode, lokal abspeichern, verändern und abschicken
wurde auch bereits beschrieben.
Zur Entwicklung:
Es gibt in der Webentwicklung ein paar Grundsätze und einer lautet,
das alles was vom Client an den Server gesendet wird
eine potenzielle Schwachstelle darstellt.
Das bedeutet:
Viele denken erst an GET, weils über die URL einfach geht.
An POST weil der Beitrag darüber handelt.
Aber da ja alles vom Client nicht vertrauenswürdig ist,
gilt das auch für Header-Daten (z.B. welcher Browser verwendet wird).
Etwas zum Einlesen von php.net:
http://www.php.net/manual/de/security.php
Meiner Meinung eines der Besten Bücher zum Thema:
PHP-Sicherheit. PHP/MySQL-Webanwendungen sicher programmieren
@Diomira:
Wie im Leben: Nichts ist 100%tig sicher.
Und Software ist es am wenigsten. ;)
Grüße Francois
Nochmal: Mir ist schon bewusst das Firebug das nicht neu erfunden hat, es macht einem das ganze nur sehr sehr einfach. So recht musste ich mich damit aber bisher kaum beschäftigen, da ich bisher fast ausschließlich Webanwendungen für bekannte Nutzergruppen geschrieben habe, wo wirklich nur 4 oder 5 feststehende Mitarbeiter ein Backend bedienen durften.
Die Hardcore-Programmierer werden jetzt sagen das man jetzt vielleicht auch bei solchen Applikationen darauf achten müsste, was ich jedoch anders sehe.
Da ich jedoch gerade an einem Konzept für eine öffentliche Plattform sitze stellte ich mir eben die Frage wie das meine Leser machen ;) Denn in fast allen Anleitungen findet man zu dem Thema kaum etwas.
@Christian:
Noch kurz zu den geschlossenen Benutzergruppen.
Da ich im Unternehmen oft Software erstelle, die nur intern benötigt wird verstehe ich sehr gut das man hierfür den Overhead nicht machen möchte.
Darf mich da an der eigenen Nase fassen…
Doch Statistiken meinen, das die meißten Angriffe von innen kommen.
Aber bei 4 bis 5 Leuten denke ich ist das zu vernachlässigen.
Wie ich meine Anwendungen schütze:
Stufe 1: kleine Anwendung / intern / quick & dirty -> keine Überprüfung (bitte keine Steinigung…)
Stufe 2: kleine Anwendung / extern -> manuelle Überpüfung hinzufügen, hauptsächlich folgende PHP Funktionen: addslashes, htmlentities, is_int, is_*
Stufe 3: große Anwendung -> Funktionen über eine Klasse / Framework
früher hab ich ne kleine selbstgebastelte Klasse gehabt,
jetzt verwende ich vorzugsweise die Filter Klasse aus dem Zend Framework
http://framework.zend.com/manual/de/zend.filter.html
Die kann man außerdem auch nutzen, falls man sonst ein anderes Framework nutzt (beispielsweise Cake…).
Kommentar-Feed für diesen Artikel
Kommentarfunktion für diesen Artikel geschlossen.
Arbeitsvorlage für neue Projekte Firefox und die langsame JavaScript-Engine
Das ist ja kein Problem, das unmittelbar mit Firebug zusammenhängt. Wer das Wissen und die bösartige Energie hat, auf diese Weise in fremden Datenbanken herumzufummeln, kriegt das auch auch Firebug auf die Reihe.
Da hilft nur konsequentes Validieren. Alles was vom Nutzer kommt ist so lange bösartig, bis das Gegenteil bewiesen wurde. Die Unschuldsvermutung ist da nicht angebracht.