.MB: vorgefertigte Skripte, sicherheits lücke?

Guten Abend,

ich habe in Fachzeitschriften und auch hier grade eben gelesen, das templates und tools - JOOMLA - zum tempate erstellen, viel zuviel an zusätzen mit sich bringen. je nach anzahl der Code-Zeilen, mehr Sicherheitslücken da sind.

JSON, JQUERRY, usw. sind Frameworks. Zählen die in diesem Sinn auch dazu?

Ich habe mich noch nicht damit beschäftigt und würde es nur ungern tun wollen. aber was muss, das muss.

LG

MB

  1. @@.MB

    ich habe in Fachzeitschriften und auch hier grade eben gelesen, das templates und tools - JOOMLA - zum tempate erstellen, viel zuviel an zusätzen mit sich bringen. je nach anzahl der Code-Zeilen, mehr Sicherheitslücken da sind.

    JSON, JQUERRY, usw. sind Frameworks.

    Nein. JSON ist ein Datenformat, jQuery ist eine Bibliothek, Joomla! ist ein CMS.

    LLAP 🖖

    --
    „Wir haben deinen numidischen Schreiber aufgegriffen, o Syndicus.“
    „Hat auf dem Forum herumgelungert …“
    (Wachen in Asterix 36: Der Papyrus des Cäsar)
  2. Hallo,

    ich habe in Fachzeitschriften und auch hier grade eben gelesen, das templates und tools - JOOMLA - zum tempate erstellen, viel zuviel an zusätzen mit sich bringen. je nach anzahl der Code-Zeilen, mehr Sicherheitslücken da sind.

    es ist fast schon eine Art Naturgesetz, dass jedes Stück Software, das über die Komplexität eines "Hello World"-Beispiels hinausgeht, auch eine gewisse Zahl von unentdeckten Fehlern und Schwächen enthält. Dasliegt einfach daran, dass man bei einer gewissen Komplexität nicht mehr wirklich jeden Einzelfall testen oder analytisch abfrühstücken kann, sondern verallgemeinern und/oder zusammenfassen muss. Und dabei kann man schon mal den einen oder anderen Sonderfall übersehen, der zum Problem werden kann.

    Und unter Fachleuten gibt es einen netten Kalauer:
    Sei n die Anzahl der unentdeckten Bugs einer Software, dann gilt immer: n = n+1
    Mit anderen Worten: Es ist immer einer mehr, als du glaubst.

    JSON, JQUERRY, usw. sind Frameworks.

    Nein. JSON ist ein Datenaustauschformat, das sich an die Javascript-Syntax anlehnt; JQuery (bitte nur mit einem 'r') ist eine Javascript-Bibliothek, meinetwegen auch ein Framework.

    Zählen die in diesem Sinn auch dazu?

    Ja und nein. Für JQuery gilt dasselbe wie für jede Javascript-Anwendung: Sie läuft auf dem Client-Rechner. Für den Webserver ergibt sich daraus also keine direkte Bedrohung. Dafür aber vielleicht für die Funktion der Anwendung auf der Clientseite, oder für die Privatsphäre des Nutzers. Ja, Sicherheit hat in der IT viele unterschiedliche Facetten.

    Ich habe mich noch nicht damit beschäftigt und würde es nur ungern tun wollen. aber was muss, das muss.

    Ein paar grundsätzliche Verhaltensregeln und ein kleines bisschen antrainierte Paranoia genügen eigentlich schon, wenn man mal den Blick für die Zusammenhänge hat.

    So long,
     Martin

    1. Erst mal herzlichen Dank für AW

      JSON, JQUERRY, usw. sind Frameworks.

      Nein. JSON ist ein Datenaustauschformat, das sich an die Javascript-Syntax anlehnt; JQuery (bitte nur mit einem 'r') ist eine Javascript-Bibliothek, meinetwegen auch ein Framework.

      Gut. Gut meine mitstreiter lernen oberflächlich JQue(r)y. Ich möchte mich nicht zwangsweise damit rumschlagen.

      Ja und nein. Für JQuery gilt dasselbe wie für jede Javascript-Anwendung: Sie läuft auf dem Client-Rechner. Für den Webserver ergibt sich daraus also keine direkte Bedrohung. Dafür aber vielleicht für die Funktion der Anwendung auf der Clientseite, oder für die Privatsphäre des Nutzers. Ja, Sicherheit hat in der IT viele unterschiedliche Facetten.

      wenn ich also ne kleine webseite aufziehn will reicht das ohne zusatz z.B. Jquery?

      grüße MB

      1. Tach,

        wenn ich also ne kleine webseite aufziehn will reicht das ohne zusatz z.B. Jquery?

        eine Webseite braucht kein jQuery oder Javascript. Für jemanden, der das Programmieren oder eine Sprache neu lernt, würde ich empfehlen immer zuerst auf Frameworks und Helfer zu verzichten; das hilft zu verstehen, was das Framework eigentlich tut, wo ein Einsatz hilfreich ist und wo nicht.

        mfg
        Woodfighter

        1. Moin,

          eine Webseite braucht kein jQuery oder Javascript. Für jemanden, der das Programmieren oder eine Sprache neu lernt, würde ich empfehlen immer zuerst auf Frameworks und Helfer zu verzichten; das hilft zu verstehen, was das Framework eigentlich tut, wo ein Einsatz hilfreich ist und wo nicht.

          ganz genau: Erst sollte man mal laufen lernen, bevor man aufs Fahrrad steigt.

          Und später wird man bei so manchem Tool oder Framework feststellen: Als Anfänger mag man's nicht einsetzen, weil man es nicht versteht; als Experte mag man es nicht einsetzen, weil man es versteht.

          An JQuery stört mich zum Beispiel, dass es oft gedankenlos und reflexartig eingesetzt wird - und sei es nur für eine einzige Kleinigkeit, die man mit zwei Zeilen Plain-Vanilla-Javascript ebenso einfach, vielleicht sogar einfacher gelöst hätte.

          So long,
           Martin

    2. Hallo Martin,

      es ist fast schon eine Art Naturgesetz, dass jedes Stück Software, das über die Komplexität eines "Hello World"-Beispiels hinausgeht, […]

      Warum schränkst du das so ein? Hast du eine Ahnung, wie komplex ein Compiler oder ein Interpreter sind? ;-) Geschweige denn ein Browser.

      LG,
      CK

      1. Hi,

        es ist fast schon eine Art Naturgesetz, dass jedes Stück Software, das über die Komplexität eines "Hello World"-Beispiels hinausgeht, […]

        Warum schränkst du das so ein? Hast du eine Ahnung, wie komplex ein Compiler oder ein Interpreter sind? ;-) Geschweige denn ein Browser.

        ja, aber ich wollte ja nicht auf die Bugs von Compilern oder Browsern hinaus, sondern auf die des eigentlichen zu erstellenden Programms. Wenn es so einfach gestrickt ist, dass man systematisch alle möglichen Eingaben testen kann (und das wäre im Fall des klassischen Hello-World-Beispiels ein Nullvektor), dann kann man auch mit hinreichender Sicherheit behaupten, das Programm an sich sei fehlerfrei.
        Was das erforderliche Drumherum in der Praxis anstellt, ist nochmal eine ganz andere Baustelle.

        So long,
         Martin

        1. Hallo Martin,

          es ist fast schon eine Art Naturgesetz, dass jedes Stück Software, das über die Komplexität eines "Hello World"-Beispiels hinausgeht, […]

          Warum schränkst du das so ein? Hast du eine Ahnung, wie komplex ein Compiler oder ein Interpreter sind? ;-) Geschweige denn ein Browser.

          ja, aber ich wollte ja nicht auf die Bugs von Compilern oder Browsern hinaus, sondern auf die des eigentlichen zu erstellenden Programms.

          Worauf du hinaus wolltest, war mir klar, deshalb ja auch die Frage, warum du dich so einschränkst.

          Wenn es so einfach gestrickt ist, dass man systematisch alle möglichen Eingaben testen kann (und das wäre im Fall des klassischen Hello-World-Beispiels ein Nullvektor), dann kann man auch mit hinreichender Sicherheit behaupten, das Programm an sich sei fehlerfrei.

          Das haben wir um Studium mal versucht. Nein, das ist nicht möglich. Allein schon nur die Ausgabe von „Hello World“ ist sehr komplex. Und wenn wir in die Hochsprachen schauen, wird es noch kritischer. Die einzige Möglichkeit das nachzuweisen (sic!) ist vorauszusetzen, dass ausser dem selbst geschriebenen Quellcode (also auch die Standard-Bibliothek und so weiter) alles verifiziert ist.

          LG,
          CK

          1. Tach,

            Das haben wir um Studium mal versucht. Nein, das ist nicht möglich. Allein schon nur die Ausgabe von „Hello World“ ist sehr komplex. Und wenn wir in die Hochsprachen schauen, wird es noch kritischer. Die einzige Möglichkeit das nachzuweisen (sic!) ist vorauszusetzen, dass ausser dem selbst geschriebenen Quellcode (also auch die Standard-Bibliothek und so weiter) alles verifiziert ist.

            … inklusive der bugfreien Hardware …

            mfg
            Woodfighter

  3. Tach,

    ich habe in Fachzeitschriften und auch hier grade eben gelesen, das templates und tools - JOOMLA - zum tempate erstellen, viel zuviel an zusätzen mit sich bringen. je nach anzahl der Code-Zeilen, mehr Sicherheitslücken da sind.

    wie die anderen schon gesagt haben, je mehr Code da ist, desto mehr Bugs werden sein; die größeren Projekte haben allerdings den Vorteil, dass auch mehr Augen nach den Bugs suchen und dass möglicherweise ein Patch für einen Zero-Day schon da ist, bevor dein System angegriffen wird. Als Anfänger wirst du Fehler machen und Sicherheitslücken einbauen, und du wirst dann vielleicht erst von diesen Lücken erfahren, nachdem sie jemand ausgenutzt hat (die Menge an „personalisierten“ Angriffen ist zwar insgesamt geringer, aber dafür meist desaströser) und dann bist du auch noch derjenige, der deinen vermutlich schrecklich aussehenden Code (alter Code sieht immer schrecklich aus und die Antworten auf die Fragen, welcher Idiot sich das hier ausgedacht hat und was er sich dabei gedacht hat, waren leider schon öfter ich und offenbar nicht viel) debuggen und den/die Fehler finden musst.

    mfg
    Woodfighter

    1. Tach!

      und dann bist du auch noch derjenige, der deinen vermutlich schrecklich aussehenden Code (alter Code sieht immer schrecklich aus und die Antworten auf die Fragen, welcher Idiot sich das hier ausgedacht hat und was er sich dabei gedacht hat, waren leider schon öfter ich und offenbar nicht viel) debuggen und den/die Fehler finden musst.

      Ach du warst das? Und ich fragte mich immer, wer aus meinem verständlich geschriebenen und gut dokumentierten Code *hust* solch eine Katastrophe gemacht hat, während ich mal ein paar Tage nicht draufgeschaut habe.

      Aber mal im Ernst, Dokumentieren ist eine Kunst, die noch weniger beherrscht wird als das Programmieren. Man muss ja in den Kommentaren nicht das Offensichtliche beschreiben, sondern was man sich dabei gedacht hat, warum man die Lösung so implementiert hat und nicht doch anders, womöglich noch abweichend vom Üblichen.

      dedlfix.

      1. Hallo,

        Aber mal im Ernst, Dokumentieren ist eine Kunst, die noch weniger beherrscht wird als das Programmieren.

        das ist leider wahr.

        Man muss ja in den Kommentaren nicht das Offensichtliche beschreiben, sondern was man sich dabei gedacht hat, warum man die Lösung so implementiert hat und nicht doch anders, womöglich noch abweichend vom Üblichen.

        ACK. Das A und O beim Dokumentieren ist nicht, zu beschreiben, WAS der Code tut, sondern WARUM. Dazu gehören, wie du schon sagst, ein paar Worte dazu, was man sich als Programmierer bei dieser konkreten Implementierung gedacht hat, aber auch Zusammenhänge - etwa das gewünschte Zusammenspiel verschiedener Funktionen oder Objekte.
        Genau das vermisse ich auch oft in Dokumentationen "professioneller" Bibliotheken und Frameworks: Da wird jedes einzelne Element, jedes API genau beschrieben, aber der Zusammenhang existiert oft nur in den Köpfen der Programmierer.

        Und das gilt IMO sowohl für Kommentare im Code, als auch für eine eigenständige Dokumentation.

        Ciao,
         Martin

        1. Tach!

          Genau das vermisse ich auch oft in Dokumentationen "professioneller" Bibliotheken und Frameworks: Da wird jedes einzelne Element, jedes API genau beschrieben, aber der Zusammenhang existiert oft nur in den Köpfen der Programmierer.

          Ich hab auch schon unbrauchbare Dokumentation für Anwender gesehen. Die ist einfach nur da, weil "Dokumentation" im Pflichtenheft stand. Dokumentation kostet nur und bringt kein Geld, und da spart man auch gern mal. Der Programmierer denkt sich, dass eine solche ja sowieso nicht nötig sei, das Programm bedient sich ja doch ganz einfach. Dumm nur, dass nur er die Zusammenhänge im Hintergrund kennt.

          Da gibt es zu einem Feld, das mit "Telefonnummer:" beschriftet ist, sinngemäß nicht mehr und nicht weniger als: "Tragen Sie in dieses Feld die Telefonnummer ein." - Ach! Na das hätte ich ja jetzt nicht erwartet! Ein Feld, das mit Telefonnummer beschriftet ist, soll mit einer Telefonnummer gefüllt werden. Wie gut, dass mir das jemand gesagt hat. Meine eigentliche Frage ist aber, in welchem Format ich sie da eintragen soll, nur die Nebenstelle oder die vollständige Nummer, und wenn letzteres, als E.164 oder so wie man sie wählt? Das ist besonders wichtig, wenn das Programm die Nummer selbst verarbeitet und sie nicht nur in die Datenbank wandert, damit später ein Mensch sie lesen kann.

          Nett sind auch solche Rückfragen wie "Sind Sie sicher?" - Danke der Nachfrage, aber wessen soll ich mir sicher sein? Der Programmierer weiß natürlich in welchem Zusammenhang er die Rückfrage stellt. Aber der Anwender? Vielleicht hat er unbemerkt irgendwas angeklickt, was er gar nicht klicken wollte, beispielsweise genau neben das eigentliche Ziel oder unbewusst irgendwohin. Da kommt die Frage dann ohne Kontext daher und ist schwer einzuordnen.

          dedlfix.

          1. Hi,

            Da gibt es zu einem Feld, das mit "Telefonnummer:" beschriftet ist, sinngemäß nicht mehr und nicht weniger als: "Tragen Sie in dieses Feld die Telefonnummer ein."

            da würde ich als Tester ganz ketzerisch fragen: Wessen Telefonnummer?
            So ähnlich wie bei Kontaktformularen, die zwingend die Angabe einer Telefonnummer fordern. Da trage ich dann gern die Telefonnummer des Anbieters aus dessen eigenem Impressum ein, denn meine geht ihn zunächst mal nichts an.

            Ach! Na das hätte ich ja jetzt nicht erwartet! Ein Feld, das mit Telefonnummer beschriftet ist, soll mit einer Telefonnummer gefüllt werden. Wie gut, dass mir das jemand gesagt hat. Meine eigentliche Frage ist aber, in welchem Format ich sie da eintragen soll, nur die Nebenstelle oder die vollständige Nummer, und wenn letzteres, als E.164 oder so wie man sie wählt?

            Auch ein interessanter Aspekt, stimmt.

            Nett sind auch solche Rückfragen wie "Sind Sie sicher?" - Danke der Nachfrage, aber wessen soll ich mir sicher sein? Der Programmierer weiß natürlich in welchem Zusammenhang er die Rückfrage stellt. Aber der Anwender?

            Meistens sollte er wissen, was er tut, aber ...

            Vielleicht hat er unbemerkt irgendwas angeklickt, was er gar nicht klicken wollte, beispielsweise genau neben das eigentliche Ziel oder unbewusst irgendwohin. Da kommt die Frage dann ohne Kontext daher und ist schwer einzuordnen.

            ... das ist natürlich ein guter Einwand.

            Schön fand ich auch die Rückfrage in einer sehr alten Programmiersoftware für Siemens SPSen (muss so in den 90er Jahren gewesen sein:

            Alle Bausteine nicht löschen?
                 [ Ja ]      [Nein]
            

            Das ist doch mal 'ne interessante Frage!

            So long,
             Martin

            1. Tach!

              Da gibt es zu einem Feld, das mit "Telefonnummer:" beschriftet ist, sinngemäß nicht mehr und nicht weniger als: "Tragen Sie in dieses Feld die Telefonnummer ein."

              da würde ich als Tester ganz ketzerisch fragen: Wessen Telefonnummer?
              So ähnlich wie bei Kontaktformularen, die zwingend die Angabe einer Telefonnummer fordern. Da trage ich dann gern die Telefonnummer des Anbieters aus dessen eigenem Impressum ein, denn meine geht ihn zunächst mal nichts an.

              Schon klar. In meinem Fall war es ein technisches System, und da ergab sich aus dem Zusammenhang, dass da die zum aktuellen Datensatz passende Telefonnummer einzutragen ist, damit das gewünschte Ergebnis erreicht wird. Nur das Format war eben nicht klar.

              dedlfix.

            2. Hi,

              Schön fand ich auch die Rückfrage in einer sehr alten Programmiersoftware für Siemens SPSen (muss so in den 90er Jahren gewesen sein:

              Alle Bausteine nicht löschen?
                   [ Ja ]      [Nein]
              

              Auch immer wieder schön:

              Soll die Aktion abgebrochen werden?
              [OK] [Abbruch]
              

              cu,
              Andreas a/k/a MudGuard

              1. Moin!

                Soll die Aktion abgebrochen werden?
                [OK] [Abbruch]
                

                Dabei gibt es doch extra den Dialog vom Typ "vbYesNo".

                Jörg Reinholz

  4. Aloha ;)

    ich habe in Fachzeitschriften und auch hier grade eben gelesen, das templates und tools - JOOMLA - zum tempate erstellen, viel zuviel an zusätzen mit sich bringen. je nach anzahl der Code-Zeilen, mehr Sicherheitslücken da sind.

    Bei Joomla!, wordpress und Konsorten kommt noch etwas dazu, was sehr viel gefährlicher ist, als die bisher angesprochenen Sicherheitslücken, die naturgegeben in jedem Stück Code oder in jeder Bibliothek auftauchen: bösartige Drittanbieter-Software.

    Während wir bei gängigen Tools (in den meisten Fällen begründeterweise, vor allem im OpenSource-Bereich) davon ausgehen können, dass uns der Ersteller des Tools nichts Böses will, ist das bei vielen Drittanbieter-Plugins für populäre Systeme nicht gegeben. Da wird schonmal Schadcode eingeschleust, wenn man nicht ganz genau aufpasst. Die Täter machen sich zunutzen, dass die Opfer dem Grundsystem vertrauen und das Vertrauen auf die installierbaren Plugins blindlings übertragen; niemand (verallgemeinernd, Ausnahmen bestätigen die Regel) forstet sich durch den Code eines Plugins (da kann mans ja schon fast selbst schreiben) und die meisten CMS-Admins haben ohnehin keine Ahnung von Code (wozu sonst ein CMS), sodass einfach installiert wird, was vordergründig tut, was es soll.

    Da hilft nur, sich entweder den Code anzuschauen (man muss nicht jede Zeile verstanden haben um zu sehen, ob die ausgeschriebene Funktionalität des Plugin nur Fassade ist), oder auch hier sorgsam nach vertrauenswürdigen Quellen zu suchen. Die Versuchung, eine eierlegende Wollmilchsau von irgendwo zu installieren, wenn man keine aus vertrauenswürdigen Quellen gefunden hat, ist dennoch immens groß.

    Grüße,

    RIDER

    --
    Camping_RIDER a.k.a. Riders Flame a.k.a. Janosch Zoller Erreichbar manchmal im Self-TS (ts.selfhtml.org) oder sonst - wenn online - auf dem eigenen TeamSpeak-Server (fritz.campingrider.de) oder unter: # Facebook # Twitter # Steam # YouTube # Self-Wiki # ch:? rl:| br:> n4:? ie:% mo:| va:) js:) de:> zu:) fl:( ss:| ls:[
    1. Hallo

      Während wir bei gängigen Tools (in den meisten Fällen begründeterweise, vor allem im OpenSource-Bereich) davon ausgehen können, dass uns der Ersteller des Tools nichts Böses will, ist das bei vielen Drittanbieter-Plugins für populäre Systeme nicht gegeben. Da wird schonmal Schadcode eingeschleust, wenn man nicht ganz genau aufpasst. Die Täter machen sich zunutzen, dass die Opfer dem Grundsystem vertrauen und das Vertrauen auf die installierbaren Plugins blindlings übertragen;

      Das kann man garnicht oft und deutlich genug sagen. Der OP fragt, wie wohl jeder Unbedarfte, zuerst nach den Gefahren, denen man sich durch fehlerhaft geschriebene Software, die man einsetzt, aussetzt. Der Gedanke, dass einem bösartige Software untergeschoben wird, die man selbst bewusst installiert, muss einem ja auch erst einmal kommen.

      Nicht der Angriff durch eine vorhandene Sicherheitslücke des Betriebssystems, nicht der per Email oder bei einem Webseitenbesuch untergeschobene Schadcode, nein, das bewusst ausgewählte und installierte Plugin mit der schon seit langem gewünschten Funktionserweiterung des CMS' auf der eigenen Website kann es sein, das einen dahin reitet, wo man mit an Sicherheit grenzender Wahrscheinlichkeit nicht sein mag.

      Es ist eine durchaus schwierige Abwägung, zu entscheiden, ob man eigenen oder fremden Code einsetzt. Ist man selbst zum Programmieren ohne klaffende Sicherheitslöcher fähig? Kann man dem Anbieter von fremdem Code vertrauen? Kann man fremden und eigenen Code verstehend lesen oder [1] hat man jemanden, dem man das als alternativer oder zusätzlicher Kontrollinstanz zutraut? Gibt es eventuell Berichte von Code Reviews oder von gefundenen Fehlern? Ist man sich dessen bewusst, dann man sich die regelmäßige Prüfung auf zukünftige Fehlerbehebungen ans Bein bindet, binden muss? Ist man sich der Tatsache bewusst, dass es geschehen kann, dass Softwareprodukte irgendwann nicht mehr gepflegt werden und man diese dann gegen andere, weiterhin gepflegte Produkte austauschen sollte?

      Tschö, Auge

      --
      Es schimmerte ein Licht am Ende des Tunnels und es stammte von einem Flammenwerfer.
      Terry Pratchett, „Gevatter Tod“

      1. Noch besser als „oder“ ist an dieser Stelle „und“. ↩︎