Erfahrungen aus der Praxis
Das Hauptproblem beim Anpassen von WebCastellum-Regeln sind unserer Erfahrung nach unsauber programmierte Altanwendungen, die potenziell gefährdete oder nicht korrekt kodierte Bestandteile im "HTTP-Request" oder "-Response" gewollt übertragen. Um Altanwendungen nicht anpassen zu müssen, sind in einigen Fällen gezielt Regeln aufzuweichen. Dieses Aufweichen sollte allerdings auf der kleinstmöglichen Einheit, also im Optimalfall auf Ebene eines bestimmten Parameters oder Formularfelds, erfolgen. Zweifellos wird hierdurch der Gesamtschutzgrad reduziert. Auf der anderen Seite müssen bezüglich Altanwendungen auch Risikobetrachtungen durchgeführt werden. Um für diese Sonderfälle den Schutzgrad um einen geringen Prozentsatz zu erhöhen, müssten gegebenenfalls hohe Anpassungskosten für die Anwendung sowie Akzeptanzrisiken berücksichtigt werden.
Bei hoher Kritikalität der durch eine Regelaufweichung geschaffenen Sicherheitslücke sollte die betroffene Altanwendung dennoch korrigiert werden, um anschließend die Schutzregel aktivieren zu können. Ein positiver Nebeneffekt des Einsatzes von WebCastellum ist die Tatsache, dass viele sicherheitskritisch bedenkliche Implementierungen in Form von "false positives" aufgedeckt werden. Oftmals lässt sich eine allgemeine aufgeweichte Regel aber auch durch eine gezielt eingesetzte Positivliste ersetzen, wodurch der Schutz weitgehend erhalten bleibt. Bei der Absicherung vorhandener Anwendungen kann durch den Einsatz der Open Source WAF deutlich Aufwand eingespart werden. Eine Anwendung im Nachhinein vollständig abzusichern, beispielsweise durchgängig Eingabevalidierungen einzubauen, Datenbankzugriffe umzustellen und Formularfeldschutzfunktionen einzubauen, erfordert einen hohen Aufwand. Da durch den minimal-invasiven Einsatz von WebCastellum ein hoher Schutzgrad erreicht wird, kann in vielen Fällen auf eine Anpassung der Altanwendung verzichtet werden.
Werden Neuentwicklungen durchgeführt, sollten natürlich von vornherein Sicherheitsaspekte berücksichtigt werden. Durch den Einsatz von WebCastellum wird der Schutzgrad in diesen Fällen zusätzlich erhöht. Prophylaktische Schutzfunktionen wenden einen Algorithmus an, der bestimmte Bestandteile eines "HTTP-Responses" verändert und dadurch gegen bösartige Manipulation immunisiert. Ob diese Algorithmen in der Anwendung liegen oder in eine vorgeschaltete, aber integrierte WAF ausgelagert sind, ist dabei unerheblich. Keine der Varianten bietet gegenüber der anderen ein Mehr an Schutz. Daher kann die Implementierung dieser Verfahren in der Anwendung entfallen. Stattdessen können hierfür ausschließlich die Funktionen von WebCastellum genutzt werden, was Aufwand einspart. Eine nachhaltige und vollständige Sicherheitskonzeption sollte sich natürlich nicht auf den Einsatz von WebCastellum beschränken. Viele weitere, auch organisatorische, Maßnahmen wurden im ersten Teil des Artikels diskutiert.
Fazit
Die Zeiten, in denen Entwickler Webanwendungen ohne Berücksichtigung von Sicherheitsaspekten erstellt haben, gehören hoffentlich bald der Vergangenheit an. Mittlerweile herrscht in vielen Unternehmen ein Bewusstsein für die Notwendigkeit, in die Sicherheit ihrer Webanwendungen zu investieren. Glücklicherweise nimmt die Zahl der zu diesem Zweck angebotenen Lösungen sowohl im kommerziellen als auch im Open-Source-Bereich stetig zu. Insbesondere die Masse an so genannten Altanwendungen profitiert von dieser Entwicklung. Ein wirkungsvolles Mittel, Altanwendungen kostengünstig nachträglich abzusichern sowie Einsparungen und zusätzliche Sicherheit bei Neuanwendungen zu erzielen, bieten Web Application Firewalls. Das Open-Source-Produkt WebCastellum nimmt hier eine Sonderposition ein, da es sich um eine in die Webanwendung integrierte WAF handelt. Die Ausführungen haben gezeigt, dass sich diese ohne Quellcodeanpassungen mit wenig Aufwand und ohne teure zusätzliche Infrastruktur in bestehende und neue Anwendungen integrieren lässt. Eine Skalierung der Webanwendung wirkt sich in gleicher Weise auf die WAF aus. Das Argument der negativen Auswirkung auf das Antwortzeitverhalten zählt kaum noch, der Einfluss der WAF ist selbst bei Aktivierung aller Schutzfunktionen äußerst gering.
Die Autoren haben WebCastellum in den letzten zwei Jahren in Kundenprojekten erfolgreich in zahlreiche Webanwendungen integriert und in Betrieb genommen. Mittlerweile ist dort der Einsatz auch für Neuentwicklungen Standard. Die Entwickler sind mit der WAF vertraut und in der Lage, diese zu konfigurieren. Im bereits etwa eineinhalbjährigen Betrieb hat die WAF sehr gute Performance und Stabilität bewiesen. Trotz aller Vorteile bleiben natürlich auch noch einige Punkte offen. So existiert derzeit noch keine durchgängige Unterstützung für Ajax-basierte Webanwendungen. Gerade die Ajax-Technologie öffnet Angreifern neue Möglichkeiten, ein System unbemerkt zu kompromittieren. Sofern ein Angreifer einmal eine Websession übernommen hat, laufen schädliche Anfragen im Hintergrund per "Ajax Request" ab. Der Anwender bemerkt den parallelen Angriff nicht einmal. Da "Ajax Requests" per JavaScript dynamisch zur Laufzeit generiert werden, sind Schutzfunktionen in einer mit nicht Ajax-basierten Anwendungen gleichwertig hohen Qualität kaum zu realisieren. Daher sollte heute für sicherheitstechnisch hochkritische Teilbereiche einer Webanwendung auf den Einsatz von Ajax noch weitgehend verzichtet werden. Der aktuelle Lagebericht 2009 des BSI weist erneut auf die Gefahren des "Web 2.0" hin.
Bei Einsatz von JSON ist in jedem Fall ein JSON Parser der Verwendung der eval()-Methode vorzuziehen, da bei dieser unter Umständen bösartige Java-Skripte im Browser zur Ausführung gebracht werden. Bei Nutzung von Web Services werden bereits automatisch alle abwehrenden WebCastellum-Schutzfunktionen angewendet. Maßgeschneiderte Algorithmen zur Abwehr XML-spezifischer Angriffsformen sind für kommende WebCastellum-Versionen geplant. Bei Dateiuploads ist dafür zu sorgen, dass Inhalte hochgeladener Dateien nicht zu einem späteren Zeitpunkt ungeprüft im Browser zur Anzeige gebracht werden. Zukünftig ist es angedacht, über ein Interface-Virenscanner oder ähnliche Tools zur nachgelagerten Prüfung von "Uploads" anbinden zu können.
Auch für Ajax-basierte Anwendungen wird bereits an WebCastellum-Schutzalgorithmen gearbeitet, die ein hohes Maß an Sicherheit gewährleisten. Dieser neue Typ Web Application Firewall bietet reichlich Potenzial, auch zukünftigen Angriffsformen (Hacker 2.0) wirkungsvoll zu begegnen.
Während der Entwicklung von WebCastellum haben wir von Kollegen, Kunden und Sicherheitsverantwortlichen in den Projekten sowie von Helfern und einer kleinen WebCastellum Community außerhalb der Projekte tatkräftige Unterstützung sowie viele wertvolle Anregungen erhalten, wofür wir uns an dieser Stelle bedanken möchten. All jene sowie alle interessierten Leser laden wir ein, WebCastellum auszuprobieren, zu testen und die Weiterentwicklung auch zukünftig mit Ideen, Anregungen und Kritik tatkräftig zu unterstützen.
Links & Literatur
- http://www.webcastellum.org
- http://www.webcastellum.org/WebCastellum-Datasheet.pdf
- http://en.wikipedia.org/wiki/Honeypot_(computing)
- http://en.wikipedia.org/wiki/SQL_injection
- http://www.owasp.org/index.php/SQL_injection
- http://www.owasp.org/index.php/Command_Injection
- http://en.wikipedia.org/wiki/Code_injection
- http://en.wikipedia.org/wiki/HTTP_response_splitting
- http://www.owasp.org/index.php/HTTP_Response_Splitting
- http://www.webappsec.org/projects/threat/classes/http_response_splitting.shtml
- http://en.wikipedia.org/wiki/Cross-site_scripting
- http://www.owasp.org/index.php/Cross_Site_Scripting
- http://www.cgisecurity.com/xss-faq.html
- http://www.owasp.org/index.php/Brute_force_attack
- http://en.wikipedia.org/wiki/Session_fixation
- http://www.owasp.org/index.php/Session_Fixation
- http://shiflett.org/articles/session-fixation
- http://www.webappsec.org/projects/threat/classes/information_leakage.shtml
- http://www.owasp.org/index.php/Command_Injection
- http://en.wikipedia.org/wiki/Code_injection
- http://www.json.org/
- http://www.bsi.bund.de/literat/lagebericht/Lagebericht2009.pdf, Kapitel 5.3 Seite 37-38#



