Website absichern mit HTML, Apache, .htaccess

Situation

Eine Website läuft unter Debian auf einem lokalen Apache Webserver und ist bereit, auf den Webserver im Internet hochgeladen zu werden.
Nach dem Hochladen läuft die Website einwandfrei. Ein Test bei 'Webcoll' weist aus, dass es einige offene Themen gibt. Es sollen also noch zusätzliche Sicherheitseinstellungen eingerichtet werden.

Aufkommendes Thema

Die Sicherheitsteinstellungen werden bewirken, dass zum Beispiel in der jeweiligen HTML-Datei direkt hinterlegte Java-Skripte, bestimmte Absatz- und Tabellenformatierungen nicht länger funktionieren. Als Vorarbeit testet man am besten auf dem lokalen Apache-Webserver, wo es tatsächlich ein Thema gibt.

Technisch müssen die Javaskripte in Dateien ausgelagert und dann über die Metaangaben im Head-Bereich eingebunden werden.
Besondere Formatierungen müssen in css ausgelagert werden.

Das Problem ist die Entscheidung

Man darf sich entscheiden, die Einstellungen über HTML und dann in jeder einzelnen HTML-Datei zu hinterlegen oder das einmalig in der .htaccess-Datei auf dem Webserver des Providers zu tun, sofern der Provider gestattet, auf diese Datei zuzugreifen und deren Inhalt zu ändern.
Ausnahme: Clickjacking, siehe unten.

Völlig klar: Wenn man das sogleich auf dem Webserver des Providers aktiviert, dann kann wirken sich die Änderungen sogleich aus.
Hilfsweise kann man auf dem lokalen Webserver eine Test-Datei mit allen Funktionen erstellen und prüfen, wie die Änderung sich auswirkt.

Abhilfe Weg 1: HTML

In den Metadaten jeder HTML-Datei dies hier hinterlegen. Zeilenümbrüche dürfen nach einem ';' eingefügt werden:

<meta http-equiv="Content-Security-Policy" content="default-src 'none'; 
script-src 'self'; img-src 'self'; style-src 'self'; font-src 'self'; 
connect-src 'self'; form-action 'self'; base-uri 'self'; media-src 'self';">

Abhilfe Weg 2: auf dem Apache-Webserver des Providers

Sofern der Provider das gestattet, kann man die Einstellungen einmal in einer Datei hinterlegen. Diese Einstellungen wirken sich dann auf alle Dateien der Website aus.
Nachteil: Ich konnte das auf dem lokalen Webserver nicht 1:1 ausprobieren.

.htaccess

Sofern vorhanden, lädt man die .htaccess vom Webserver des Providers herunter und fügt am Ende dies hier an:

<IfModule mod_headers.c>
  Header set Content-Security-Policy "default-src 'none'; 
  script-src 'self'; img-src 'self'; style-src 'self'; 
  font-src 'self'; connect-src 'self'; form-action 'self'; 
  base-uri 'self'; frame-ancestors 'none';"
    Header set X-Frame-Options "DENY"
</IfModule>

Sollte die Datei auf dem lokalen Rechner nicht sichtbar sein, kann man mit [Strg]+[h] die Systemdateien einblenden.

Unter Windows kann ein Dateiname nicht mit einem Punkt beginnen. Der Name kann also gegebenenfalls auf dem lokalen Rechner anders lauten und nach dem Hochladen auf den Webserver des Providers geändert werden.

Clickjacking

Soweit ich in Erfahrung bringen konnte, kann Clickjacking nicht mit einem Eintrag in HTML abgewehrt werden. Das muss auf dem Apache in .htaccess geschehen. Das ist dann dieser Eintrag:

Header set X-Frame-Options "DENY"

Weniger streng ist:

Header set X-Frame-Options "SAMEORIGIN"

Übersicht der Effekte

• default-src 'none'; (Das eiserne Sicherheitsnetz)
  Alles, was nachfolgend nicht explizit erlaubt ist (z. B. Videos, Audio, Iframes, Ajax-Abfragen), das wird vom Browser präventiv komplett blockiert.
• script-src 'self'; (Starker XSS-Schutz)
  Es darf ausnahmslos JavaScript aus eigenen Dateien ('self') vom 'eigenen' Server geladen werden. Jegliches Inline-JavaScript (wie onclick="..." oder <script>...) wird blockiert, was Angreifer daran hindert, Schadcode einzuschleusen.
• img-src 'self' data:; (Bildersicherheit)
  Bilder dürfen vom eigenen Server geladen werden. Das zusätzliche data: erlaubt es dir, Bilder direkt als Base64-Code im HTML oder CSS einzubetten (wird oft für kleine Icons genutzt).
• style-src 'self' 'unsafe-inline'; (CSS-Schutz mit Ausnahme)
  CSS-Dateien vom 'eigenen' Server sind erlaubt. Durch 'unsafe-inline' dürfen die eigene Website (oder ein Angreifer) Styles direkt in die HTML-Tags via style="..." schreiben.
  Hinweis: Wenn Galeriebilder und eine Lightbox komplett in die externe CSS-Datei ausgelagert sind, sollte man das unsichere 'unsafe-inline' gar nicht verwenden, um noch sicherer zu sein!
• font-src 'self'; (Schriftarten-Schutz)
  Verhindert das Laden von fremden Schriftarten. Es werden nur Schriften erlaubt, die lokal auf dem 'eigenen' Server liegen.
• connect-src 'self';
  Die Website darf Daten nur vom exakt eigenen Server (gleiche Domain, gleiches Protokoll wie https, gleicher Port) nachladen. Alle Anfragen an fremde Server werden vom Browser blockiert.
• form-action 'self'; (Datendiebstahl-Schutz)
  Formulare auf deiner Website dürfen Daten nur an deinen eigenen Server abschicken. Ein Angreifer kann so Formulardaten (wie Login-Daten) nicht an eine fremde Domain umleiten.
• base-uri 'none'; (Pfad-Manipulationsschutz)
  Verhindert, dass Angreifer das <base>-Tag im HTML injizieren, um relative Links (wie ../bilder/) heimlich auf einen Angreifer-Server umzulenken.
• frame-ancestors 'self'; (Clickjacking-Schutz)
  Die eigene Website darf nur von deiner eigenen Domain in einem <iframe> angezeigt werden. Fremde Webseiten können die eigene Website nicht unsichtbar einbetten, um Klicks abzufangen.
• Header set X-Frame-Options "DENY": DENY (Maximaler Schutz): Niemand darf Ihre Seite einbetten.
  Wenn Sie selbst auf Ihrer Domain versuchen, Seite A in ein Frame auf Seite B zu laden, wird der Browser das blockieren. Das ist die sicherste Einstellung, wenn Sie auf deiner Website überhaupt keine Frames nutzen.
• Header set X-Frame-Options "SAMEORIGIN": SAMEORIGIN (Flexibler Schutz):
  Nur deine eigene Website darf ihre eigenen Seiten einbetten. Wenn ein Angreifer versucht, Ihre Seite auf seiner Domain einzubetten, blockiert der Browser es.
• media-src 'self' in einer Content Security Policy (CSP)
  erlaubt das Laden von Audio- und Videodateien ausschließlich von der eigenen Domain.