Sichere Webserver(konfiguration) - Revision history

Wolfm: /* Beispiel Apache Konfiguration */

2017-10-17T08:16:44Z

Beispiel Apache Konfiguration

← Older revision		Revision as of 08:16, 17 October 2017
Line 120:		Line 120:
	Header set X-Frame-Options: "sameorigin" <br>		Header set X-Frame-Options: "sameorigin" <br>
	#enable CSP <br>		#enable CSP <br>
	Header set Content-Security-Policy: "object-src 'self'; frame-src 'self'; script-src '~~self‘~~;" <br>		Header set Content-Security-Policy: "object-src 'self'; frame-src 'self'; script-src 'self';" <br>
	#X-Content-Type-Options <br>		#X-Content-Type-Options <br>
	Header set X-Content-Type-Options: ~~„no~~ ~~sniff“~~ <br><br>		Header set X-Content-Type-Options: "no sniff" <br><br>
	#Vhost-Config for port 80 (redirect to https)<br>		#Vhost-Config for port 80 (redirect to https)<br>
	<IfModule mod_rewrite.c> <br>		<IfModule mod_rewrite.c> <br>

Beeckoli: /* Subresource Integrity */

2016-11-06T00:49:35Z

Subresource Integrity

← Older revision		Revision as of 00:49, 6 November 2016
Line 60:		Line 60:

	==== Subresource Integrity ====		==== Subresource Integrity ====
			Geteilte Ressourcen, wie z.b. von einem CDN liegen ausserhalb der eigenen Kontrolle und können gegebenfalls manipuliert werden. Um die Integrität dieser Ressourcen zu gewährleisten, wird bei der Auslieferung jeder Ressource zusätzlich ein Hash mitgelifert, der beim ersten Einbinden der Ressource erstellt wurde. So kann sichergestellt werden, dass sie nicht verändert wurde. Der Browser des Benutzers muss dann die entsprechenden Hashwerte mit selbst errechneten Werten vergleichen und gegebenfalls das Laden der Webseite unterbrechen.

			<code>
			<script src="https://example.com/example-framework.js" integrity="sha384-oqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K/uxy9rx7HNQlGYl1kPzQho1wx4JwY8wC" crossorigin="anonymous"></script>
			</code>

	==== X-Content-Type-Options ====		==== X-Content-Type-Options ====
	Setzt der Server den HTTP-Header X-Content-Type-Options: nosniff, so wird dem Browser signalisiert, dass der MIME-Type in jedem Fall respektiert werden soll. Javascript-Code in Bildern wird damit ignoriert.<ref>http://www.golem.de/news/cross-site-scripting-javascript-code-in-bilder-einbetten-1411-110264-2.html</ref> <br>		Setzt der Server den HTTP-Header X-Content-Type-Options: nosniff, so wird dem Browser signalisiert, dass der MIME-Type in jedem Fall respektiert werden soll. Javascript-Code in Bildern wird damit ignoriert.<ref>http://www.golem.de/news/cross-site-scripting-javascript-code-in-bilder-einbetten-1411-110264-2.html</ref> <br>

Beeckoli: /* X-XSS-Protection */

2016-11-05T23:30:42Z

X-XSS-Protection

@@ Line 87: / Line 87: @@
 ==== X-XSS-Protection ====
 ==== Beispiel Apache Konfiguration ====
 <tt>

Beeckoli: /* X-Frame-Options */

2016-11-05T23:21:44Z

X-Frame-Options

@@ Line 68: / Line 68: @@
 ==== X-Frame-Options ====
 ==== X-XSS-Protection ====
 ==== Beispiel Apache Konfiguration ====

Poeschlm: /* Beispiel Apache Konfiguration */

2016-10-26T07:20:38Z

Beispiel Apache Konfiguration

← Older revision		Revision as of 07:20, 26 October 2016
Line 71:		Line 71:
	==== Beispiel Apache Konfiguration ====		==== Beispiel Apache Konfiguration ====
	<tt>		<tt>
	<nowiki />--Debian apache 2.4 <br>		<nowiki />#Debian apache 2.4 <br><br>
	<nowiki />-enable mod_headers <br>		<nowiki />#enable mod_headers <br>
	sudo a2enmod headers <br>		sudo a2enmod headers <br>
			#enable rewrite
⚫	-insert into config file: <br>
			sudo a2enmod rewrite <br><br>
		⚫	#insert into config file: <br>
	sudo vi /etc/apache2/conf-available/security.conf <br>		sudo vi /etc/apache2/conf-available/security.conf <br>
	-enable XFO <br>		#enable XFO <br>
	Header set X-Frame-Options: "sameorigin" <br>		Header set X-Frame-Options: "sameorigin" <br>
	-enable CSP <br>		#enable CSP <br>
	Header set Content-Security-Policy: "object-src 'self'; frame-src 'self'; script-src 'self‘;" <br>		Header set Content-Security-Policy: "object-src 'self'; frame-src 'self'; script-src 'self‘;" <br>
	-X-Content-Type-Options <br>		#X-Content-Type-Options <br>
	Header set X-Content-Type-Options: „no sniff“ <br>		Header set X-Content-Type-Options: „no sniff“ <br><br>
	-Config for port 80 (redirect to https) <br>		#Vhost-Config for port 80 (redirect to https)<br>
	~~sudo~~ ~~a2enmod~~ ~~rewrite~~ <br>		<IfModule mod_rewrite.c> <br>
	~~-in~~ ~~Virtual~~ ~~Hosts~~ ~~file:~~ <br>		RewriteEngine On <br>
		⚫	RewriteCond %{HTTPS} off <br>
⚫	<IfModule ~~mod_rewrite.c~~> <br>
		⚫	RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} <br>
	RewriteEngine On <br>
		⚫	</IfModule> <br><br>
⚫	RewriteCond %{HTTPS} off <br>
			#Config for port 443<br>
⚫	RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} <br>
	~~</IfModule>~~ <br>		#enable SSL, e.g. <br>
	~~-Config~~ ~~for~~ ~~port~~ ~~443~~ <br>		SSLEngine On <br>
		⚫	SSLCertificateFile /etc/ssl/localcerts/apache.pem <br>
	-enable SSL, e.g. <br>
		⚫	SSLCertificateKeyFile /etc/ssl/localcerts/apache.key <br>
	SSLEngine On <br>
⚫	SSLCertificateFile /etc/ssl/localcerts/apache.pem <br>
⚫	SSLCertificateKeyFile /etc/ssl/localcerts/apache.key <br>
	</tt>		</tt>
	<nowiki />		<nowiki />

Walterfl: /* Content Security Policy */

2016-10-25T17:48:57Z

Content Security Policy

← Older revision		Revision as of 17:48, 25 October 2016
Line 23:		Line 23:
	* Stylesheets dürfen nur von der eigenen Domain und static.ak.fbcdn.net geladen werden, Inline-Styles sind nicht erlaubt		* Stylesheets dürfen nur von der eigenen Domain und static.ak.fbcdn.net geladen werden, Inline-Styles sind nicht erlaubt

	Mit Hilfe von CSP lassen sich noch weitere Einstellungen sehr granular anpassen. Eine Liste der möglichen ~~Anpassungen~~ findet sich ~~hier~~ [https://content-security-policy.com/ hier].		Mit Hilfe von CSP lassen sich noch weitere Einstellungen sehr granular anpassen. Eine Liste der möglichen Einstellungen findet sich [https://content-security-policy.com/ hier].

	==== Cross-origin Resource Sharing ====		==== Cross-origin Resource Sharing ====

Walterfl: /* Content Security Policy */

2016-10-25T17:48:31Z

Content Security Policy

← Older revision		Revision as of 17:48, 25 October 2016
Line 22:		Line 22:
	* Scripte dürfen nur von von der eigenen Domain und cdnjs.cloudflare.com geladen werden, Inline-Scripte sind nicht erlaubt		* Scripte dürfen nur von von der eigenen Domain und cdnjs.cloudflare.com geladen werden, Inline-Scripte sind nicht erlaubt
	* Stylesheets dürfen nur von der eigenen Domain und static.ak.fbcdn.net geladen werden, Inline-Styles sind nicht erlaubt		* Stylesheets dürfen nur von der eigenen Domain und static.ak.fbcdn.net geladen werden, Inline-Styles sind nicht erlaubt

			Mit Hilfe von CSP lassen sich noch weitere Einstellungen sehr granular anpassen. Eine Liste der möglichen Anpassungen findet sich hier [https://content-security-policy.com/ hier].

	==== Cross-origin Resource Sharing ====		==== Cross-origin Resource Sharing ====

Walterfl: /* Content Security Policy */

2016-10-25T17:45:30Z

Content Security Policy

← Older revision		Revision as of 17:45, 25 October 2016
Line 7:		Line 7:
	==== Content Security Policy ====		==== Content Security Policy ====
	Der Content Security Policy (CSP) ist ein Sicherheitskonzept, welches dabei helfen soll Cross-Site-Scripting (XSS) und weitere Angriffe zu unterbinden. Bei solchen Angriffen werden Daten in die Webseite eingeschleust. Der CSP-Header soll einschränken, von wo Daten gelesen werden dürfen. <br>		Der Content Security Policy (CSP) ist ein Sicherheitskonzept, welches dabei helfen soll Cross-Site-Scripting (XSS) und weitere Angriffe zu unterbinden. Bei solchen Angriffen werden Daten in die Webseite eingeschleust. Der CSP-Header soll einschränken, von wo Daten gelesen werden dürfen. <br>
	Eine der wichtigsten Regeln von CSP ist, dass inline JavaScript unterbunden wird. Dabei kann durch escaped user-inputs unerwünschter Code generiert werden, welcher vom Browser als JavaScript interpretiert wird. Durch das abschalten von Inline JavaScript werden fast alle XSS angriffe unterbunden. Das bedeutet jedoch auch, dass nur JavaScript von Orten geladen werden dürfen, die mit <script> src markiert sind. Das ist für bereits bestehende Seiten mit großen umfang sehr aufwändig umzusetzen. <ref>https://wiki.mozilla.org/Security/Guidelines/Web_Security#Content_Security_Policy</ref> Gleiches gilt auch für inline stylesheets, welche ebenfalls in <style> tags ausgelagert werden müssen.		Eine der wichtigsten Regeln von CSP ist, dass inline JavaScript unterbunden wird. Dabei kann durch escaped user-inputs unerwünschter Code generiert werden, welcher vom Browser als JavaScript interpretiert wird. Durch das abschalten von Inline JavaScript werden fast alle XSS angriffe unterbunden. Das bedeutet jedoch auch, dass nur JavaScript von Orten geladen werden dürfen, die mit <script> src markiert sind. Das ist für bereits bestehende Seiten mit großen umfang sehr aufwändig umzusetzen. <ref>https://wiki.mozilla.org/Security/Guidelines/Web_Security#Content_Security_Policy</ref> Gleiches gilt auch für inline stylesheets, welche ebenfalls in <style> tags ausgelagert werden müssen. <br>
			Auslagern von JavaScript in Script-Files:
	<code>		<code>
	<script> [code] </script> <br>		<script> [code] </script> <br>
Line 13:		Line 14:
	</code>		</code>

			CSP-Header:
	<code>		<code>
	$csp_rules = "default-src 'self' cdn.foobar.de; script-src 'self' cdnjs.cloudflare.com; style-src 'self' static.ak.fbcdn.net";		$csp_rules = "default-src 'self' cdn.foobar.de; script-src 'self' cdnjs.cloudflare.com; style-src 'self' static.ak.fbcdn.net";

Walterfl: /* Content Security Policy */

2016-10-25T17:43:55Z

Content Security Policy

← Older revision		Revision as of 17:43, 25 October 2016
Line 12:		Line 12:
	<script src="externalfile.js"></script>		<script src="externalfile.js"></script>
	</code>		</code>

			<code>
			$csp_rules = "default-src 'self' cdn.foobar.de; script-src 'self' cdnjs.cloudflare.com; style-src 'self' static.ak.fbcdn.net";
			</code>

			* Alle Resourcen dürfen von self und cdn.foobar.de geladen werden
			* Scripte dürfen nur von von der eigenen Domain und cdnjs.cloudflare.com geladen werden, Inline-Scripte sind nicht erlaubt
			* Stylesheets dürfen nur von der eigenen Domain und static.ak.fbcdn.net geladen werden, Inline-Styles sind nicht erlaubt

	==== Cross-origin Resource Sharing ====		==== Cross-origin Resource Sharing ====

Walterfl: /* Content Security Policy */

2016-10-25T13:08:54Z

Content Security Policy

← Older revision		Revision as of 13:08, 25 October 2016
Line 6:		Line 6:
	=== Sicherheitskonzepte ===		=== Sicherheitskonzepte ===
	==== Content Security Policy ====		==== Content Security Policy ====
			Der Content Security Policy (CSP) ist ein Sicherheitskonzept, welches dabei helfen soll Cross-Site-Scripting (XSS) und weitere Angriffe zu unterbinden. Bei solchen Angriffen werden Daten in die Webseite eingeschleust. Der CSP-Header soll einschränken, von wo Daten gelesen werden dürfen. <br>
			Eine der wichtigsten Regeln von CSP ist, dass inline JavaScript unterbunden wird. Dabei kann durch escaped user-inputs unerwünschter Code generiert werden, welcher vom Browser als JavaScript interpretiert wird. Durch das abschalten von Inline JavaScript werden fast alle XSS angriffe unterbunden. Das bedeutet jedoch auch, dass nur JavaScript von Orten geladen werden dürfen, die mit <script> src markiert sind. Das ist für bereits bestehende Seiten mit großen umfang sehr aufwändig umzusetzen. <ref>https://wiki.mozilla.org/Security/Guidelines/Web_Security#Content_Security_Policy</ref> Gleiches gilt auch für inline stylesheets, welche ebenfalls in <style> tags ausgelagert werden müssen.
			<code>
			<script> [code] </script> <br>
			<script src="externalfile.js"></script>
			</code>

	==== Cross-origin Resource Sharing ====		==== Cross-origin Resource Sharing ====
	Der HTTP-Header "Access-Control-Allow-Origin" gibt an, welche anderen Domains auf den Inhalt der eigenen Domain über Scripte zugreifen dürfen. Dabei wird die Same-Origin-Policy <ref>https://de.wikipedia.org/wiki/Same-Origin-Policy</ref> bewusst umgangen, um z.B. über Domain-Grenzen hinweg Web-Applikationen in einer gemeinsamen Oberfläche zu kombinieren. Dieser Header sollte nur vorhanden sein, falls dies unbedingt benötigt wird und sollte auf so wenig Domains wie nötig beschränkt werden. Als Beispiel sollte ein Server, der eine Webseite und eine API betreibt und den Dienst XMLHttpRequest access auf einer Remote-Webseite anbietet, sollte nur die API den Access-Control-Allow-Origin Header senden.<ref>https://wiki.mozilla.org/Security/Guidelines/Web_Security</ref> <br>		Der HTTP-Header "Access-Control-Allow-Origin" gibt an, welche anderen Domains auf den Inhalt der eigenen Domain über Scripte zugreifen dürfen. Dabei wird die Same-Origin-Policy <ref>https://de.wikipedia.org/wiki/Same-Origin-Policy</ref> bewusst umgangen, um z.B. über Domain-Grenzen hinweg Web-Applikationen in einer gemeinsamen Oberfläche zu kombinieren. Dieser Header sollte nur vorhanden sein, falls dies unbedingt benötigt wird und sollte auf so wenig Domains wie nötig beschränkt werden. Als Beispiel sollte ein Server, der eine Webseite und eine API betreibt und den Dienst XMLHttpRequest access auf einer Remote-Webseite anbietet, sollte nur die API den Access-Control-Allow-Origin Header senden.<ref>https://wiki.mozilla.org/Security/Guidelines/Web_Security</ref> <br>