Bei der aktuellen Version des sql_injection_filter kommt es zu einem unschönen Fehler! Sobald ein Kunde ein Formular (Beispiel unter Kontakt) aufruft und eine Nachricht absendet, erhält er als Antwort "fuck you asshole" uihh...also lieber nicht einsetzen!!!
Dazu ist es wichtig zu verstehen wie solche Filter arbeiten und wo sich die Ansätze von Avengers Filter und dem G-Protector unterscheiden: Einen Filter der alles filtert wir es nicht geben können. Die Frage ist immer wie streng der Filter einegstellt ist, also was er noch durchlässt und was nicht. Für den G-Protector haben wir im Rahmen eines automatisierten Security-Scans eine Reihe von Parametern identifizert, die potenziell anfällig für XSS und SQL-Injections sein könnten. Für diese Parameter haben wir im G-Protector für den jeweiligen Zweck der Parameter passende Regeln hinterlegt, z.B. dürfen in den meisten id-Parametern nur Zahlen enthalten sein oder in action-Parametern nur alphanummerische Zeichen. So gibt es im G-Protector also nicht eine Regel, die für alles gilt, sondern eher fallspezifische. Im Klartext: Unser G-Protector schaut sich einzelne Bereiche des Shops an und legt dann fest, was in welchem Bereich erlaubt ist und was nicht. Das führt dazu, dass er bei externen Modulen nur bedingt nützlich ist, da er diese Bereiche nicht kennt. Ein Filter darf aber ohnehin nie als Freifahrtschein für Entwickler verstanden werden. Jeder Entwickler muss imemr auf die Sicherheit seiner Entwicklungen achten, der Filter ist nur ein zusätzlicher Schutz, falls doch einmal etwas übersehen wird. Avengers Ansatz ist etwas anders: Sein Filter arbeitet mit den selben Regeln im ganzen Shop und nicht Bereichsweise. Den Ansatz haben wir auch mal verfolgt, aber uns dann doch dagegen entscheiden, da er auch schnell zu Problemen führt. Beispiel: Avengers Filter sucht in gesendeten Daten nach den o.a. Strings. Gerade Strings wie "or " und "and " können in vielen sinnvollen Texten enthalten sein, die an den Shop gesendet werden, z.B. "Der Monitor ist klasse!" im Kontaktformular oder Kommentar einer Bestellung, "Am Waldrand 1" als Straße in der Registrierung. In beiden Fällen habe ich ein "Fuck you, asshole!" gemeldet bekommen. Dazu kommt, dass man mySQL-Schlüsselwörter tatsächlich durch Inline-Comments unkenntlich machen kann. So lässt sich ein "SELECT" unter anderem durch folgende Schreibweisen ausführen: S/**/ELECT S/**/E/**/L/**/ECT S/*hack123*/ELECT sel/*ECT*/ect S/**/E/**/L/**/E/**/C/**/T Da Input-Filter die Logik einer Applikation in der Regel nicht kennen und sinnvolle Inputs nicht immer eindeutig von ungewünschten Inputs erkennen können, können diese immer nur bis zu einem bestimmten Umfang Sicherheit bieten. Zu scharfes Filtern kann dann zu ungewollten Effekten wie oben beschrieben führen. Sich als Entwickler darum blind auf diese Filter zu verlassen und selbst nichts mehr für die Sicherheit zu tun ist also in etwa wie beim Einparken nicht mehr aus dem Fenster oder in die Spiegel zu schauen, weil man doch eh eine Einparkhilfe hat.
Kann ich nicht bestätigen. Läuft bei mir einwandfrei in drei Shops. Gerade getestet. Hast Du evtl. nicht die aktuellste Version installiert?
Habe den Text mal vorsichtshalber geändert: $this->fuck_you="Ein Fehler ist aufgetreten. Bitte informieren Sie den Shopbetreiber!";
Können wir nicht von Herrn Nadir die Infos zur angeblichen Sicherheitslücke für 200,- EUR kaufen und DANN Strafanzeige stellen? Dann wüssten wir zumindest woher das Problem stammt und ob noch mehr betroffen sind? Oder vllt möchte Gambio selbst mal Kontakt aufnehmen mit dem Typen?
Oh ja... das ist wirklich nicht gut.. Ich hab 1513 Adressen mir "and" und 3814 Adressen mit "or" von insgesamt 11.000 Adressen im Kundenstamm... Die Wahrscheinlichkeit damit einen Kunden vor den Kopf zu stossen ist also recht hoch.
Würde es nicht reichen ein Leerzeichen vor 'and', 'or' und 'all' zu setzen? Das sollte doch einige false positives verhindern und trotzdem funktionieren? PHP: 'select ', 'select(', 'union ', ' and ', ' or ', ' all ', 'from ', 'from(', 'concat('
Daniels Einwand bzgl. der Kommentare gilt auch hier: Code: SELECT * FROM `customers` WHERE customers_id = 1 /**/OR/**/ customers_id = 1 Leerzeichen sind als Merkmal überhaupt untauglich. Code: SELECT*FROM`customers`WHERE`customers_id`='1'/**/OR/**/`customers_id`='1' Das ist zwar grausam anzusehen, wird von MySQL aber akzeptiert.
Danke! ich habe "and", "or" und "all" erstmal rausgenommen. Keine Stunde später hat eine "Andrea XYZ" eine Bestellung über 550,- EUR getätigt. Der Auftrag wäre mir durch die Lappen gegangen...
So, habe das noch mal überarbeitet... Zum einen braucht man die "and" und "or" nicht wirklich zu testen, da die ohne "union" und "select" nicht auftreten können. (Aus gleichem Grunde m.E. auch nicht die "DROP", "UPDATES" usw., da die SQL-injizierten Befehle ja nicht freistehend ausgeführt werden, sondern nur als Anhang zu schon existierenden SELECTS usw. genutzt werden können. Das führt dann zu einem SQL-Fehler. Zum anderen wird jetzt nicht mehr die "böse Meldung" angezeigt, sondern der Wert der Variablen mit SQL-Befehlen wird einfach ab dem Auftauchen des Elements angeschnitten, so dass dann ein SQL-Fehler entsteht. Im Moment habe ich mich erst mal darauf konzentriert, die vorhandenen Einbruchsversuche zu blocken, das deckt sicher noch nicht alle denkbaren Möglichkeiten ab. P.S.; Ich finde es schon schade, dass sich die gambio-Cracks nur damit befassen, nachzuweisen, dass und warum mein Ansatz Blödsinn ist. Statt ein konstruktive Lösung zum Stopfen dieses Loches mit zu suchen (z.B. Reguläre Ausdrücke, um einen weiten Bereich möglicher Konstrukte filtern zu können).
Ich will mal ganz stark hoffen, dass sich das Gambio-Team da im Hintergrund mehr überlegt, als hier in diesem Thread kommuniziert wird. Wenn nicht, stimmte ich Avenger zu. @Gambio: Das MUSS funktionieren, dass ein Gambio-Shop ohne Risiko von SQL-Injections betrieben werden kann. Ich finde es natürlich völlig ok, dass ihr nicht die Verantwortung für Erweiterungen von Dritten übernehmen wollt, aber das ist ja auch - von euch beworbenes - Feature eures Shop-Systems, dass es anpassbar ist. Wenn das also nicht von vornherein der Fall ist, dass solche eigenen Erweiterungen sicher sind, dann erwarte ich mir von euch auch eine ordentliche Dokumentation, wo drin steht, was ich bei eigenen Erweiterungen beachten muss / was ich überprüfen muss, wenn ich eine Erweiterung eines Drittanbieters einsetze / was ich in das Lastenheft reinschreiben muss, wenn ich einen Programmierauftrag an Dritte vergebe. Das muss auch für normale Shopbetreiber mit weniger Programmierkenntnissen als Avenger & Co verständlich und nachvollziehbar sein, welche Sicherheitsregeln hier bei der Programmierung einzuhalten sind.* So eine Dokumentation habe ich bisher noch nicht gefunden, und möchte hiermit dringend den Wunsch danach äußern. *) Edit: Ich nehme mal ganz stark an, dass in marmoles' Shop keine Anfänger-Fehler wie ungefilterte Datenbankabfragen u dgl. drin sind, die auch jedem Anfänger klar sein sollten.
Also von den XTC Forks dürfte Gambio inzwichen das sicherste sein. Und 100% Sicherheit gibt es nie und die darfst auch nie vorraussetzen / erwarten. Wenn 3. Anbieter Module entwickeln sollten sie eigentlich wissen das sie ihre Module absichern müssen finde ich sonst sind es keine guten Programmierer. Klar ist der Fall ärgerlich und alle machen sich nun gedanken aber man sollte das nun nicht über dramatisieren. Selbst bei großen Firmen werden DBs gehackt und Daten gestohlen. So alle paar Monate stehts in der Zeitung das wieder bei einer internationalen Firma Daten gestohlen wurden. Und diese Firmen überleben das auch und hatten sicher mehr Programmierer und Experten im Einsatz als wir je haben werden.
Stimme Avenger und Johannes zu und wäre nach wie vor sehr daran interessiert zu erfahren auf welchem Wege die bei Marmoles reingekommen sind. Gambio spricht die ganze Zeit von Drittanbieter-Erweiterungen (und sagt damit implizit dass Gambio in der Ausgangsversion einbruchsicher ist) während Avenger dabei ist, eine vermutete Sicherheitslücke der Standardinstallation zu stopfen? Den Herstellerfilter hat ja jeder Gambio Shop...
Ob das eine Sicherheitslücke der Standardinstallation weiß ich nicht, evtl. wird der "Angreifer" ja mitteilen, wo die Lücke ist. ... Aber unabhängig davon finde ich es nicht gut, dass sich SQL-Injektionen unbehelligt durch das System bewegen können. Das sollte man schon zentral abfangen. Wenn man überall doch wieder alles selbst machen muss kann man sich ja den GProtector und den Input-Filter sparen, die kosten ja dann nur unnötig Zeit.