© Excellent backgrounds/Shutterstock.com
Java Magazin
Für mehr Sicherheit in Webanwendungen

Kopfsache

Zusätzlich zur grundsätzlich sicheren Entwicklung einer Webanwendung stellen Response-Header eine sinnvolle Ergänzung dar, mit denen der Browser gefährliche Operationen als letzte Instanz an der Ausführung hindern kann. Hierfür stehen verschiedene Response-Header zur Verfügung, von denen ich Ihnen einige in diesem Artikel vorstellen werde.

Dominik Schadow


Die meisten Java-Webentwickler sind zumindest schon mit einigen der zahlreichen HTTP-Response-Header in Berührung gekommen, mit denen sich die Darstellung und Verarbeitung einer Webanwendung im Browser beeinflussen lässt. Einige Response-Header versprechen nun sogar, die Sicherheit einer Webanwendung zu erhöhen. X-Frame-Options, X-Content-Type-Options, HTTP Strict Transport Security (HSTS) und Content Security Policy (CSP) sind die bekanntesten Vertreter dieser sicherheitsrelevanten Header.

Trotz des dadurch vergleichsweise einfach gebotenen zusätzlichen Schutzes und des allgemein deutlich gewachsenen Sicherheitsbewusstseins werden diese Header bisher allerdings viel zu selten eingesetzt. Ob nun aus Unkenntnis, vermeintlich aufwändiger Konfiguration bzw. Entwicklung, befürchteter Seiteneffekte oder fehlender Browserunterstützung. Als Entwickler verschenkt man so relativ einfach erreichbare zusätzliche Sicherheit in einer neuen Webanwendung. Selbst bei der nachträglichen Absicherung von Altanwendungen können diese Header einen positiven Einfluss auf die Sicherheit haben (üblicherweise allerdings mit einem deutlich höheren Entwicklungs- und Integrationsaufwand). Wunder dürfen Sie von den Headern allerdings keine erwarten, der Rest der Webanwendung muss weiterhin seinen Teil zur Sicherheit beitragen.

Generell ist es empfehlenswert, diese Header gleich von Anfang zu integrieren und damit deren Anforderungen und Einschränkungen bei der Entwicklung konsequent zu berücksichtigen. Gerade die später noch vorgestellte Content Security Policy stellt bestimmte Anforderungen an den Code, die sich nachträglich nur schwer und aufwändig in eine Webanwendung einbringen lassen (konsequent getrennter Code – in diesem Fall JavaScript, CSS und (X)HTML – erleichtert aber auch die nachträgliche Integration).

X-Frame-Options

Mit einem X-Frame-Options-Header lässt sich das an sich harmlos klingende Clickjacking verhindern. An der alternativen Bezeichnung UI redress attack wird allerdings deutlich, dass es sich um einen Angriff handelt. Dieser Angriff führt dazu, dass das ahnungslose Opfer eine Aktion ausführt oder erlaubt, die es unter normalen Umständen niemals gestattet hätte. Dazu lädt der Angreifer einen oder mehrere transparente Ebenen (Layer) per Frame über die vom Opfer eigentlich besuchte Webseite und überlagert diese damit ganz oder teilweise. Während das Opfer nun glaubt, auf der Webseite auf einen Button oder Link zu klicken, klickt es in Wirklichkeit auf den versteckt ...

Java Magazin
Für mehr Sicherheit in Webanwendungen

Kopfsache

Zusätzlich zur grundsätzlich sicheren Entwicklung einer Webanwendung stellen Response-Header eine sinnvolle Ergänzung dar, mit denen der Browser gefährliche Operationen als letzte Instanz an der Ausführung hindern kann. Hierfür stehen verschiedene Response-Header zur Verfügung, von denen ich Ihnen einige in diesem Artikel vorstellen werde.

Dominik Schadow


Die meisten Java-Webentwickler sind zumindest schon mit einigen der zahlreichen HTTP-Response-Header in Berührung gekommen, mit denen sich die Darstellung und Verarbeitung einer Webanwendung im Browser beeinflussen lässt. Einige Response-Header versprechen nun sogar, die Sicherheit einer Webanwendung zu erhöhen. X-Frame-Options, X-Content-Type-Options, HTTP Strict Transport Security (HSTS) und Content Security Policy (CSP) sind die bekanntesten Vertreter dieser sicherheitsrelevanten Header.

Trotz des dadurch vergleichsweise einfach gebotenen zusätzlichen Schutzes und des allgemein deutlich gewachsenen Sicherheitsbewusstseins werden diese Header bisher allerdings viel zu selten eingesetzt. Ob nun aus Unkenntnis, vermeintlich aufwändiger Konfiguration bzw. Entwicklung, befürchteter Seiteneffekte oder fehlender Browserunterstützung. Als Entwickler verschenkt man so relativ einfach erreichbare zusätzliche Sicherheit in einer neuen Webanwendung. Selbst bei der nachträglichen Absicherung von Altanwendungen können diese Header einen positiven Einfluss auf die Sicherheit haben (üblicherweise allerdings mit einem deutlich höheren Entwicklungs- und Integrationsaufwand). Wunder dürfen Sie von den Headern allerdings keine erwarten, der Rest der Webanwendung muss weiterhin seinen Teil zur Sicherheit beitragen.

Generell ist es empfehlenswert, diese Header gleich von Anfang zu integrieren und damit deren Anforderungen und Einschränkungen bei der Entwicklung konsequent zu berücksichtigen. Gerade die später noch vorgestellte Content Security Policy stellt bestimmte Anforderungen an den Code, die sich nachträglich nur schwer und aufwändig in eine Webanwendung einbringen lassen (konsequent getrennter Code – in diesem Fall JavaScript, CSS und (X)HTML – erleichtert aber auch die nachträgliche Integration).

X-Frame-Options

Mit einem X-Frame-Options-Header lässt sich das an sich harmlos klingende Clickjacking verhindern. An der alternativen Bezeichnung UI redress attack wird allerdings deutlich, dass es sich um einen Angriff handelt. Dieser Angriff führt dazu, dass das ahnungslose Opfer eine Aktion ausführt oder erlaubt, die es unter normalen Umständen niemals gestattet hätte. Dazu lädt der Angreifer einen oder mehrere transparente Ebenen (Layer) per Frame über die vom Opfer eigentlich besuchte Webseite und überlagert diese damit ganz oder teilweise. Während das Opfer nun glaubt, auf der Webseite auf einen Button oder Link zu klicken, klickt es in Wirklichkeit auf den versteckt ...

Neugierig geworden?


    
Loading...

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang