Ankündigung

Einklappen
Keine Ankündigung bisher.

PHP soll angeblich per Definition unsicher sein - Meinung eines einzelnen?

Einklappen

Neue Werbung 2019

Einklappen
X
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

  • PHP soll angeblich per Definition unsicher sein - Meinung eines einzelnen?

    Hallo Leute,

    direkt mal vorne weg: Ich hoffe, dass ich das richtige Board für mein Thema gewählt habe. Schließlich geht es hier in erster Linie um einen Meinungs- und Erfahrungsaustausch, nicht jedoch um ein konkrete PHP-Problemstellung.

    Mich hatte neulich jemand in einem anderen Forum immer wieder darauf angesprochen, wie unsicher doch PHP sei. Das läge laut seiner Meinung an den vielen Sicherheitslöchern die es gibt und an den vielen Schmu den PHP zulässt.
    Nun ja, der Mensch ist anscheinend ein Python Entwickler, vielleicht rührt daher auch seine Meinung. Denn bei Python gibt es fest verankerte Konventionen, also Einrückungstiefe und solche Scherze, und wenn die nicht stimmt, dann kompiliert der Compiler nicht. Das ist laut seiner Meinung ein Grund, warum Python wesentlich sicherer sei als PHP. Und auch wenn ich das richtig umrissen habe, der einzige gute Grund, warum das so sei. Andere genannte Gründe waren noch:
    - Python sei sicherer programmiert worden
    - es verwendet nicht jedes Skript Kiddie, das froh ist, gerade mal einen von Sicherheitslücken klaffenden Webserver aufsetzen zu können, um dann die eigenen Erfolge in einem Blog mit der zu teilen
    - als Beispiel wurde der PHP 5.3 Debian (Bug-)fix genannt. Leider ist das nicht nachvollziehbar, weil man von diesen Bug keine aktuellen Berichte mehr findet

    Nun meine Meinung dazu: Ich denke nicht, dass PHP per Definition oder Design unsicher sei. Das würde ja bedeuten, dass alle anderen Skriptsprachen wie Perl, Python, Tcl, etc. genauso unsicher seien. Denn soviel ich weiß, wurde ein Großteil der Skriptsprachen mit C programmiert.
    Man kann in PHP viel unsicheren Mist erzeugen. Das liegt aber nicht per se an der Programmiersprache, sondern eher an der unsicheren Konfiguration oder an der unsicheren Programmierung des Anwendungsentwicklers. Eine Prorammiersprache kann schließlich nichts für eine unsichere Behandlung. Wenn ich bei mir zu Hause die Haustür offen lasse und mich dann beschwere, dass eingebrochen wurde, dann ist doch auch nicht die Haustür schuld daran.

    Aber mal unter der wage Annahme, es sei wirklich so, googelte ich nach "PHP ist unsicher". Die einzigen sinnvollen und halbwegs noch heute aktuellen Suchergebnisse, die ich fand, sind diese hier:
    https://www.heise.de/security/meldun...n-2774343.html
    https://www.thewebhatesme.com/entwic...hp-frameworks/
    https://entwickler.de/online/php-sic...-2-136924.html

    Diese Recherche bekräftigt eigentlich nur meine Aussagen und entkräftigt deutlich die Meinung der Kontra Partei. Außerdem sei auch noch erwähnt, dass viele Sicherheitslöcher bereits durch ein neues Major Release gefixt werden, weil man in einer neueren PHP 5.x oder PHP 7.x Version es komplett anders löst, was die alten Sicherheitslöcher fixt, weil dieser Code schlicht und ergreifend so nicht mehr vorhanden ist.


    Was meint ihr dazu oder wie ist in dahingehend eure Erfahrung? Ich bezweifle jedenfalls stark, dass PHP per se unsicher sei. Eine kurze Recherche bestätigte mir das auch.



    MFG

    derwunner


    Edit: Bitte versteht mich nicht falsch, es geht mir dabei nicht darum, diesen netten helfenden Menschen bloß zu stellen, sondern viel mehr darum diese Frage auf sachlicher Ebene ein für alle mal zu klären. Allein schon aus Eigeninteresse.

  • #2
    Ich bringe einmal ein Zitat:

    "Just because the language tries to forbid bad thing doesn't mean you can't do them" (so in etwa...)

    Also OpenSSL wurde in C programmiert und Heartbleed war doch sehr schlimm, nicht?

    Die Sprache ist so sicher, wie die Software, die du mit ihr programmierst. Solche Diskussioenn sind sinnlos, weil das Argument schon zeigt, dass dem Gegenüber die Sachlichkeit fehlt.
    [URL="https://github.com/chrisandchris"]GitHub.com - ChrisAndChris[/URL] - [URL="https://github.com/chrisandchris/symfony-rowmapper"]RowMapper und QueryBuilder für MySQL-Datenbanken[/URL]

    Kommentar


    • #3
      Zitat von derwunner Beitrag anzeigen
      Mich hatte neulich jemand in einem anderen Forum immer wieder darauf angesprochen, wie unsicher doch PHP sei. Das läge laut seiner Meinung an den vielen Sicherheitslöchern die es gibt und an den vielen Schmu den PHP zulässt.
      Nun ja, der Mensch ist anscheinend ein Python Entwickler, vielleicht rührt daher auch seine Meinung. Denn bei Python gibt es fest verankerte Konventionen, also Einrückungstiefe und solche Scherze, und wenn die nicht stimmt, dann kompiliert der Compiler nicht. Das ist laut seiner Meinung ein Grund, warum Python wesentlich sicherer sei als PHP. Und auch wenn ich das richtig umrissen habe, der einzige gute Grund, warum das so sei.
      Die Einrückungstiefe bei Python ist keine Konvention, sondern eine syntaktische Notwendigkeit. Das Weglassen der Einrückung hat in etwa den gleichen Effekt, wie das Weglassen von geschweiften oder runden Klammern bei PHP.

      Zitat von derwunner Beitrag anzeigen
      Andere genannte Gründe waren noch:
      - Python sei sicherer programmiert worden
      Da ist sicher was dran. Der PHP-VM-Code ist unterentwickelt im Vergleich zu den großen VMs (V8, Python, JVM, BEAM, etc).

      Zitat von derwunner Beitrag anzeigen
      - es verwendet nicht jedes Skript Kiddie, das froh ist, gerade mal einen von Sicherheitslücken klaffenden Webserver aufsetzen zu können, um dann die eigenen Erfolge in einem Blog mit der zu teilen
      Erfolg zieht Pöbel an.
      - Windows

      Zitat von derwunner Beitrag anzeigen
      - als Beispiel wurde der PHP 5.3 Debian (Bug-)fix genannt. Leider ist das nicht nachvollziehbar, weil man von diesen Bug keine aktuellen Berichte mehr findet
      Auch dieser Coding-Horror-Bericht hat keine praktische Relevanz mehr.


      Der Unterschied ist vor allem, dass Python tatsächliche Konventionen hat (PEP etc), die weit über das von PHP bekannte PSR hinaus gehen und für viele Pythonistas eine wichtige Entscheidungshilfe bei der Erstellung von Bibliotheken und Frameworks sind. Die Sprache selbst ist da gar nicht so der entscheidende Faktor.

      https://www.python.org/dev/peps/pep-0020/


      Zudem gibt es in der Python Community den (nicht ganz unumstrittenen) OneWayItShouldBe™ aka "the pythonic way of doing things".


      Zitat von derwunner Beitrag anzeigen
      Nun meine Meinung dazu: Ich denke nicht, dass PHP per Definition oder Design unsicher sei. Das würde ja bedeuten, dass alle anderen Skriptsprachen wie Perl, Python, Tcl, etc. genauso unsicher seien. Denn soviel ich weiß, wurde ein Großteil der Skriptsprachen mit C programmiert.
      Um hier direkt mal einzuhaken: Die Sicherheit einer Umgebung hängt maßgeblich an dessen Dokumentation. Bei Vanilla-PHP findest du schneller und häufiger Beispiele (Google), wie man etwas nicht machen sollte.

      Zitat von derwunner Beitrag anzeigen
      Man kann in PHP viel unsicheren Mist erzeugen. Das liegt aber nicht per se an der Programmiersprache, sondern eher an der unsicheren Konfiguration oder an der unsicheren Programmierung des Anwendungsentwicklers.
      Und da jeder Entwickler irgendwann mal Anfänger war, gilt besonders diese Personengruppe an die Hand zu nehmen und ihr einen korrekten Weg aufzuzeigen.

      Du kannst in jeder Sprache unsichere Software schreiben. PHP ist in meinen Augen weit besser für die Erstellung von Webanwendungen geeignet, als die meisten kompilierenden Sprachen, inkl Java. Aber da kommt es immer drauf an, was du machen willst. Man kann PHP nicht für alles verwenden, weil es Szenarien gibt, in denen PHP nicht genug Performance bringt (heisst, wo InMemory-Capabilities gefragt sind). Und Java ist deswegen nicht für jede Problemstellung geeignet, weil es für kleinere Projekte zu umständlich, zu zeitaufwändig und damit ineffizient ist.

      Rails, Phoenix, Play und Django machen es super easy, ne Webanwendung zu ziehen, aber sind voll krampfig, wenn man die beschilderten Pfade verlassen möchte/muss. Und PHP ist meiner Erfahrung nach wesentlich schneller als Rails. Und ungefähr 100-10000mal langsamer als Play oder Phoenix, was vor allem am In-Memory-Handling liegt, wenn sich davon profitieren lässt...

      Kommentar


      • #4
        Ok, danke an alle für die informativen Beiträge. Thema ist somit geklärt, da wir festgestellt haben, dass die Behauptung blanker Unfug ist.

        Bis bald!

        Kommentar


        • #5
          Ich glaub ned, das er mit informativen Gegenargumenten zufrieden ist.

          Kommentar


          • #6
            Hallo!

            Ein Programm ist so sicher wie der Benutzer. Das größte Sicherheitsrisiko sitzt 60 cm vor dem Bildschirm. Wenn der Nutzer begierig auf alles klickt was man ihm vorsetzt kann man noch so sicher programmieren, es wird unsicher bleiben.

            Gruß, René

            Kommentar


            • #7
              Zitat von mumpel Beitrag anzeigen
              Ein Programm ist so sicher wie der Benutzer.
              Unsinn. Ein Programm ist so sicher wie dessen Programmierer das schafft es ohne Sicherheitsmängel zu erstellen. Das es keine 100%ige Sicherheit gibt wissen wir alle.
              PHP ist dafür nur ein Werkzeug von vielen. Gutes Werkzeug kann das Erstellen eines Programms und den Test erleichtern, mehr aber auch nicht.

              PHP-Klassen auf [URL="https://github.com/jspit-de"]github[/URL]

              Kommentar


              • #8
                Zitat von mumpel Beitrag anzeigen
                Hallo!

                Ein Programm ist so sicher wie der Benutzer. Das größte Sicherheitsrisiko sitzt 60 cm vor dem Bildschirm. Wenn der Nutzer begierig auf alles klickt was man ihm vorsetzt kann man noch so sicher programmieren, es wird unsicher bleiben.

                Gruß, René
                Wenn du von Prozesssicherheit sprichst, ja (also der Logik eines Ablaufes). Wenn du von Anwendungssicherheit sprichst (also dem Ausreissen aus einem gedachten Prozess), dann sitzt das Problem zwar immer noch 60cm vor dem Bildschirm, einfach im Entwicklerbüro.
                [URL="https://github.com/chrisandchris"]GitHub.com - ChrisAndChris[/URL] - [URL="https://github.com/chrisandchris/symfony-rowmapper"]RowMapper und QueryBuilder für MySQL-Datenbanken[/URL]

                Kommentar

                Lädt...
                X