Zum Umgang mit Sicherheitslücken bei Webanwendungen mittels .htaccess

In einem aktuellen Projekt habe ich zum ersten Mal den Fall einer “gehackten” Webanwendung kennen gelernt. Dem Angreifer ist es dabei gelungen, eine eigene .htaccess-Datei anzulegen oder in eine vorhandene .htaccess-Datei zu schreiben und vorhandenen Javascript-Code zu modifizieren. Die Folge war, beim Seitenaufruf bzw. beim Aufruf bestimmter Javascript-Befehle stets zu einer bestimmten Webadresse umgeleitet zu werden. Die Datenbanken wurden nicht in Mitleidenschaft gezogen. Da die Tabellen und Daten der Datenbanken intakt sind, man aber bei der “Reinigung” des Quellcodes der Scriptdateien eventuell das ein oder andere übersehen hätte, hat man sich nun dafür entschieden, eine Neuinstallation der Anwendungen von Originaldateien vorzunehmen. Interessant ist nun die Frage, wie man solchen Angriffen in Zukunft vorbeugen kann. Im folgenden hierzu meine Notizen.

Mögliche Sicherheitslücken

Wikipedia führt verschiedene Arten möglicher Sicherheitslücken bei Webanwendungen auf. Im Mittelpunkt steht dabei die Möglichkeit eines Benutzers, die Eingabemöglichkeiten eines Scripts zu missbrauchen, um illegitime Operationen durchzuführen. Es handelt sich dabei um Code-Injektionen oder “Injections”. Man unterscheidet:

  • Header Injection: Übermittlung illegitimen Codes als Teil der Metadaten des Protokolls, die im sogenannten Header zwischen Client und Server ausgetauscht werden.
    • HTTP Response Splitting: dient der Durchführung von Cross-Site Scripting-Attacken, (Cross-User) Defacements, Web cache poisoning, etc.
    • Cross-Site Scripting (XSS): dient z.B. der Umgestaltung von Internetseiten (Defacement), dem Diebstahl des Authentifizierungs-Cookies etc.
    • E-Mail-Injection: dient dem Versand unerlaubter Emails (Spam) über ein ungeschütztes Kontaktformular an beliebig viele, von der ursprünglichen Kontaktadresse abweichende Empfänger
  • SQL-Injection: Unerlaubter Zugriff auf die Datenbank mittels modifizierter SQL-Befehle mit dem Ziel z.B. Daten auszuspähen (z.B. Passwörter etc.), zu modifizieren oder zu zerstören (z.B. Tabellen löschen)

Erich Kachel geht in einem Beitrag zu XSS ausführlich aufAnalyse und Maßnahmen gegen Sicherheitsschwachstellen bei der Implementierung von Webanwendungen in PHP/MySQL ein, wobei er anschaulich die jeweils unterschiedlichen Angriffsformen erläutert.

Gegenmaßnahmen

Als Schutzmaßname für Webseitenbetreiber wird empfohlen, jegliche Form nutzerseitiger Eingabewerte als unsicher einzustufen und serverseitig zu überprüfen. Dies kann erstens durch entsprechende Befehle im Code der jeweiligen Anwendung und zweitens durch die Festlegung bestimmter Regeln seitens des Servers erfolgen. Letzteres geschieht auf Apache-Servern mittels .htaccess-Dateien (siehe unten). Das Mittel der Wahl ist, dabei jeweils nur die zulässigen Eingaben zu definieren (“weiße Liste”). Denn Aufzählungen unzulässiger Eingaben (“schwarze Liste”) haben den Nachteil, nicht alle denkbaren Angriffsmethoden durch nutzerseitige Eingaben vorhersehen zu können.

Bleibende Risiken

Insbesondere bei der Installation von Webanwendungen, die der Webmaster nicht selbst programmiert hat, wie z.B. bei umfangreichen Anwendungen wie WordPress, Joomla, vtiger uvm. , stellt sich aufgrund des Umfangs und der Komplexität der fremd entwickelten Software das Problem, sich auf die Qualität der in der Webanwendung vorhandenen Eingabeprüfungen verlassen zu müssen. Klaffen hier Sicherheitslücken, so ist es dem Webmaster zumeist mangels Wissen oder Zeit nicht möglich, sie durch ergänzende Programmierung vollständig auszuräumen. Er ist deshalb darauf angewiesen, dass mögliche Sicherheitslücken im betreffenden Script von der Gemeinschaft der diese Anwendung nutzenden Webmaster je einzeln identifiziert, in Foren und Mailinglisten bekannt gemacht und in Updates der betreffenden Anwendung behoben werden. Darum die häufig zu lesende Mahnung, kontinuierlich verfügbare Updates und Patches einer Software einzuspielen. Man profitiert so von den (teils unangenehmen und vielleicht sogar teuren) Erfahrungen anderer. Dem dann noch bleibendem Restrisiko wird man nur mittels regelmäßiger Sicherungskopien Herr.

Beispiel und erste Schlußfolgerungen

An meinem Beispiel ist interessant, dass es dem Angreifer gelungen ist, Dateien auf dem Server zu manipulieren. Es handelt sich dabei also um einen “persistenten Angriff”, bei dem der Angreifer präparierten Code innerhalb der Anwendung speichern konnte. Wie er das genau gemacht hat, ist nicht nachzuvollziehen. Ein Dienstleister hat nach Auswertung der Log-Dateien mitgeteilt, er halte es für wahrscheinlich, dass der Angreifer die FTP-Zugangsdaten auf dem Rechner des Webmasters mittels eines Trojaners ausgespäht hat. Eventuell ist also die Aufbewahrung der wichtigsten Zugangsdaten auf den Rechnern des Webmasters keine sichere Lösung.

Angesichts des von mir in Augenschein genommenen Installation kann es aber ebenso gut (und wesentlich wahrscheinlicher) so sein, dass die Sicherheitslücke entstanden ist, weil alte, nicht mehr gepflegte Scripte und Testinstallationen nicht gelöscht wurden, sondern parallel zu den produktiven Installationen bestehen blieben. Aber ebenso so gut ist es natürlich auch möglich, dass produktiv genutzte Installationen Sicherheitslücken aufweisen, die auch in Zukunft wieder Probleme bereiten werden.

Zu den ersten Schritten der Reduzierung möglicher Sicherheitslücken bei Webanwendungen zählt deshalb meines Erachtens

  • Passwörter nach Möglichkeit nicht in einfach lesbaren Textdateien aufzubewahren (sondern ggf. handschriftlich in Papierform aufzubewahren)
  • alte, nicht mehr benötigte Scripte zu entfernen
  • produktiv genutzte Installationen aktuell zu halten.
  • regelmäßig Sicherungskopien zu erstellen (Script-Dateien nach jeder Modifikation, Datenbanken in bestimmten zeitlichem Abstand)

Der zweite Schritt besteht darin, mittels .htaccess-Dateien Regeln festzulegen, die einen nochmaligen Angriff bereits aufgrund der Konfiguration des Servers wesentlich erschweren.

Sicherheitsmaßnahmen bei Webanwendungen mittels .htaccess

Ein Webmaster mag seitens der von ihm eingesetzten Scripte auf die Qualitätssicherung der Gemeinschaft der Entwickler und Nutzer dieser Scripte angewiesen sein. Ihm bleibt aber immer noch die Möglichkeit, seitens seines eigenen Servers mittels .htaccess Sicherheitsmaßnahmen zu ergreifen. Eine Beschreibung solcher möglicher Sicherheitsmaßnahmen mittels .htaccess findet man bspw. bei Marco Götze, der mich mit seinem Beitrag auf die weiterführenden Möglichkeiten von .htaccess neugierig gemacht hat.

Die erste und einfachste Möglichkeit besteht darin, den Zugriff von einer Authentifizierung des Nutzers abhängig zu machen. Der Nachteil dieser Methode besteht darin, dass der Zugriff dann auf bestimmte Nutzer beschränkt wird, denen man manuell Zugriffsrechte einräumen muss. Für ein nicht-öffentlich genutztes System wie beispielsweise vtigerCRM ist dies eine geeignete Lösung. Nicht jedoch für Content-Management-Systeme, deren Content allgemein öffentlich zugänglich sein sollen.

In diesem Fall stellen Apache-Server mit dem Softwaremodul mod_rewrite die Möglichkeit zur Verfügung, URL-Anfragen auf der Basis zuvor festgelegter Regeln unter Verwendung regulärer Ausdrücke umzuschreiben. Zum Gebrauch dieses Moduls existiert eine ausführlichere Dokumentation auf den Seiten von Apache.

“mod_rewrite is voodoo. Damned cool voodoo, but still voodoo.”
Brian Moore, zitiert nach Apache

Keine Kommentare »