Joomla! 38%* sicherer machen

Lieber Joomla! Nutzer oder Entwickler oder Admin, hier findest du diesmal keine Links zu Beschreibungen von Sicherheitslücken und wie sie vermieden werden können. Hier findest du nur eine kleine aber mächtige Lösung gegen einige Sicherheitslücken in Joomla! und Erweiterungen. Es handelt sich dabei um eine eigenständige Sicherheitslösung die nichts mit dem Joomla!-CMS zu tun hat. Das sei mal zum Anfang gleich gesagt :)

Auch schon die lange Liste der Schwachstellen in Joomla!-Erweiterungen gemerkt? Über 90 detaillierte Angriffsmöglichkeiten seit Anfang 2008 werden auf einschlägige Seiten gelistet und mit jeder neuen Erweiterung werden es sicherlich mehr werden.

Doch hier lieber eine offizielle Quelle:
Bei NVD nach „Joomla“ suchen und Schwachstellen anzeigen lassen

Sucht man in dieser langen Liste (265 Treffer) nur die Schwachstellen mit SQL-Injection und Cross-Site-Scripting heraus, so ergeben sich:

96 Mal SQL-Injection
+ 6 Mal XSS
———————
Potentielle 102 geschlossene Sicherheitslücken.

Ich möchte hier wieder einmal demonstrieren, mit wie wenig Aufwand besonders die SQL-Injection-Lücken gesichert werden könnten.

Dazu bindet man in der index.php die SSEQ-LIB ein und parametrisiert den Vorfilter. Dieser überprüft die Parameter aus einer gegebenen Liste auf Datentyp und Datenlänge. Wird an dieser Stelle definiert, dass beispielsweise die Parameter „cat„, „catid„, „category_id„, „CategoryID“ oder „cat_id“ nur eine Zahl zwischen 0 und 100000 sein darf, schließt man auf einmal mehrere Schwachstellen:

CVE-2008-4777
CVE-2008-1297
CVE-2008-0849
CVE-2008-3083
CVE-2008-2892
CVE-2008-2701
CVE-2008-2630
CVE-2008-2568
CVE-2008-1077
CVE-2008-0916
CVE-2008-0855

und andere mehr. Daten, die nicht zu diesem Muster passen (z.B. durch SQL-Injection), werden aus GET/POST/REQUEST gelöscht und kommen so gar nicht erst an die ungesicherte Stelle an.

Beispiel einer angepassten Joomla! „index.php“ die SQL-Angriffe über die Parameter „cat„, „catid„, „category_id„, „CategoryID“ oder „cat_id“ abwehrt
<br />
// SSEQ-LIB einbinden<br />
include_once(&#8217;sseq-lib/seq_lib.php&#8216;);</p>
<p>// Regeln definieren<br />
//              VARIABLE NAME  # SOURCE # TYPE # MIN # MAX # XSS # SQL  &#038;<br />
$sanitizer = &#8218;  cat            # pg # INT # 1   # 100000   #  #   &#038;<br />
                
catid          # pg # INT # 1   # 100000   #  #   &#038;<br />
                
cat_id         # pg # INT # 1   # 100000   #  #   &#038;<br />
                
category_id    # pg # INT # 1   # 100000   #  #   &#038;<br />
                
CategoryID     # pg # INT # 1   # 100000   #  #   &#038;<br />
             
&#8218;;</p>
<p>// Filter starten<br />
SEQ_SANITIZE($sanitizer);</p>
<
p>[Weiterer Joomla!-Code]<br />

Wird diese Liste durch neue zu schützende Parameter erweitert, z.B. beim Installieren neuer Joomla!-Komponenten, ergibt sich eine wirkungsvolle Sicherheitsbarriere gegen eine Vielzahl von Angriffen. Die Lücken bleiben nach dieser Maßnahme natürlich noch immer bestehen. Sie können aber nicht mehr ausgenutzt werden und das ist es doch, was man erreichen möchte!

* „38% sicherer“ ist eine schöne Milchmädchenrechnung: 102 potentiell geschützte Schwachstellen aus 265 gelisteten Schwachstellen. Bezieht man künftige Schwachstellen mit ein, die ebenfalls unter diesen Schutz fallen, ist die Prozentzahl > 38.

Das könnte Dich auch interessieren …

2 Antworten

  1. Jens sagt:

    Ähmm das geht ja nur wenn man einen eigenden (v)server gat und keinen hosting webspace ?!

    icch meien damit das einbinden der „sseq-lib“

  2. Erich Kachel sagt:

    Hallo Jens,
    die sseq-lib Bibliothek ist im Gegenteil so konzipiert, dass sie auch (bzw. besonders) auf shared-hoster-server mit eingeschränkten Einstellungen läuft.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.