Bevor ich meine erste Erweiterung schreibe, möchte ich verstehen, wie man sie so unverwundbar wie möglich gestaltet.
Gibt es eine Reihe von Regeln zum Schreiben einer sicheren Joomla-Erweiterung?
Ich kann mir nur SQL-Injection als mögliche Bedrohung vorstellen, daher weiß ich, dass Formulareingaben niemals direkt in den SQL-Befehl 'as is' eingefügt werden können.
Welche anderen Angriffsmethoden sollte ich beim Schreiben eines benutzerdefinierten Moduls oder Plugins beachten?
Antworten:
Eine Hauptsache, auf die Sie hingewiesen haben, ist SQL Injection. Dies ist eine Sache, die einige Leute, die ich gesehen habe, anscheinend völlig vermissen und mit der Entwicklung unter Verwendung von Nicht- Joomla-Codierungsstandards beginnen und mit dem Schreiben von SQL-Warteschlangen mithilfe von mysql_*Befehlen beginnen.
Das zweite, was ich im ersten Punkt erwähnt habe, ist, dass ich mich immer an die Joomla-Codierungsstandards halte. Das einzige Mal, dass Sie nicht sollten, ist, wenn Joomla keine Alternative bietet.
Drittens, wenn Ihre Erweiterung einen Ordner oder eine Datei erstellt, stellen Sie sicher, dass Sie ihnen die richtigen Berechtigungen erteilen, und beginnen Sie nicht, den Ordner chmod 777 zu erstellen. Dies ist der genaue Grund, warum K2, eine der beliebtesten Erweiterungen, als anfällig eingestuft wurde und vorübergehend aus JED entfernt.
Verwenden Sie immer Token mit Formularen. Dadurch wird sichergestellt, dass keine nicht autorisierten Angriffe von anderen Websites ausgeführt werden können. Weitere Informationen hierzu finden Sie unter:
http://docs.joomla.org/How_to_add_CSRF_anti-spoofing_to_forms
Wenn Sie sich nicht sicher sind, ob bereits einige Tests ausgeführt wurden, besuchen Sie den Code Review Stackexchange, da möglicherweise jemand bereit ist, Ihren Code für Sie zu überprüfen.
Sie können in der Liste der gefährdeten Erweiterungen nachsehen, welche Erweiterungen vorübergehend (bis zur Behebung) aus dem Joomla-Erweiterungsverzeichnis entfernt wurden, weil sie nicht sicher sind.
Ich hoffe, dies gibt Ihnen einen kleinen Einblick und viel Glück bei Ihrer ersten Erweiterung
Nach der offiziellen Dokumentation finden Sie hier einige Schritte zum Thema Richtlinien für die sichere Codierung :
Überprüfen Sie alle Daten, die Sie aus der Anfrage erhalten (POST, GET, COOKIES usw.). Vertraue dem Benutzer nicht und sei so streng wie möglich. Wenn Sie eine erwarten integer, lassen Sie nicht zu, dass eine stringakzeptiert wird.
Hochladen von Dateien - Vermeiden Sie nach Möglichkeit das Akzeptieren von Dateien auf öffentlichen Webseiten. Wenn Sie die Datei-Metainformationen validieren und alle möglichen Überprüfungen durchführen müssen.
Erstellen von SQL-Abfragen - Verstehen Sie, wie SQL-Injections funktionieren, aber auch, wie Sie mit Datenbankfehlern umgehen. Je mehr Fehler Sie anzeigen, desto mehr Informationen geben Sie über Ihre Datenbankstruktur. Im Idealfall protokollieren Sie Fehler, zeigen sie jedoch nicht an.
Sichern Sie Formulare mithilfe eines Tokens
Es ist für die meisten Erweiterungen größtenteils sicher. Seien Sie jedoch sehr vorsichtig, wenn Sie Dateien speichern / bearbeiten müssen. Durch unsachgemäße Filterung oder Validierung kann ein Einstiegspunkt erstellt werden.
Solange Sie die JDatabase-API korrekt verwenden, sollten Sie auch vor SQL-Injection geschützt sein. Sie können sich eine Joomla-Installation ansehen com_contentoder plg_system_loadpositonin einer Joomla-Installation, um einige der Feinheiten verschiedener Joomla-APIs herauszufinden (da die Dokumentation etwas schwer zu befolgen ist).
Wenn die APIs ebenfalls verwendet werden, wenn sie fehlschlagen und eine Art von Sicherheitsanfälligkeit verwendet wird, handelt es sich wahrscheinlich um ein Kernupdate (wenn es sich um eine JDatabase handelt, kann ich mir eine Joomla-Version innerhalb einer Stunde vorstellen, wenn sie entdeckt wird: D), und nicht um ein Update zu Ihrer Erweiterung.
Dies ist ein Hauptfehler von Open Source: Jeder, der Schaden anrichten möchte, verfügt über alle erforderlichen Informationen. Wenn es sich um eine geschlossene Erweiterung handelt (nicht öffentlich verfügbar), gibt es wahrscheinlich nie ein Problem.
Je einfacher die Erweiterung ist (weniger Code), desto wahrscheinlicher ist es, dass sie unverwundbar ist. Wenn eine Erweiterung wächst, gibt es viel mehr Stellen, an denen ein kleiner Fehler auftreten kann, um einen Einstiegspunkt zu erstellen.