Es ist nicht so sehr so, dass PHP selbst Sicherheitsprobleme hat (vorausgesetzt, es werden Sicherheitsupdates benötigt), da es eine Menge populärer PHP-basierter Software mit weit verbreiteten Sicherheitsproblemen gibt. Sie könnten PHP dafür verantwortlich machen, dass es eine Sprache ist, die Ihnen genug Seil gibt, um sich selbst zu ersticken, aber das eigentliche Problem ist, wie häufig anfälliger PHP-Code tatsächlich ist. Man muss nicht weiter suchen als bis zum Stack Overflow PHP-Tag, um PHP-Neulinge zu finden, die schrecklich anfälligen Code schreiben, der auf einer Gräueltat eines alten Tutorials basiert.

Zusätzlich eine beträchtliche Anzahl beliebter PHP Software, die für ihre weit verbreiteten Sicherheitslücken bekannt ist, basiert auf sehr altem Code und Codierungspraktiken. Viele dieser alten Praktiken werden aufgrund von Sicherheitsproblemen als schlechte Praktiken angesehen.

Für mich klingt dies so, als würde man jemandem sagen, er solle niemals fahren, damit er keinen Autounfall erleidet.

So ziemlich ja. Ein besserer Rat könnte lauten: "Fahren Sie kein altes Auto ohne Airbags".

Mein Bauchgefühl ist, dass der Host versucht, dem Kunden die Schuld für Sicherheitslücken zu geben ihr eigenes System.

Nicht unbedingt. Wenn ein Benutzer dasselbe Kennwort für die WordPress-Site und cPanel verwendet, gefährdet die Beeinträchtigung des WordPress-Kennworts auch cPanel. Das wäre die Schuld des Benutzers. Hacker müssen jedoch selten so weit kommen und nur eine PHP-Shell verwenden.

Ich sagte meinem Kunden, dass sie zur Verarbeitung des Kontaktformulars eine Form von dynamischem Scripting benötigen. (Falsch?)

Nicht unbedingt wahr. Sie können einen Drittanbieter-Service verwenden, um den E-Mail-Versand abzuwickeln. Anschließend übernimmt der Dienst die dynamische Server-Skripterstellung und übernimmt die Auswirkungen auf die Sicherheit. Es gibt zahlreiche solcher Dienste mit unterschiedlichen Funktionen, und sie sind beliebt, um Kontaktformulare auf statisch generierten Websites zu aktivieren.

Wie viel Wahrheit steckt in der Behauptung, dass die Verwendung eines PHP-Skripts, egal wie einfach, ein inhärentes Sicherheitsproblem darstellt?

Einige, aber nicht viel. PHP enthält sowohl in PHP als auch in der Serversoftware, die es ausführt, aktiven Code. Sollte es jemals eine Sicherheitslücke in diesem Prozess geben, die nicht von einem bestimmten PHP-Code abhängt, könnte diese ausgenutzt werden. Obwohl dieses Risiko gering ist, ist es ein Risiko, das ein Server ohne solche Unterstützung nicht hat.

"Richtig" ist vielleicht nicht das richtige Wort, aber "weise", "umsichtig" und "gewissenhaft" kommen mir in den Sinn. PHP hat seit seiner Gründung an einer Philosophie festgehalten, die die Korrektheit in Software abwertet. Es gibt eine Vielzahl von Situationen, in denen ein Programm auftreten kann, in denen andere Sprachen (z. B. Python) aufgeben und einen Fehler auslösen, um Ihnen mitzuteilen, dass Ihr Programm falsch ist. PHP entscheidet sich jedoch dafür, etwas Unsinniges zu tun und so weiterzumachen, als ob die Dinge gerecht wären gut.

Beachten Sie, dass Korrektheit für die Sicherheit sehr wichtig ist. Eine Sprache, die dazu neigt, Fehler links und rechts stillschweigend zu ignorieren, hat mehr als ihren gerechten Anteil an Programmen mit Sicherheitsproblemen. Beispielsweise haben Sie möglicherweise einen Code, von dem Ihre Programmierer glauben, dass er vor einem bestimmten Angriff schützt, der jedoch tatsächlich übersprungen wird, weil der Interpreter einen Fehler ignoriert.

Zusätzlich:

• PHP wurde entwickelt, um den kleinsten Nenner von Programmierern mit der geringsten Motivation anzusprechen, sich in ihrem Handwerk zu behaupten. Und damit die wahrscheinlichste, die unsichere Software schreibt.
• Das PHP-Team hat in der Vergangenheit zutiefst fehlerhafte Versuche unternommen, häufig auftretende Sicherheitsprobleme zu beheben. Schauen Sie sich zum Beispiel den SQL-Injection-Schutz an, der wiederholte fehlerhafte Versuche zur Behebung des Problems verrät: real_escape_string (weil der ursprüngliche Escape-String defekt war, aber erst später entfernt wurde ) vs. fügt Schrägstriche hinzu vs. mysql_escape_string / pg_escape_string und so weiter. Während so ziemlich jede andere Sprache nur mit vorbereiteten Anweisungen und Abfrageparametern ausgestattet war und gleich beim ersten Versuch ein auf alle Datenbanken erweiterbares Design erhielt.

Also für alle Gespräche in anderen Antworten darüber, wie Sie kann sichere Software in PHP schreiben, wenn Sie es versuchen, schwimmen Sie sehr gegen den Strom.

Die Sicherheitsprobleme von PHP können im Allgemeinen auf zwei Kategorien eingegrenzt werden.

Nicht gepatchte Systeme

Derzeit werden in Wordpress-Statistiken mehr als die Hälfte aller Benutzer angezeigt führen PHP auf PHP-Versionen aus, die End of Life (PHP 5.2 - 5.4) überschritten haben. In zwei Wochen geht PHP 5.5 auf EOL und springt dann auf ungefähr 80% aller Installationen. Um fair zu sein, werden einige Enterprise / LTS Linux-Installationen Sicherheitskorrekturen zurückportieren, aber die überwiegende Mehrheit von ihnen verwendet keine rückportierten Korrekturen (oder einige patchen ihre Systeme nicht). Schlimmer noch, viele Leute weigern sich, PHP selbst zu aktualisieren. Entweder können / wollen sie ihren Code nicht aktualisieren, oder sie denken, dass ältere Software stabiler ist.

Wordpress (weltweit führende PHP-Anwendung Nr. 1) hat konzertierte Anstrengungen unternommen, um sicherzustellen, dass die Benutzer auf dem Laufenden bleiben Datum auf der Software selbst (und sie haben große Fortschritte gemacht), aber trotzdem verwenden nur 40% die neueste Version von Wordpress. Dies bedeutet, dass etwa 60% möglicherweise eine nicht gepatchte Sicherheitslücke aufweisen. Und das ist nur das Basisprogramm. Wordpress verfügt über ein riesiges Ökosystem an Plugins, und viele von ihnen haben eigene Sicherheitslücken.

Dann gibt es noch andere Probleme, wie viel älteren Code, der die nicht mehr existierende mcrypt verwendet Bibliothek. Und das ist nur ein PHP-Plugin, das Sie kompilieren können.

Extrapolieren Sie dies nun auf die Server, die nicht ausgeführt werden, und melden Sie Statistiken an WP. Es malt kein schönes Bild. Letzten Sommer habe ich eine Website gefunden, auf der eine E-Commerce-Seite mit Apache 1.3.3 und PHP 4.1.2 ausgeführt wird. Es war so alt, dass SSLv2 aktiviert war ...

Schlechte Praktiken

Wenn Sie lange genug mit SO PHP-Fragen herumhängen, werden Sie viele Leute sehen, die schlechten Code üben. Einige der Probleme, die ich im Laufe der Jahre gesehen habe

• SQL Injection
• MD5 ist eine gute Möglichkeit, Kennwörter zu schützen.
• Verwenden veralteter APIs int ihren Code (dh ext / mysql , der alte MySQL-Connector)
• Vertrauen in Benutzereingaben zur Ausführung von Code (dh Verwendung von eval mit vom Benutzer angegebenen Daten)
• Sicherheitsrisiken im PHP-Code nicht ausschalten (dh die Funktion exec)

Für Ungeschulte sieht dies wie ein PHP-Problem aus, wenn es das ist Codierer und ihre Ökosysteme, die die Probleme verursachen. Vielleicht hatten sie es eilig. Vielleicht haben sie jemanden eingestellt, der dies in seiner Freizeit tut und "es einfach zum Laufen gebracht hat".

Kann es sicher sein?

JA! Diese Sicherheit erfordert jedoch einige Anstrengungen. Halten Sie Ihre PHP-Installation auf dem neuesten Stand. Halten Sie Ihren gesamten Server auf dem neuesten Stand. Host wird keine Sicherheit und Patches tun? Finden Sie einen anderen Gastgeber. (Ich bin erstaunt über die Leute, die sich dagegen wehren). Erstellen Sie Ihren eigenen Server (VMs sind billig). Vor allem aber aufpassen. Erfahren Sie alles über Sicherheit. Lassen Sie Ihre Website und Ihren Server nicht einfach auf See gehen.

Jemand, der Ihnen sagt, dass PHP unsicher ist, ist nur faul.

PHP ist nicht weniger oder sicherer oder unsicherer als jede andere Sprache (Java, Rails usw.). Es dreht sich alles um die Codierung. Sind Checks and Balances vorhanden, um einen Angriff abzulenken, zu verteidigen, zu verhindern oder zu mildern? Zitat:

WhiteHat Security führte Schwachstellenbewertungen von mehr als 30.000 Websites mit .NET, Java, ASP, PHP, Cold Fusion und Perl durch. Die am häufigsten verwendeten Sprachen waren .NET (28,1 Prozent der Webanwendungen), Java (24,9 Prozent) und ASP (15,9 Prozent).

...

Die Programmiersprache .Net hatte durchschnittlich 11,36 Schwachstellen pro Slot, Java 11.32 und ASP 10.98. Die sicherste Sprache, ColdFusion, hatte sechs Sicherheitslücken pro Steckplatz. Perl hatte sieben Schwachstellen pro Slot und PHP 10.

...

Java machte 28 Prozent der gefundenen Schwachstellen und ASP 15 Prozent aus. "Auch hier muss die Anzahl der in der Sprache verfassten Bewerbungen sowie die Komplexität der Websites als ein Faktor angesehen werden", heißt es in dem Bericht. PHP machte auch 15 Prozent der entdeckten Sicherheitslücken aus. ColdFusion machte nur 4 Prozent der Sicherheitslücken und Perl 2 Prozent aus. ( Quelle)

Dies sagt nichts darüber aus, wie Websites im Hinblick auf gute Codierungspraktiken entwickelt wurden. Wenn Sie beispielsweise ungelernte Programmierer (mangels besserer Begriffe) in jeder Sprache nehmen, können diese Zahlen umgekehrt werden und Perl weist die meisten Schwachstellen auf, wobei .Net die geringsten aufweist. Alles läuft darauf hinaus, was der Code selbst tun soll. Wurde der Code so programmiert, dass er seine einzige Funktion mit Manipulationen / Missbrauch ausführt, die getestet wurden, bevor er in die Entwicklung aufgenommen wurde?

Es gibt viele Spickzettel zur Sicherheit, Best-Practice-Anleitungen und andere Artikel, die Sicherheitsprobleme behandeln, aber dies wird zu einer Situation wenn der Kunde aufgrund der Ratschläge seines Anbieters müde ist. Dies kann eine Hürde sein, da es zu einer Art "er sagte" wird, sagte sie, eine Art Kampf, um Ihren Kunden davon zu überzeugen, dass Sie die Site mit PHP erstellen können. Eine Methode, die ich verwenden könnte, wenn ich weiterhin PHP verwenden möchte, besteht darin, eine Demo-Site zu erstellen und dann einen Scanner zur Schwachstellenbewertung (Acunetix, AppScan, Burpsuite) zu verwenden, um nach Fehlern zu suchen. Wenn keine gefunden werden, würde ich dem Kunden den Bericht vorlegen, in dem die Sicherheitslage Ihrer Erstellung detailliert beschrieben ist, und ihn so erstellen (PDF usw.), dass er dem Anbieter präsentiert werden kann.

Eines der grundlegenden Probleme mit PHP ist wirklich ein grundlegendes Problem mit dem CGI-Modell der Dinge (auf dem PHP trotz der Fallen von mod_php basiert) - nämlich, dass benutzerbezogene Daten miteinander vermischt werden mit Skripten, und es wird sehr einfach für z Benutzer lädt hoch, um ein ausführbares Skript zu werden. Dies ist nicht unbedingt ein Problem mit PHP selbst, aber wenn PHP überhaupt auf einem System verfügbar ist, ist es eine sehr große Angriffsfläche. Einige Sicherheitsprobleme von WordPress-Plugins sind beispielsweise auf diesen Aspekt zurückzuführen.

Herkömmliche CGI-basierte Bereitstellungen haben dieses Problem in der Vergangenheit gemindert, indem CGI-Skripte nur aus einem vertrauenswürdigen Verzeichnis (z. B. / cgi-bin / ), aber viele Shared-Hosting-Anbieter haben diese Einschränkung schließlich aus Gründen der "Bequemlichkeit" gelockert, und diese Bequemlichkeit ist in PHP allgegenwärtig.

Viele moderne PHP-basierte Anwendungen verwenden häufig .htaccess als schneller und schmutziger Anforderungs-Routing-Mechanismus, der zwar zur Minderung dieser Probleme beiträgt, dies jedoch alles andere als universell ist und dennoch keine einfache Lösung darstellt.

Meiner Meinung nach besteht das größte Problem bei PHP darin, dass beliebiger PHP-Code so einfach für die Ausführung auf jedem Server verfügbar gemacht werden kann, auf dem er konfiguriert ist, und daher ist der in PHP geschriebene Code nicht unbedingt mehr oder weniger sicher als der geschriebene Code in anderen Sprachen (obwohl seine Standardbibliothek nicht gerade einen Gefallen tut, wenn es darum geht, se zu schreiben Cure Code), der Mechanismus, mit dem PHP-Skripte ausgeführt werden, stellt eine massive Sicherheitsherausforderung dar, da PHP sogar auf einem Server verfügbar ist.

Ich stimme Ihrer Einschätzung zu, dass die Verwendung von PHP kein Sicherheitsrisiko erfordert. Es gibt einige Anbieter, die PHP aus dem gleichen Grund scheuen, aus dem WordPress als Sicherheitsrisiko angesehen wird. Es ist beliebt. Je häufiger etwas vorkommt, desto mehr Energie wird in die Entwicklung von Exploits investiert.

Allerdings würde ich PHP nicht vermeiden, wenn es ordnungsgemäß implementiert wird, zeitnahe Patches erhält und über ein gewisses Maß an Überwachung verfügt, um böswillige Aktivitäten zu erkennen . Fazit: Sicherheitsrisiken sind Sicherheitsrisiken, die für die Plattform unabhängig sind. Durch das Ändern der Skriptsprachen werden die Sicherheitsrisiken, die mit schlecht geschriebenem / entwickeltem / implementiertem Code verbunden sind, nicht gemindert.

Wenn Sie lediglich eine Standard-Kopf- / Fußzeile einfügen möchten, ist PHP möglicherweise übertrieben - einfache serverseitige Einschlüsse können dies tun.

PHP ist nicht von Natur aus gefährlich, wie in früheren Antworten dargelegt. Wenn Sie jedoch keine vollständige Skriptsprache auf dem Server benötigen, empfiehlt es sich, keine zu installieren. Wenn, wie Sie sagen, PHP sowieso auf dem Server installiert wird, ist das zusätzliche Risiko, das durch die Verwendung von PHP entsteht, ungefähr Null, solange Sie nichts Dummes tun. Das Einfügen einer Vorlage ist nicht dumm, es sei denn, Sie analysieren den Dateinamen anhand eines URL-Parameters.

Das Kontaktformular benötigt eine API und eine Datenbank dahinter, um die POST-Anforderung zu verarbeiten, wenn jemand sie sendet und es ist Wie gut dieser Teil geschrieben ist, der Dinge machen oder brechen wird - egal welche Sprache Sie verwenden, wenn es sich um eine SQL-Datenbank handelt, lohnt es sich, auf SQL Injection zu achten. Wenn die Eingaben des Benutzers in irgendeiner Weise an ihn oder den Client auf einer Webseite zurückgegeben werden, muss die (Java-) Skriptinjektion berücksichtigt und alles ordnungsgemäß HTML-maskiert werden. Im Vergleich zum Kontaktformular ist die Verwendung eines Includes so sicher wie möglich.

Wenn Sie nur eine Reihe von Webseiten und keine interaktive Webanwendung wünschen, besteht die ultimative Sicherheit darin, einen statischen Site-Generator zu verwenden. Der Server muss nur Dateien bereitstellen, was eine viel kleinere Angriffsfläche ergibt.

So:

Wie viel Wahrheit steckt in der Behauptung, dass die Verwendung eines PHP-Skripts, egal wie einfach, ein inhärentes Sicherheitsproblem darstellt?

So formuliert, fast keine. Ein Include-Header-Skript ist sicherlich keine Sicherheitslücke. Die Installation von PHP an erster Stelle, wenn Sie es nicht benötigen, ist keine bewährte Sicherheitsmethode. Es ist ein potenzielles Problem, es zu installieren und nicht regelmäßig zu aktualisieren, wenn Sicherheitspatches veröffentlicht werden, ebenso wenig wie die Richtlinie, wer für diese Updates verantwortlich ist - Wird der Kunde nach Abschluss des Site-Designs dafür verantwortlich sein? Oder der Hosting-Anbieter? Wenn sich der Client darüber Sorgen macht, sollte er überhaupt kein PHP auf dem Server haben. Wenn nicht, gibt es keinen sicherheitsrelevanten Grund, es nicht an Orten zu verwenden, an denen Sie wissen, was Sie tun.

Sprachen und Tools sind nicht von Natur aus unsicher, schlechte Code- und Sicherheitspraktiken sind es.

Da PHP eine geringe Eintrittsbarriere aufweist, können Personen, die die Netzwerksicherheit und die sichere Codierung nicht verstehen, Sicherheitsprobleme verursachen mit nicht informierten Entscheidungen.

Es ist nicht das Werkzeug, es ist der Affe, der es benutzt ;-)

In jeder Sprache geschriebener Code kann unsicher sein.

"Sie zögern, weil sie von ihrem Hosting-Unternehmen darauf hingewiesen wurden, dass die Verwendung von PHP ein Sicherheitsrisiko darstellt, das es jemandem ermöglichen könnte, in cPanel einzudringen und die Kontrolle über die Site zu erlangen."

Wenn das Hosting-Unternehmen dies glaubt brauche cPanel, um PHP auszuführen, dann ist es Zeit, den Host zu verschieben