Sie können einzelne Codezeilen nicht überprüfen. Du wirst einfach sterben, wenn du das versuchst.

Irgendwann musst du jemand anderem vertrauen. Im Jahr 1984 schrieb Ken Thompson, einer der Miterfinder eines Großteils von Unix, einen kurzen Artikel über die Einschränkungen von Trusts. Irgendwann müssen Sie anderen Menschen vertrauen, Sie müssen darauf vertrauen, dass derjenige, der Ihren Texteditor geschrieben hat, nicht automatisch Trojaner-Code versteckt, den der PHP-Interpreter in Bitcoin-Malware ausführt.

Sie Sie müssen eine Kosten-Nutzen-Analyse durchführen, um zu priorisieren, was Sie überprüfen.

Zum größten Teil sollten Sie das Beste tun, um die Autoren des Codes, die internen Sicherheitspraktiken des Projekts und die Vorgehensweise zu überprüfen Code erreicht Sie. Das Überprüfen des Codes ist teuer und schwierig, daher sollten sie für die Teile reserviert werden, die Sie für Ihr Projekt als am wichtigsten erachten.

Ist die Bibliothek eine beliebte Bibliothek, die von vielen Personen mit einem seriösen Unternehmen oder einer angesehenen Firma verwendet wird? ein bekannter Projektleiter dahinter? Verfügt das Projekt über geeignete Projektmanagementprozesse? Hat die Bibliothek eine gute Vorgeschichte von Sicherheitsproblemen und wie haben sie damit umgegangen? Verfügt es über Tests, um alle Verhaltensweisen abzudecken, mit denen es umgehen muss? Besteht es seine eigenen Tests? Dann wird das Risiko verringert, dass die Bibliothek kompromittiert wird, ohne dass es jemand merkt.

Nehmen Sie ein paar Beispieldateien für eine eingehendere Überprüfung. Sehen Sie dort etwas? Wenn die wenigen Dateien, die Sie aufgenommen haben, größere Probleme haben, können Sie wahrscheinlich darauf schließen, dass der Rest der Codebasis ähnliche Probleme hat. Wenn sie gut aussehen, erhöht dies Ihr Vertrauen, dass der Rest der Codebasis ähnlich gut geschrieben ist. Beachten Sie, dass es in sehr großen Codebasen unterschiedliche Bereiche des Codes mit unterschiedlichen Codequalitätsstufen gibt.

Überprüft Ihr Paketmanager-Repository die Paketsignatur? Ist ein Vorprüfungssystem erforderlich, um ein Paket im Repository zu registrieren, oder handelt es sich um ein offenes Registrierungs-Repository? Erhalten Sie die Bibliothek in Form von Quellcode oder als vorkompilierte Binärdatei? Diese wirken sich darauf aus, wie sehr Sie der Bibliothek vertrauen können, welche Risikofaktoren Sie haben und wie Sie das Vertrauen weiter verbessern können.

Sie müssen auch die Anwendung und die Ausführungsumgebung berücksichtigen, in der die Anwendung ausgeführt wird. Ist das für einen nationalen Sicherheitscode? Ist diese Code-Verarbeitung Teil eines E-Commerce- oder Bankgeschäfts mit Kreditkartennummern? Läuft dieser Code als Superuser? Ist dieser Code lebens- / sicherheitskritisch? Haben Sie kompensierende Steuerelemente zum Isolieren und Ausführen von Code mit unterschiedlichen Berechtigungen (z. B. Container, VMs, Benutzerberechtigungen)? Ist dieser Code für ein Wochenendprojekt? Wie Sie diese Fragen beantworten, sollte es Ihnen ermöglichen, ein Budget zu definieren, wie viel Sie in Überprüfungscode investieren können, und daher zu priorisieren, welche Bibliotheken auf welcher Ebene überprüft werden müssen und welche mit geringerem Vertrauen in Ordnung sind.

Mein "Composer" -Verzeichnisbaum enthält derzeit über 120.000 Codezeilen. Und das ist für die minimale Anzahl wichtiger PHP-Bibliotheken, die ich benötige.

Ihr Fehler besteht darin, Code von Drittanbietern so zu überprüfen, als wäre es Ihr eigener. Sie können und sollten nicht versuchen, dies zu tun.

Sie haben keine der Bibliotheken namentlich erwähnt, aber ich gehe davon aus, dass ein angemessener Teil davon vorhanden ist, weil Sie eine verwenden der größeren Frameworks wie Laravel oder Symfony. Frameworks wie dieses haben wie andere große Bibliotheken ihre eigenen Sicherheitsteams. Probleme werden schnell behoben und die Installation von Updates ist trivial (solange Sie eine unterstützte Version verwenden).

Anstatt zu versuchen, den gesamten Code selbst zu überprüfen, müssen Sie loslassen und dem Anbieter vertrauen erledigt - und tut es auch weiterhin - diese Überprüfung für Sie. Dies ist schließlich einer der Gründe, warum Sie Code von Drittanbietern verwenden.

Realistisch gesehen sollten Sie PHP-Bibliotheken von Drittanbietern genauso behandeln, wie Sie Bibliotheken von Drittanbietern in einer kompilierten Version behandeln würden Umgebung wie .NET oder Java. Auf diesen Plattformen werden die Bibliotheken als DLL-Dateien oder ähnliches geliefert, und der Quellcode wird möglicherweise nie angezeigt. Sie können sie nicht untersuchen und Sie würden es nicht versuchen. Wenn Ihre Einstellung zu einer PHP-Bibliothek anders ist als diese, müssen Sie sich fragen, warum. Nur weil Sie den Code lesen können, bedeutet dies nicht, dass Sie dadurch etwas gewinnen.

Dies alles hängt natürlich davon ab, ob Ihre Bibliotheken von Drittanbietern kleinere enthalten nicht unterstützt oder haben keine Sicherheitsrichtlinie. Dies ist also die Frage, die Sie allen von Ihnen verwendeten Bibliotheken stellen müssen: Werden sie vollständig unterstützt und verfügen sie über eine Sicherheitsrichtlinie, mit der Sie vertraut sind? Wenn dies nicht der Fall ist, sollten Sie eine Alternative zu diesen Bibliotheken suchen. Das heißt aber nicht, dass Sie versuchen sollten, sie selbst zu überprüfen, es sei denn, Sie beabsichtigen tatsächlich, die Unterstützung für sie zu übernehmen.

Eines möchte ich jedoch hinzufügen: Wenn Sie eine Sicherheitsüberprüfung Ihres PHP-Codes durchführen möchten, empfehle ich dringend die Verwendung des RIPS-Scanners. Es ist nicht billig, aber wenn Sie hohe Sicherheitsanforderungen haben, ist es einfach das beste automatisierte Sicherheitsanalysetool, das Sie für PHP erhalten können. Führen Sie es auf jeden Fall mit Ihrem eigenen Code aus. Sie werden wahrscheinlich überrascht sein, wie viele Probleme es aufgreift. Sie können es natürlich auch in Ihren Bibliotheken von Drittanbietern ausführen, wenn Sie paranoid genug sind. Es wird Sie jedoch viel mehr kosten, und meine obigen Punkte stehen immer noch; Sie sollten wirklich darauf vertrauen, dass Ihre Drittanbieter dies für sich selbst tun.

Willkommen zum neuen Paradigma der Codierung: Sie verwenden Bibliotheken über Bibliotheken. Sie sind kaum allein, aber Sie müssen auch verstehen, dass Sie jedes Mal, wenn Sie Code einbringen, den Sie nicht geschrieben haben, ein gewisses Risiko mit sich bringen.

Ihre eigentliche Frage lautet , wie ich mit diesem Risiko umgehen kann ?

Verstehen Sie, was Ihre Software tun soll.

Zu oft werden Bibliotheksverwalter zu einer bequemen Möglichkeit, Code so zu verwenden, dass er "einfach funktioniert", ohne sich jemals darum zu kümmern auf hohem Niveau zu verstehen, was es tun soll. Wenn Ihr vertrauenswürdiger Bibliothekscode schlechte Dinge tut, werden Sie mit platten Füßen erwischt und fragen sich, was passiert ist. Hier kann Unit Testing helfen, da es testet, was der Code tun soll.

Kennen Sie Ihre Quellen

Composer (oder einen beliebigen Paketmanager) ) kann von jeder von Ihnen angegebenen Quelle installiert werden, einschließlich einer Bibliothek, die gestern von einer völlig unbekannten Quelle aufgerollt wurde. Ich habe bereitwillig Pakete von Anbietern installiert, die über SDKs verfügen, da der Anbieter eine sehr vertrauenswürdige Quelle ist. Ich habe auch Pakete aus Quellen verwendet, die andere vertrauenswürdige Arbeiten ausführen (d. H. Jemand im PHP-Projekt hat ein Bibliotheks-Repo). Das blinde Vertrauen in eine Quelle kann zu Problemen führen.

Akzeptieren Sie, dass ein gewisses Risiko besteht, das Sie niemals vollständig mindern können.

Im Jahr 2016 hat ein einzelner NodeJS-Entwickler eine Menge Pakete verkrüppelt wenn sie das Projekt beenden und verlangen, dass ihre Bibliotheken nicht veröffentlicht werden. Sie hatten eine einfache Bibliothek, die Hunderte anderer Pakete als Abhängigkeit auflisteten. Oder die Infrastruktur wurde nicht für die Paketverteilung erstellt, sodass sie zufällig ausfällt. Das Internet ist in der Welt der verteilten Softwareentwicklung so gut darin geworden, "Dinge zum Laufen zu bringen", dass die Leute dazu neigen, verärgert oder verwirrt zu sein, wenn es einfach nicht mehr funktioniert.

Als PHP 7.0 herauskam, musste ich eine Menge Arbeit leisten, um ein Open-Source-Softwarepaket von Drittanbietern zu erstellen, das wir in der 7.0-Umgebung verwenden. Es hat einige Zeit in Anspruch genommen, aber ich konnte dem Autor des Pakets helfen, einige Probleme zu lösen und es in der 7.0-Umgebung verwendbar zu machen. Die Alternative war, es zu ersetzen ... was noch mehr Zeit in Anspruch genommen hätte. Wir akzeptieren dieses Risiko, da dieses Paket sehr nützlich ist.

Das grundlegendste Sicherheitsproblem besteht jedoch weiterhin: Ich habe keine Ahnung, was dieser "installierte" Code enthält, und ich weiß auch nicht, was bei jedem Update hinzugefügt / geändert wird. Einer der Autoren der Bibliotheken könnte eines Tages leicht kompromittiert worden sein, als mein Composer Updates abruft, was dazu führt, dass meine PHP-CLI-Skripte plötzlich meine Bitcoin wallet.dat an einen Remote-Server senden, eine RAT / einen Trojaner auf meinem Computer installieren oder noch schlimmer. Tatsächlich hätte es schon passieren können, und ich wäre nicht klüger. Ich habe einfach keine Ahnung. Ich kann logischerweise keine Ahnung haben.

Nachschlagen Heartbleed, die massive Sicherheitslücke in OpenSSL. Heartbleed hat SSL effektiv verfeinert, indem zuerst die letzten mehreren hundert oder tausend (netzwerkverschlüsselten) Transaktionen als Klartext gespeichert wurden und dann jedem, der davon wusste, eine einfache und nicht protokollierte Funktion zur Verfügung gestellt wurde, um eine Remoteverbindung herzustellen und alle vom Benutzer zwischengespeicherten Transaktionen abzurufen wurden sicher im Klartext verschlüsselt. Zu diesem Zeitpunkt schützte OpenSSL die überwiegende Mehrheit der selbst gehosteten Websites und eine große Anzahl von Banken und sogar staatlichen Geheimdiensten.

Dann schauen Sie nach Meltdown und Spectre, massive Fehler, die direkt in moderne Intel-CPUs eingebaut sind. Meltdown und Spectre wirken dem Ausführen einer CPU im geschützten Modus vollständig entgegen und sind unabhängig vom Betriebssystem auf jedem Betriebssystem ausnutzbar.

Vor Jahren hat eine Malware namens MSBlaster einen Windows XP-Hintergrunddienst ausgenutzt (ich bin mir nicht einmal sicher, ob es sich um einen Fehler handelte - nur einen außergewöhnlich dummen), der kein Geschäft hatte Standardmäßig wird es nur von einer großen Minderheit der Windows-Benutzer aktiv verwendet und ist dann nur den IT-Abteilungen bekannt. Dies veranlasste ISPs schließlich, in ihre Modemgeräte integrierte Hardware-Firewalls herauszugeben, und Microsoft veranlasste Microsoft, eine integrierte Software-Firewall in ihre Betriebssysteme einzubetten. Etwa zur gleichen Zeit wurde entdeckt, dass eine Distribution der angeblich "virensicheren" Linux-Plattform ein integriertes Rootkit in der Hauptdistributionsversion enthält.

Wie andere gesagt haben: Man muss jemandem vertrauen Punkt. Sowohl Unfälle als auch Bosheit verursachen Probleme. Ich bin wie du - großer Fan von The X-Files und Uplink (VERTRAUEN SIE KEINEM!) - Die Realität ist jedoch, dass Ihre SSL-Kryptografie-Engine oder Ihre physischen Hardwaregeräte genauso wahrscheinlich Sicherheitslücken aufweisen und dass diese weitaus häufiger geschäftskritische Fehler darstellen, wenn sie auftreten.

Wenn Sie es ernst meinen, das Composer-Rad für Ihre und die Sicherheit Ihrer Benutzer neu zu erfinden, sollten Sie es ernst meinen: Entwickeln Sie Ihre eigene CPU, Ihr Mainboard, Ihren RAM, Ihre Festplatte und Ihre optischen Laufwerke. Schreiben Sie Ihre eigenen Betriebssystem- und Hardwaretreiber. Erstellen Sie auch Ihre eigenen Compiler. Und vergessen Sie PHP, weil es Probleme im Interpreter geben könnte - vergessen Sie auch C und C ++, weil es Probleme im Compiler geben könnte, und denken Sie nicht einmal an die Assemblersprache mit einem Assembler, den jemand anderes geschrieben hat. Schreiben Sie Ihre gesamte Software von Grund auf in Maschinenanweisungen mit einem Hex-Editor.

Oder Sie könnten sich wie ein Mitglied der Branche verhalten. Abonnieren Sie die Update-Newsletter von Composer / PHP / YourLinuxDistro und erhalten Sie möglicherweise auch einige unabhängige sicherheitsbasierte Newsletter. Außerdem erhalten Sie ein Abonnement für Wired . Überprüfen Sie Ihre Systemprotokolle. Testen Sie Ihr Netzwerk regelmäßig mit einem PCAP, um sicherzustellen, dass keine nicht autorisierten Netzwerkströme ein- oder ausgehen. Seien Sie proaktiv bei der Überwachung möglicher Bedrohungen und nicht paranoid bei Dingen, die noch nicht geschehen sind.

Als fortgeschrittener bis fortgeschrittener Entwickler habe ich das gleiche Problem in Betracht gezogen. Einige zu berücksichtigende Punkte:

• Priorisieren Überprüfen von Code, der aus Sicherheitsgründen von entscheidender Bedeutung ist. Dazu gehören natürlich Dinge wie Authentifizierung und Anmeldecode, Berechtigungsüberprüfung, Integration von Zahlungsprozessoren . Alles, was nach vertraulichen Informationen fragt oder Netzwerkanrufe tätigt.
• Visuell überfliegen Dinge wie Styling-Bibliotheken - Sie sollten schnell feststellen können, dass sie nur Styling ausführen - und Dinge wie Dienstprogrammfunktionen. Überstrichen von Zeichenfolgen, Leerzeichenersetzungen, Neuanordnen von Arrays ... Sie sollten in der Lage sein, den Code schnell zu überfliegen und festzustellen, dass sie nichts Unerwartetes bewirken.
• Auch wenn Sie den Code nicht vollständig rückentwickeln, als ob Es war Ihre eigene, Sie sollten in der Lage sein, einen Blick auf die Quelle zu werfen und festzustellen, ob sie für das Reverse Engineering freundlich sein soll. Code sollte dokumentiert mit hilfreichen Kommentaren sein, Variablen- und Methodennamen sollten relevant und nützlich sein, Funktionen und Implementierungen sollten nicht zu lang oder zu komplex sein oder unnötige Funktionen enthalten. Code, der für das Auge sehr angenehm ist ist sicherlich nicht der bevorzugte Angriffsvektor für böswillige Hacker.
• Bestätigen Sie, dass der Code eine etablierte und ausgereifte Benutzerbasis hat stark>. Sie möchten sich für Projekte interessieren, die von profitablen und bekannten Unternehmen verwendet werden.
• Bestätigen Sie die realen Identitäten von Lead Contributors . Bei Großprojekten wird der Hauptentwickler gerne für seine Arbeit Anerkennung finden. Sie sollten in der Lage sein, Blog-Beiträge, Social-Media-Konten und wahrscheinlich einen Lebenslauf oder eine Marketing-Seite für Beratungsarbeiten zu finden. Kontaktieren Sie mich! usw.
• Vergewissern Sie sich, dass Open Source-Code aktiv gepflegt mit den neuesten Bugfixes ist. Schauen Sie sich ausstehende Fehlerberichte an - es wird bestimmt einige geben - und vertrauen Sie nicht den Behauptungen, dass ein bestimmtes Tool oder eine bestimmte Bibliothek fehlerfrei ist. Das ist eine wahnhafte Behauptung.
• Vermeiden Sie "Freeware" -Seiten mit übermäßigen Anzeigen. Vermeiden Sie Projekte, für die keine Demo-Site verfügbar ist oder bei denen die Demo "hässlich", schlecht gewartet oder häufig offline ist. Vermeiden Sie Projekte, die überfordert sind, oder übermäßige Schlagworte, die ungetestete Ansprüche auf überlegene Leistung stellen. Vermeiden Sie das Herunterladen von anonymen Blogs. Usw.
• Böswillig denken . Was würden Sie versuchen, wenn Sie Ihre Website brechen wollten? Wenn Sie unsicheren Code in eine weit verbreitete Bibliothek schleichen möchten, wie würden Sie das tun? (Versuchen Sie dies natürlich nicht.)
• Fork Open-Source-Projekte oder laden Sie Backups herunter. Vertrauen Sie niemals darauf, dass das offizielle Repo des Open-Source-Projekts, das Sie mögen, auf unbestimmte Zeit online bleibt.

Versuchen Sie also nicht, jede einzelne Codezeile einzeln zu lesen und zu verstehen, sondern machen Sie sich ein Bild davon was jede Bibliothek tut, und Sie glauben, dass es das tut. Ich denke wirklich, wenn Ihre Arbeit rentabel ist, gibt es keine Obergrenze dafür, wie groß ein Projekt sein kann. Sie können mehr als 1.200.000 Codezeilen oder mehr als 120.000.000 Codezeilen "überprüfen"!

Composer kann mit einer composer.lock -Datei arbeiten und Pakete standardmäßig über https://packagist.org/ herunterladen (beachten Sie das HTTP S. .) Sie haben also ein riesiges Paket-Repository und einen sicheren Download mit der dazugehörigen SHA1-Prüfsumme, um sicherzustellen, dass Sie genau das herunterladen, was einmal angegeben wurde. Das allein hilft Ihnen sehr.

Wenn Sie bei Abhängigkeitsaktualisierungen auf der konservativen Seite bleiben, können Sie auch erwarten, dass die Paketversionen in der Produktion verwendet wurden.

Am Ende jedoch , du musst jemandem vertrauen. Sie können sich entweder darauf verlassen, dass Sie Exploit-freien Code schreiben, oder Sie können, wie andere auch, Community-Projekten vertrauen, die von Tausenden verwendet und von noch mehr Benutzern gesehen werden.

Letztendlich glaube ich nicht, dass Sie eine Wahl haben. Wenn andere "blind fliegen", dh ohne die Sicherheitsüberprüfungen, die Sie durchführen möchten, und "Ihre" Kunden mit niedrigeren Preisen und schnelleren Feature-Releases nehmen, wird ohnehin niemand von Ihrer sicheren selbstgeschriebenen Anwendung profitieren.