Was sind die Nachteile der Verwendung von PHP-Filter-Code in Blöcken, Knoten, Views-Args usw.?

Ich habe oft Leute gesehen, die sagten, sie sollten keinen benutzerdefinierten PHP / PHP-Filter (von der Drupal-Benutzeroberfläche) in Blöcken, Knoten, Ansichten, Regeln usw. verwenden. Ich habe ein bisschen gesucht und nicht viel gefunden, wie es scheint Dies ist eine bewährte Drupal-Methode, die alle "nur wissen".

Ich verstehe, dass dies ein potenzielles Sicherheitsrisiko darstellt, insbesondere in den Händen von Endbenutzern oder Leuten, die mit Drupal oder PHP noch nicht vertraut sind. Aber was sind die wirklichen Gründe, um kein benutzerdefiniertes PHP von der Drupal-Benutzeroberfläche aus zu verwenden?

Einige Gründe:

• Code in Ihrer Datenbank kann nicht versionskontrolliert werden und ist auch später im Allgemeinen schwerer zu finden.
• Der Code von Eval () ist viel langsamer als ein fester Code in einer Datei.
• Wenn irgendwo in diesem Code ein Fehler auftritt, erhalten Sie eine sehr wenig hilfreiche Fehlermeldung (Fehler in eval () - Code in Zeile 3), und Sie müssen möglicherweise sogar Ihre Datenbank manuell durchsuchen, um den Fehler zu finden und zu beheben. Befindet es sich in einem Block, der auf allen Seiten angezeigt wird und beispielsweise die ganze Zeit über zu einem schwerwiegenden Fehler führt.
• Dies gilt auch für das Upgrade von Drupal 6 auf 7 und für alle APIs, die Sie verwendet haben. Sie müssen also Ihren Code während der Migration portieren. Wenn sich der Code in einem Modul befindet, können Sie ihn im Voraus portieren, testen und nur auf der neuen Site bereitstellen. Innerhalb eines Knotens oder Blocks funktioniert es nur mit Drupal 6 oder 7.
• Das Schreiben und Verwalten dieses Codes ist auch schwieriger, da Sie in einem Textfeld in Ihrem Browser arbeiten. Wenn Sie es in einem Modul haben, können Sie einen Editor / eine IDE mit Syntaxhervorhebung, automatischer Vervollständigung usw. verwenden.
• Es besteht immer die Möglichkeit einer Fehlkonfiguration, die den Benutzern Zugriff auf ein Textformat / einen Block / irgendetwas mit aktivierter PHP-Ausführung gibt. Wenn php.module (in D7 ist D6 nicht so streng, zum Beispiel für Blockzugriffsregeln) nicht einmal aktiviert ist, ist dieses Risiko bereits viel geringer.
• Wenn Ihr CMS die Ausführung von PHP zulässt, kann ein Angreifer, der eine Sicherheitslücke in Bezug auf XSS oder die Eskalation von Berechtigungen entdeckt, Ihren Server jetzt für äußerst böswillige Aktivitäten (als Teil eines DDOS, Versenden von Spam, Hosten von Malware, Hacken in andere Websites / Datenbanken auf der Website) verwenden Server, Hacken in andere Server im Netzwerk, die sich möglicherweise hinter Firewalls befinden). Dies macht kleine Schwachstellen nicht nur schmerzhafter, sondern macht die Site auch zu einem wahrscheinlichen Angriffsziel, wenn bekannt ist, dass sie zur Ausführung von PHP verwendet werden kann.

Es könnte noch mehr Gründe geben, aber das sollte reichen :)

Dieser Code ist schwer zu debuggen und zu warten. Ich kenne keine Möglichkeit, die Versionskontrolle für eine solche Art von PHP-Code zu verwenden.

Und es ist wirklich ein potentielles Sicherheitsrisiko für Leute, die neu in Drupal oder PHP sind.

In Anbetracht des in einem Knoten verwendeten PHP-Filters wird dieser nicht verwendet, da Sie die Benutzer einschränken, die diesen Knoten bearbeiten können, wenn nicht alle Benutzer den PHP-Filter verwenden dürfen.
Anstatt den PHP-Filter zu verwenden, ist es besser, ein benutzerdefiniertes Modul zu verwenden, das bestimmten Text im Knoteninhalt durch das Ergebnis des von ihm ausgeführten Codes ersetzt (ohne ihn zu verwenden eval()) oder seinen eigenen Text an den Hauptteil der Knoten anfügt. In diesem Fall kann jeder Benutzer den Knoten bearbeiten, ohne die Berechtigung zum Hinzufügen von beliebigem PHP-Code zu haben, der dann vom PHP-Filter ausgeführt wird.

Im Allgemeinen ist es besser zu vermeiden, eval()da dies die Lesbarkeit des Codes, die Möglichkeit, den Codepfad (und mögliche Auswirkungen auf die Sicherheit) vor der Laufzeit vorherzusagen, und damit die Möglichkeit, Code zu debuggen, verringert.

Abgesehen von einer Entwicklungs- oder Testsite würde ich den PHP-Filter nicht aktivieren oder PHP-Code verwenden, der an übergeben wird eval().

Der PHP-Filter wurde aus Drupal 8 entfernt. Es handelt sich nun um ein Drittanbieter-Modul , das nicht in der Sicherheitsrichtlinie aufgeführt ist . Dies ist wahrscheinlich ein Grund mehr, es nicht in Produktionsservern zu verwenden (wenn Sie die bereits angegebenen Gründe nicht überzeugt haben).

Als Umgehungslösung für die verschiedenen oben genannten Probleme - Schwierigkeit der Codewartung, Versionskontrolle, Fehlersuche - haben Sie diese leicht "kluge" Möglichkeit:

Erstellen Sie Funktionen (benennen Sie sie sorgfältig, je nachdem, was sie tun) in einer Datei, die immer enthalten ist. Wenn Sie ein benutzerdefiniertes Modul für die Site haben, können Sie diese Funktionen hier platzieren. Das PHP, das Sie dann eingeben, ist einfach: return my_specialfunc($somevar);- $somevarHier ist möglicherweise das Knotenobjekt, an dem gearbeitet wird, oder welche anderen Variablen hier relevant sind.

Ich finde, dass ich in der Regel immer noch die Flexibilität möchte, meinen eigenen Code an einigen Stellen aufzurufen. Bei dieser Technik ist die Pflege des Codes einfach, da lediglich die Funktion in der Datei geändert werden muss. Das Erkennen von Fehlern ist einfach, da die Funktion in einer Rückverfolgung angezeigt wird.

Beachten Sie jedoch, dass dies die potenziellen Sicherheitsprobleme nicht löst. Diese hängen weitgehend von der Sicherheit des Drupal-Kerns ab. Im Allgemeinen ist datenbankbasierter Code häufig ein Sicherheitsrisiko - Funktionalitäten, die datenbankbasierten Code verwenden, sind in der Regel viel anfälliger für Ausnutzung, und die Sicherheit in ihrer Umgebung muss besonders streng sein. Drupal war jedoch im Allgemeinen recht gut darin, die Sicherheit für diese Probleme aufrechtzuerhalten - sie sind aufgetreten und wurden dann schnell mit neuen Releases gepatcht / behoben.

Dies ist der Grund für die Sicherheitsanfälligkeit, um zu vermeiden, dass Ihren Benutzern diese Berechtigung erteilt wird, wenn Sie nicht möchten, dass Benutzer ohne Administratorrechte die Datenbank direkt ändern.

<?php
echo file_get_contents(dirname(__FILE__)."/../sites/default/settings.php");
?>

Hacken der Drupal-Datenbankanmeldeinformationen

Anstatt so etwas zu tun return functionname($object), ist es besser, das Token / Filter-System so weit wie möglich zu verwenden. Es gibt Module wie "Ansicht einfügen" und "Knoten einbetten", die unter normalen Umständen helfen, PHP in Knoten- oder Blockkörper einzubetten.

Sie sollten auf die Portabilität Ihrer Daten achten. Was passiert, wenn Sie Ihre Knoten von Drupal 7 auf Drupal 8 migrieren und der Haupttext eines Knotens <?php whatever_function_that_does_not_exist_anymore(); ?>darin enthalten ist?

Denken Sie nicht innerhalb von 5 Monaten, sondern innerhalb von 5 Jahren an Ihr Projekt. Aktualisierungen, bewährte Verfahren und Portabilität sind meiner Meinung nach wichtige Aspekte eines guten IT-Projekts.

Die Verwendung von Modulen mit möglichst geringem Beitrag ist ebenfalls ein Aspekt.