Seite 1 von 1

HTTP Headers zur Absicherung?

Verfasst: Do 20. Apr 2017, 22:36
von creativecat
Ist das für uns ein interessanter Artikel? Hab ihn gerade gefunden, aber bis jetzt nur überflogen (ist erst mal in meiner Leseliste gelandet):
https://www.smashingmagazine.com/2017/0 ... p-headers/

Re: HTTP Headers zur Absicherung?

Verfasst: Fr 21. Apr 2017, 09:29
von shadowcat
Ich schau mal rein hab aber heute einen strammen Terminkalender.

Edit: Ich poste hier mal die Zusammenfassung des Artikels.
Disable caching for confidential information using the Cache-Control header.
Enforce HTTPS using the Strict-Transport-Security header, and add your domain to Chrome’s preload list.
Make your web app more robust against XSS by leveraging the X-XSS-Protection header.
Block clickjacking using the X-Frame-Options header.
Leverage Content-Security-Policy to whitelist specific sources and endpoints.
Prevent MIME-sniffing attacks using the X-Content-Type-Options header.

Re: HTTP Headers zur Absicherung?

Verfasst: Fr 21. Apr 2017, 12:57
von creativecat
Also ich habe es jetzt mal gelesen und das ein oder andere macht durchaus Sinn zu implementieren.
- Mit SSL müsste man vorsichtig sein - das würde ich eher optional anbieten
- Caching für das Backend standardmäßig aus - für das frontend könnte man das in den Seiteneinstellungen unterbringen
- Browserseitiger XSS Filter standardmäßig ein
- Eventuell kann man Ansätze von CSP optional anbieten (sehr komplex das alles).
- NoSniff... mh... da hab ich viel zu wenig Ahnung, in welchen Fällen das sinnvoll ist. Vermutlich müsste man das aber auch einmal global als Standard für alle Seiten definieren und optional - wie beim Caching - für Seiten einzeln anpassbar machen.

Wäre auf jeden Fall eine Überlegung für 2.0

Re: HTTP Headers zur Absicherung?

Verfasst: Fr 21. Apr 2017, 15:41
von shadowcat
Klar, immer.

Re: HTTP Headers zur Absicherung?

Verfasst: Fr 21. Apr 2017, 15:56
von shadowcat
Schnelle Einschätzung von mir.

Disable caching for confidential information using the Cache-Control header.

Sehe ich etwas differenzierter. Nicht alle Informationen des Backends sind wirklich "vertraulich". Im Wesentlichen sind das nur die Benutzerdaten. Daher müssen wir auf jeden Fall darüber nachdenken, ob wir wirklich das komplette Caching deaktivieren wollen. Gezieltes Deaktivieren beinhaltet wiederum das Risiko, dass man was vergißt.

Enforce HTTPS using the Strict-Transport-Security header, and add your domain to Chrome’s preload list.

Sehe ich wie Matthias, _wenn_ dann als Option. Eigentlich gehört die Einstellung in die Serverkonfiguration, auf die man aber üblicherweise keinen Einfluß hat. Dann ist nämlich schon die aufgerufene Adresse (URL) verschlüsselt.

Make your web app more robust against XSS by leveraging the X-XSS-Protection header.

Müssen wir schlichtweg testen.

Block clickjacking using the X-Frame-Options header.

Ist auch nicht ganz ungefährlich, wobei ich prinzipiell nicht gerne mit Frames arbeite. Eigentlich keine Sache des Cores.

Leverage Content-Security-Policy to whitelist specific sources and endpoints.

Auf jeden Fall aufwendig, nichtsdestotrotz sinnvoll.

Prevent MIME-sniffing attacks using the X-Content-Type-Options header.

Leider steht da nichts über mögliche Auswirkungen, müssen wir also noch näher untersuchen. Prinzipiell bin ich erst mal dafür.