Quickfix: Sicherheitslücke in QContacts 1.0.6
Samstag, 14 Januar 2012 01:07
Seit Anfang Dezember ist eine schwere Sicherheitslücke (SQL Injection) in der Joomla Komponente QContacts in Version 1.0.6 öffentlich. Ein Exploit zur Ausnutzung der Sicherheitslücke findet sich auf den einschlägigen Websites.
Die Lücke wurde bisher leider noch nicht vom Entwickler geschlossen. Da seit dem Jahr 2008 keine Updates für QContacts veröffentlicht wurde, ist fraglich, ob noch ein offizielles Update zur Behebung der Lücke entwickelt wird.
Was ist die Ursache der Sicherheitslücke?
Die Sicherheitslücke wird durch die unsaubere Verwendung des filter_order Parameters verursacht. Dieser Parameter kann beim Aufruf der Kategorien-Ansicht in der URL definiert werden und wird in der Komponente mit der Joomla-API-Funktion getUserStateFromRequest einer Variable zugeordnet. Da die Variable – an die der Inhalt des Parameters übergeben wird – in einem SQL-Query verwendet wird, ist es über die geschickte Manipulierung des Parameters möglich, eigene SQL Anweisungen auszuführen.
Wie kann die Sicherheitslücke behoben werden?
Für alle, die auf die Kategorien-Ansicht verzichten können, empfiehlt sich die Löschung dieser Ansicht. Durch diese Maßnahme kann die Sicherheitslücke von Angreifern nicht mehr ausgenutzt werden und die Funktionsweise der restlichen Ansichten wird nicht beeinträchtigt.
Um den View zu entfernen, muss auf dem Server der Order *JoomlaStammverzeichnis*/components/com_qcontacts/views/category/ gelöscht werden. Sollte zu einem späteren Zeitpunkt ein Update für QContacts erscheinen, reicht es aus, diesen Ordner erneut hoch zu laden, um die Kategorien-Ansicht wieder nutzen zu können.
Gibt es einen Weg, um die Kategorien-Ansicht weiterhin nutzen zu können?
Möchte man die Kategorien-Ansicht weiterhin nutzen, muss die Lücke schnellstmöglich komplett beseitigt werden. Da für eine saubere Lösung jedoch ein Teil der Komponente neu implementiert werden muss, ist der Aufwand für die Beseitigung relativ hoch.
Zwei Lösungsansätze zur Beseitigung der Lücke
Sicherer als die momentane Implementierung wäre beispielsweise, wenn der Parameter filter_order nur Integer-Werte (Ganzzahlen) akzeptiert. Alternativ ist es möglich, den Parameter auf unerwünschte Zeichen zu kontrollieren und diese gegebenenfalls zu entfernen.
Kurz und schmerzlose Fehlerbehung der Sicherheitslücke. Cool, danke für den hilfreichen Artikel.