Anruf wegen angeblicher Sicherheitslücke

Thema wurde von Anonymous, 12. März 2014 erstellt.

  1. Nonito (Gambio)

    Nonito (Gambio) Administrator

    Registriert seit:
    21. April 2011
    Beiträge:
    279
    Danke erhalten:
    134
    Danke vergeben:
    52
    Hallo allerseits,

    Daniel und ich haben heute stundenlang zusammengesessen und die hier aufgekommenen Fragen besprochen. Die Fragen sind allesamt berechtigt und auch wohl irgendwie ein Zeichen dafür, dass wir gerade in Sachen Sicherheit einiges genauer erklären müssten.

    - Sollte ein guter Input-Filter nicht alles alleine schützen können?

    Zu der Frage, ob man sich als Entwickler beim Bereinigen von Inputdaten allein auf einen vorgeschalteten Inputfilter verlassen sollte, möchte ich zunächst von der PHP-Website höchstselbst zitieren, auf der es um die Abschaffung der Magic Quotes geht:

    http://www.php.net/manual/en/security.magicquotes.php
    Es kann und darf keinen Filter geben, der alle eingehenden Daten auf dieselbe Weise bereinigt. Wenn ein Inputfilter nicht weiß, welchem Zweck die Daten eines Parameters dienen, ist es nicht einmal theoretisch möglich, dass sich dieser in allen Fällen richtig verhält.

    Einfaches Beispiel: Cross-Site-Scripting (XSS) funktioniert in den meisten Fällen so, dass einem Webseiten-Besucher über einen ungesäuberten Parameter schadhafter HTML-Code ausgeliefiert wird, z.B. iframes mit Formularen, deren Inhalt an Server von Hackern gesendet wird, oder JavaScripte, die Browser-Schwachstellen ausnutzen, um Trojaner zu installieren.

    Nun könnte man sagen: "Schreiben wir doch einen Inputfilter, der in den Parametern dieser Website sämtliche HTML-Codes entfernt. Und damit auch alle zukünftigen und/oder fremden Entwicklungen von diesem Inputfilter profitieren, lassen wir ihn doch einfach ALLE Parameter auf diese Weise säubern". In diesem Fall würden beispielsweise WYSIWYG-Editoren wie der FCK-Editor nicht mehr funktionieren, deren Aufgabe es eben ist HTML-Code zu produzieren und zwecks Speicherung an die Website zu senden.

    Verzichtet man andererseits komplett auf das Entfernen von HTML, ist es technisch eben möglich, dass XSS stattfindet. Das Konzept "Ein Mittel für alles" funkioniert also nicht. Der Ansatz, den wir darum verfolgen, sieht so aus, dass wir uns eben durchaus im Einzelnen anschauen, welchem Zweck ein bestimmter Parameter dient und entscheiden danach, ob oder wie dieser Parameter behandelt werden muss.

    Bei uns unbekannten Parametern (z.B. aus Fremdmodulen) steckt es in der Natur der Sache, dass wir diese nicht kennen, somit nicht kategorisieren können und diese - wenn überhaupt - nur eingeschränkt gesichert werden. Aus diesem Grund ist es m.E. unerlässlich, dass Entwickler die Sicherheit Ihres Codes selbst in die Hand nehmen.

    - Was tut der G-Protector eigentlich?

    Durch automatisierte Scans und manuelle Untersuchungen haben wir festgestellt, dass im Adminbereich Unmengen Code enthalten ist, bei dem die Entwickler sich scheinbar eben nicht viel Gedanken um Sicherheit gemacht haben oder sich durch etwaige Inputfilter oder den vorausgesetzten Adminlogin (dazu später mehr!) ausreichend geschützt fühlten.
    Um diese potenziellen Schwachstellen zu schließen, sahen wir zwei Möglichkeiten:

    1. Wir passen sämtliche Stellen an und nehmen die fehlenden Bereinigungen vor oder

    2. Wir schauen uns die Daten jeweils ganz genau an und schreiben maßgeschneiderte Regeln für einen Input-Filter.

    Das Problem bei der ersten Möglichkeit war, dass unfassbar viele Dateien von Anpassungen betroffen gewesen wären. Wir hätten in einem Update praktisch den kompletten Adminbereich ausliefern müssen. Das wollten wir insbesondere den Shopbetreibern mit umfangreichen Anpassungen nicht zumuten.

    Wir haben uns darum für den zweiten Weg entschieden und den G-Protector gebaut. Dem G-Protector haben wir zu den möglicherweise gefährdeten Dateien konkrete Filteranweisungen für die einzelnen Parameter mitgegeben. Das sieht in etwa so aus:

    PHP:
    $this->add_filter('Dateinamen-Filter 1''admin/backup.php''_GET["file"]''basename');
    $this->add_filter('Alphabetisch-Filter 6''admin/banner_statistics.php''_GET["type"]''only_alphabetic');
    $this->add_filter('Integer-Filter 14''admin/customers.php''_GET["status"]''convert_to_integer');
    Dem G-Protector ist somit bekannt, auf welche Weise er die einzelnen Parameter filtern muss. So ist unserer Meinung nach das größtmögliche Maß an Sicherheit ohne Beeinträchtigung der Funktionalität erreicht.

    - Warum gibt es die Filterregeln nur für den Adminbereich?

    Bei unseren Security-Audits sind uns auch im Frontend Stellen aufgefallen, die potenziell gefährlich aussahen. Allerdings betraf dies nicht annähernd so viele Dateien wie im Adminbereich. Gegen eine Auslieferung aller aus Sicherheitsgründen angepassten Dateien sprach also nichts, darum haben wir es getan und auf Regeln im G-Protector verzichtet.

    Allerdings spricht auch tatsächlich überhaupt nichts dagegen, für einige durchaus bekannte Parameter wie die products_id, language_id oder manufacturers_id Regeln auch fürs Frontend auszuliefern! Passend abgestimmt dürfte da wohl wirklich gelten "viel hilft viel". Wir werden uns darum nun auch die Parameter im Frontend vornehmen und die entsprechenden Regeln in den G-Protector einfließen lassen. Damit werden wir die Entwickler in Sachen Sicherheit zwar besser unterstützen bzw. absichern, hoffen aber dennoch, dass jeder weiterhin auf die Sicherheit in seinem Code achtet.

    - Ist der Adminbereich nicht schon durch den Adminlogin geschützt?

    Direkte Angriffe auf den Adminbereich werden tatsächlich aufgrund eines fehlenden Adminlogins frühzeitig geblockt. Erinnern wir uns aber an das Sicherheitsproblem in der whos_online-Ansicht im letzten Jahr, worüber der Admin über Umwege tatsächlich per XSS angreifbar wurde. Themen wie XSRF kommen auch noch dazu und werden von den meisten Entwicklern einfach unterschätzt. Die Angriffsvektoren im Adminbereich sind zwar um Welten schmaler als im Frontend, aber dennoch vorhanden. Von daher sollten sich auch hier die Entwickler nicht in falscher Sicherheit wiegen.

    - Warum ist der G-Protector auch im Frontend, wenn es doch keine Regeln gibt?

    Sollten im Frontend Parameter bekannt werden, deren Verarbeitung zu Sicherheitsproblemen führt, ohne dass wir die genaue Stelle im Code wissen, lässt sich mit dem G-Protector in den meisten Fällen eine Regel einfügen, die das Sicherheitsproblem erstmal behebt. Nachdem das Problem mit der manufacturers_id bekannt wurde haben wir unsere Standardversionen bis ins Kleinste auseinandergenommen und einfach keine Stelle gefunden, an der eine Bereinigung fehlte. Der Notfallplan sah so aus, dass wir den Parameter über den G-Protector gesäubert hätten. Zum Glück war das dann ja nicht mehr nötig.

    Übrigens haben wir heute mal gemessen, wieviel der G-Protector im Frontend eigentlich an Ladezeit kostet. Die Frage kam hier zwischendurch glaube ich auf. Das Ergebnis im Mittel: 12 ms. Das ist sehr wenig und damit nach unserer Auffassung recht gut zu vertreten.

    Der G-Protector bringt außerdem noch die IP-Sperre mit, die auch fürs Frontend wichtig ist. Aus dem Feature haben wir zugegeben leider wirklich nicht besonders viel gemacht. Niemand kannte sie bisher und eine Oberfläche gibt es für die auch nirgends. Ich habe hier jetzt eine ganze Reihe guter Ideen bzgl. der IP-Sperre gesehen. Besonders Avengers Modul, dass eine IP auf Verdacht automatisch auf die Liste setzt, finde ich klasse! Da werden wir auf jeden Fall eine Menge Sachen von übernehmen.

    - Ist die XTCsid anfällig für eine SQL-Injection?

    Wenn das Session-Handling bei der Installation (oder nachträglich in der configure.php) auf mySQL gesetzt wurde, werden im Shop SQL-Abfragen ausgeführt, in der die übertragene XTCsid enthalten ist. Wir haben allerdings schon vor Jahren diese Option aus dem Installer entfernt und setzen seitdem auf dateibasiertes Session-Handling. In einem Shop haben wir jetzt aber testweise mal das Session-Handling auf mySQL gestellt und geprüft, ob wir auf Anhieb eine SQL-Injection herbeiführen können. Die ersten Versuche waren bisher nicht erfolgreich. Wir werden das aber nochmal genauer überprüfen.

    - Was geschieht weiter in Sachen Security?

    Wegen des kommenden 2.1er-Updates haben wir den Shop in den vergangenen Wochen erneut ausführlichen Scans unterzogen. Die Laufzeit eines umfassenden Scans beträgt übrigens immer gleich mehrere Tage. An der Spitze hat ein einzelner Scan auch schon mal über drei Wochen gedauert. Unsere Audits werden dabei mit jedem Mal weiter verfeinert und effizienter, so dass wir immer besser potenzielle Schwachstellen erkennen. So sind wir auch bei diesem Durchlauf wieder auf einige Stellen gestoßen, die es durchaus wert sind zusätzlich geschützt zu werden. In den kommenden 1-2 Wochen wird es darum ein Security-Update geben, in dem wir nun auch die Verbesserungsvorschläge aus diesem Thread einarbeiten möchten.


    Wir sprechen hier oft von Sicherheitsproblemen. Es ist wichtig zu verstehen, dass es sich dabei um Stellen im Shop handelt, die wir lediglich für potenziell gefährdet halten und die wir deshalb vorsichtshalber weiter absichern. In aller Regel geht von diesen Schwachstellen keine akute Gefahr aus. Bei unseren Tests finden wir auch nur selten Wege diese Schwachstellen auszunutzen. Dennoch besteht immer die Gefahr, dass ein anderer schlauer ist als man selbst. Deshalb wollen wir bei diesen Dingen lieber zu früh als zu spät reagieren. Ich hoffe, wir konnten hiermit für etwas mehr Aufklärung sorgen.
     
  2. Avenger

    Avenger G-WARD 2012/13/14/15

    Registriert seit:
    26. April 2011
    Beiträge:
    4.771
    Danke erhalten:
    1.478
    Danke vergeben:
    89
    Aber warum macht Ihr dann überhaupt solche Filter????

    Kostet nur Arbeit und Zeit.

    Und verführt Leute wie mich, sich in Sicherheit zu wähnen.

    Da wäre die Aussage: "Ihr müsst selbst für die Sicherheit sorgen" besser angebracht.

    Aber dafür habt Ihr ja den Input-Filter, der genau solche XSS-Angriffe entfernt (zumindest entfernen soll). :cool:

    Man sollte aber dann die Regeln für Front-End und Admin trennen, und nur die ausführen, die im jeweiligen Kontext notwendig sind....

    Macht ja keinen Sinn, im Front-End die Regeln für den Admin zu prüfen, und umgekehrt....

    Auch wenn die Zeit vernachlässigbar ist: viel wenig Zeit, macht sich auch bemerkbar. :D

    Ich weiß nicht....

    Im Falle der SQL-Injections meine ich, dass man das durchaus machen kann, weil die so signifikant sind.

    Und äußerst unwahrscheinlich in echten Nutzdaten auftreten werden.

    Und wenn, dann höchstens im Englischen, wobei dort max. die Prüfung auf "select" ein mögliches Problem sein sollte.

    Aber durch eine intelligentere Prüfung als String-Vergleich (nämlich mit regulären Ausdrücken) kann man auch das sicher eindeutig klären.

    Ich bin dabei, in dem Fall auch noch eine eMail-Benachrichtigung über einen stattfindenden SQL-Injection-Angriff an den Admin zu senden...
     
  3. Avenger

    Avenger G-WARD 2012/13/14/15

    Registriert seit:
    26. April 2011
    Beiträge:
    4.771
    Danke erhalten:
    1.478
    Danke vergeben:
    89
    Der Abdel Nadir hat den marmorkamin-Shop jetzt noch mal gescanned,und als "dicht" vorgefunden...

    Er will (kostenlos) auch noch mal eine paar andere SQL-Injections versuchen.

    Der ist also wirklich eher von der kooperativen Sorte, wenn man bedenkt, was er alles hätte anstellen können....
     
  4. pommes

    pommes Aktives Mitglied

    Registriert seit:
    8. Dezember 2013
    Beiträge:
    26
    Danke erhalten:
    4
    Danke vergeben:
    1
    Moin moin zusammen,
    was hast Du bei Marmorkamin gemacht, dass er nun "dicht" ist ?
    Kannst Du hierfür eine kurze Anleitung geben?

    schönen Gruß
    Thomas
     
  5. Anonymous

    Anonymous Erfahrener Benutzer

    Registriert seit:
    26. April 2011
    Beiträge:
    993
    Danke erhalten:
    208
    Danke vergeben:
    100
    Mir stellt sich dennoch die Frage wie er ausgerechnet auf den Shop von Achim gekommen ist. Ist der ein passiver Mitleser hier im Forum?
     
  6. Avenger

    Avenger G-WARD 2012/13/14/15

    Registriert seit:
    26. April 2011
    Beiträge:
    4.771
    Danke erhalten:
    1.478
    Danke vergeben:
    89
    Die versuchen halt ihr Glück bei Shops, wo das evtl. funktionieren könnte,,,

    Gibt ja gerade wieder entsprechende Beobachtungen.

    Der Versuch fand ja statt, bevor der Thread hier existierte.
     
  7. Avenger

    Avenger G-WARD 2012/13/14/15

    Registriert seit:
    26. April 2011
    Beiträge:
    4.771
    Danke erhalten:
    1.478
    Danke vergeben:
    89
    Der Standard-Gambio Shop ist wohl "dicht"...

    Und meinen "SQL-Injection-Filter" habe ich aktiviert----
     
  8. Manni_HB

    Manni_HB G-WARD 2012/13/14/15

    Registriert seit:
    26. April 2011
    Beiträge:
    9.098
    Danke erhalten:
    1.540
    Danke vergeben:
    909
    Ort:
    Bremen
    Wie kann man denn die Ergebnisse dieses "Vorfalls" zusammenfassen?

    • Was muss beachtet werden, wenn man selber Scripte baut?
     
  9. Dennis (MotivMonster.de)

    Dennis (MotivMonster.de) G-WARD 2013/14/15/16

    Registriert seit:
    22. September 2011
    Beiträge:
    30.947
    Danke erhalten:
    6.089
    Danke vergeben:
    1.078
    Beruf:
    Mann für alles :)
    Ort:
    Weilburg
    Das eingabefelder immer geprüft werden und nur das durchlassen wofür sie gedacht sind. :D
    Euer BotTrap sollte normal seinen crawler blocken können oder gar autom. machen.
     
  10. Avenger

    Avenger G-WARD 2012/13/14/15

    Registriert seit:
    26. April 2011
    Beiträge:
    4.771
    Danke erhalten:
    1.478
    Danke vergeben:
    89
    Vertraue Nichts und Niemand, außer Dir selbst....

    Jeder ist seines Glücks Schmied....
     
  11. Avenger

    Avenger G-WARD 2012/13/14/15

    Registriert seit:
    26. April 2011
    Beiträge:
    4.771
    Danke erhalten:
    1.478
    Danke vergeben:
    89
    Nicht unbedingt...

    Man erkennt den eigentlich nur am "USER-AGENT"-String.

    Und den kann der Crawler beliebig setzen.
     
  12. Avenger

    Avenger G-WARD 2012/13/14/15

    Registriert seit:
    26. April 2011
    Beiträge:
    4.771
    Danke erhalten:
    1.478
    Danke vergeben:
    89
  13. Anonymous

    Anonymous Erfahrener Benutzer

    Registriert seit:
    10. August 2012
    Beiträge:
    1.554
    Danke erhalten:
    455
    Danke vergeben:
    96
    Abgesehen von Leuten die wissen was sie tun, sollte der Rest nicht aus Neugier mal dort vorgestellte Tools testen - wenn dort irgendwelche Backdoors integriert sind wird man ganz schnell selbst zum Opfer ;)
     
  14. Dennis (MotivMonster.de)

    Dennis (MotivMonster.de) G-WARD 2013/14/15/16

    Registriert seit:
    22. September 2011
    Beiträge:
    30.947
    Danke erhalten:
    6.089
    Danke vergeben:
    1.078
    Beruf:
    Mann für alles :)
    Ort:
    Weilburg
    blockt das teil nur ip oder auch wenn zu oft in kurzer zeit von der selben ip abgefragt wird?
     
  15. Manni_HB

    Manni_HB G-WARD 2012/13/14/15

    Registriert seit:
    26. April 2011
    Beiträge:
    9.098
    Danke erhalten:
    1.540
    Danke vergeben:
    909
    Ort:
    Bremen
    Ja ... das ist schon sehr schön! :)
    Nur dachte ich da mehr daran, wie entsprechende Stellen im Code optimal sein müssen.
     
  16. Anonymous

    Anonymous Erfahrener Benutzer

    Registriert seit:
    19. Juni 2012
    Beiträge:
    4.831
    Danke erhalten:
    1.122
    Danke vergeben:
    947
    #196 Anonymous, 3. April 2014
    Zuletzt bearbeitet: 14. Juni 2018
    Hi Avenger,


    So einen Fehler schonmal mit deinem Filter gehabt?


    Warning: strpos(): Empty needle in /www/xxxxx/gx2/GProtector/GProtector.inc.php on line 99

    Edit:

    Konnte den Fehler beheben indem ich die IP Blacklist geleert habe. Ein eingeloggter Kunde hat ihn auf der checkout_confirmation verursacht - zumindest war es seine IP die da drin stand. Als erstes eine Leerzeile. Vermutlich konnte er dann jetzt nicht bestellenweil er ausgesperrt war? Also irgendwas scheint da noch nicht zu passen...