Reverse Proxy

Sichtbarkeit: Apache Webserver oder NGNIX sind millionenfach im Internet erreichbar. Entsprechend viele Menschen haben ein starkes Interesse daran, dass diese Instanzen sicher betrieben werden können und sicherheitskritische Lücken schnell geschlossen werden. Entsprechend gut und häufig wird der Code von vielen unabhängigen Beobachtern unter die Lupe genommen. Bei einer einzelnen Webanwendung - und sei sie auch noch so beliebt - werden das üblicherweise deutlich weniger Menschen sein. Sicherheitslücken fallen ggf. nicht so schnell auf.

Benutzerdefinierte Fehlerseiten: Webanwendungen zeigen teilweise das Verhalten, dass sie bei Fehlern detaillierte Infos ausgeben. In welcher Datei (mit vollem Pfad) und in welcher Zeile ist genau was passiert. Für die Fehleranalyse natürlich hilfreich - aber für den geneigten Angreifer leider auch. Er kann daraus wertvolle Informationen für den weiteren Angriff gewinnen. Daher sollten Stack-Traces und andere detaillierte technische Fehlermeldungen niemals bis zum Client zurückgemeldet werden. Natürlich soll in erster Linie die Webanwendung sinnvoll konfiguriert und entwickelt werden. Der Reverse Proxy kann da aber eine gute zweite Verteidigungslinie sein. Er kann einfach eine schöne Fehlerseite an den Client ausliefern, statt der Inhalte, die er vom Backend bekommt. Bei Apache z. B. mit ProxyErrorOverride. Netter Nebeneffekt: Sieht auch für den technisch nicht versierten Benutzer gleich viel schöner aus und verschreckt ihn nicht vollends.

URL Filter: Den Reverse Proxy setzt man am besten so auf, dass er nur die URLs zur Webanwendung durchreicht, die man auch wirklich zur Verfügung stellen möchte. Alles andere kann man da gleich "entsorgen", um bestimmte Angriffsszenarien schlicht ins Leere laufen zu lassen.

Eine gute Praxis ist es auch, die Zugriffe auf administrative URLs (also alles, womit man die Webanwendung konfigurieren kann) nur auf bestimmte Clients zu beschränken, die das auch wirklich tun sollen. Alle anderen Clients haben dann nur Zugriff auf die URLs, die der reguläre Nutzer der Anwendung auch tatsächlich benötigt.

Schnelle Sofortmaßnahmen per Konfiguration: Wenn in der Webanwendung ein kritischer Fehler bekannt wird, kann man oft auf dem Reverse Proxy schon gegensteuern, noch bevor der Patch der Anwendung zur Verfügung steht und getestet ist. Man kann da z. B. bestimmte URL-Patterns ablehnen oder umleiten, etc.

Apache Webserver oder NGINX werden seit Jahren von einer großen Community optimiert: Sie können sehr gut damit umgehen, wenn einige Client-Verbindungen mal sehr langsam laufen, abbrechen, etc.