Sicherheitsanalyse Webanwendung - Versionsgeschichte

Kowa am 3. August 2019 um 12:51 Uhr

2019-08-03T12:51:10Z

← Nächstältere Version		Version vom 3. August 2019, 12:51 Uhr
Zeile 62:		Zeile 62:

	[[Kategorie:Web-Programmierung]]		[[Kategorie:Web-Programmierung]]
	~~[[Kategorie:Internet]]~~

Kowa am 3. August 2019 um 12:50 Uhr

2019-08-03T12:50:23Z

← Nächstältere Version		Version vom 3. August 2019, 12:50 Uhr
Zeile 1:		Zeile 1:
	{{~~In Bearbeitung~~}}		{{Qualität
			\|correctness = 2
			\|extent = 2
			\|numberOfReferences = 1
			\|qualityOfReferences = 3
			\|conformance = 3
			}}

	==Definition==		==Definition==

Kowa am 3. August 2019 um 12:47 Uhr

2019-08-03T12:47:06Z

← Nächstältere Version		Version vom 3. August 2019, 12:47 Uhr
Zeile 55:		Zeile 55:
	*[http://www.heise.de/security/Sicherheit-von-Webanwendungen--/artikel/84149 Gesundes Misstrauen]		*[http://www.heise.de/security/Sicherheit-von-Webanwendungen--/artikel/84149 Gesundes Misstrauen]

	[[Kategorie:Programmierung]]		[[Kategorie:Web-Programmierung]]
	[[Kategorie:Internet]]		[[Kategorie:Internet]]

Kowa am 23. Mai 2019 um 13:18 Uhr

2019-05-23T13:18:38Z

← Nächstältere Version		Version vom 23. Mai 2019, 13:18 Uhr
Zeile 1:		Zeile 1:
	{{In Bearbeitung}}		{{In Bearbeitung}}

	=Definition=		==Definition==
	Schwachstellen in Internetanwendungen sind heutzutage allgegenwärtig. Die große Vielfalt an Technologien in Verbindung mit der Struktur für eine Softwareanwendung im Internet bieten daher viele verschiedene Angriffsmöglichkeiten und Schwachstellen. Um das Potenzial so gering wie möglich zu halten, ist es wichtig keine offensichtlichen oder bekannten Fehler in den Algorithmen und Strukturen der Anwendung zu haben.		Schwachstellen in Internetanwendungen sind heutzutage allgegenwärtig. Die große Vielfalt an Technologien in Verbindung mit der Struktur für eine Softwareanwendung im Internet bieten daher viele verschiedene Angriffsmöglichkeiten und Schwachstellen. Um das Potenzial so gering wie möglich zu halten, ist es wichtig keine offensichtlichen oder bekannten Fehler in den Algorithmen und Strukturen der Anwendung zu haben.

	=Verfahren=		==Verfahren==

	Basierend auf dem Maßnahmenkatalog „Sicherheit von Webanwendungen[2]“ des „Bundesamt für Sicherheit in der Informationstechnik“ (kurz BSI) kann eine Analyse der typischen Schwachstellen durchgeführt. Das Dokument beinhaltet einen sehr übersichtlichen Maßnahmenkatalog. Die einzelnen Maßnahmen müssen für die Analyse nach ihrer Relevanz für die Anwendung sortiert und gewertet.		Basierend auf dem Maßnahmenkatalog „Sicherheit von Webanwendungen[2]“ des „Bundesamt für Sicherheit in der Informationstechnik“ (kurz BSI) kann eine Analyse der typischen Schwachstellen durchgeführt. Das Dokument beinhaltet einen sehr übersichtlichen Maßnahmenkatalog. Die einzelnen Maßnahmen müssen für die Analyse nach ihrer Relevanz für die Anwendung sortiert und gewertet.

	=Beispiele=		==Beispiele==

	Im folgenden sind ein paar Beispielmaßnahmen aus dem Katalog aufgelistet.		Im folgenden sind ein paar Beispielmaßnahmen aus dem Katalog aufgelistet.

	==M100 Data Validation: Filterung==		===M100 Data Validation: Filterung===
	Alle Daten, die von außen in die Anwendung gelangen, sind zu validieren und zu fil		Alle Daten, die von außen in die Anwendung gelangen, sind zu validieren und zu fil
	tern. Neben den offensichtlichen Eingabedaten in Form-Variablen existieren eine		tern. Neben den offensichtlichen Eingabedaten in Form-Variablen existieren eine
Zeile 20:		Zeile 20:


	==M110 Data Validation: Whitelisting statt Blacklisting==		===M110 Data Validation: Whitelisting statt Blacklisting===

	Eine grundsätzliche Entscheidung ist die Wahl des Validierungs- bzw. Filterprinzips:		Eine grundsätzliche Entscheidung ist die Wahl des Validierungs- bzw. Filterprinzips:
Zeile 29:		Zeile 29:
	der weiteren Verarbeitung zu einem ungewollten Systemverhalten führen.		der weiteren Verarbeitung zu einem ungewollten Systemverhalten führen.

	==M140 Data Validation: SQL-Injection verhindern==		===M140 Data Validation: SQL-Injection verhindern===

	Durch Verwendung von Prepared Statements anstatt dynamisch zusammengebauter		Durch Verwendung von Prepared Statements anstatt dynamisch zusammengebauter
Zeile 37:		Zeile 37:
	vom Input zur Ausführung gelangen können.		vom Input zur Ausführung gelangen können.

	==M150 Data Validation: Diverse Maßnahmen==		===M150 Data Validation: Diverse Maßnahmen===
	* Namen von Formularen überprüfen		* Namen von Formularen überprüfen
	* Länge/Größe der Eingabedaten begrenzen		* Länge/Größe der Eingabedaten begrenzen
Zeile 44:		Zeile 44:
	* Ausgabedaten filtern		* Ausgabedaten filtern

	==M170 Session Management==		===M170 Session Management===

	* SessionID nach Authentisierung erneuern		* SessionID nach Authentisierung erneuern
Zeile 50:		Zeile 50:
	* Session beenden		* Session beenden

			==Quellen==

	=Quellen=

	*[http://www.bsi.bund.de/literat/studien/websec/WebSec.pdf Sicherheit von Webanwendungen]		*[http://www.bsi.bund.de/literat/studien/websec/WebSec.pdf Sicherheit von Webanwendungen]

Sauterbe: /* Quellen */

2008-07-08T05:59:10Z

Quellen

← Nächstältere Version		Version vom 8. Juli 2008, 05:59 Uhr
Zeile 55:		Zeile 55:

	*[http://www.bsi.bund.de/literat/studien/websec/WebSec.pdf Sicherheit von Webanwendungen]		*[http://www.bsi.bund.de/literat/studien/websec/WebSec.pdf Sicherheit von Webanwendungen]
			*[http://www.heise.de/security/Sicherheit-von-Webanwendungen--/artikel/84149 Gesundes Misstrauen]

	[[Kategorie:Programmierung]]		[[Kategorie:Programmierung]]
	[[Kategorie:Internet]]		[[Kategorie:Internet]]

Sauterbe: hat Sicherheitsanalyse nach Sicherheitsanalyse Webanwendung verschoben: passt mehr, das war ja auch mein Thema aus der Arbeit

2008-07-08T05:58:23Z

hat Sicherheitsanalyse nach Sicherheitsanalyse Webanwendung verschoben: passt mehr, das war ja auch mein Thema aus der Arbeit

← Nächstältere Version	Version vom 8. Juli 2008, 05:58 Uhr
(kein Unterschied)

Sauterbe am 8. Juli 2008 um 05:54 Uhr

2008-07-08T05:54:25Z

← Nächstältere Version		Version vom 8. Juli 2008, 05:54 Uhr
Zeile 10:		Zeile 10:
	=Beispiele=		=Beispiele=

			Im folgenden sind ein paar Beispielmaßnahmen aus dem Katalog aufgelistet.

	==M100 Data Validation: Filterung==		==M100 Data Validation: Filterung==

Sauterbe: /* Quellen */

2008-07-08T05:53:24Z

Quellen

← Nächstältere Version		Version vom 8. Juli 2008, 05:53 Uhr
Zeile 53:		Zeile 53:
	=Quellen=		=Quellen=

	*[www.bsi.bund.de/literat/studien/websec/WebSec.pdf Sicherheit von Webanwendungen]		*[http://www.bsi.bund.de/literat/studien/websec/WebSec.pdf Sicherheit von Webanwendungen]


	[[Kategorie:Programmierung]]		[[Kategorie:Programmierung]]
	[[Kategorie:Internet]]		[[Kategorie:Internet]]

Sauterbe am 8. Juli 2008 um 05:53 Uhr

2008-07-08T05:53:05Z

Neue Seite

{{In Bearbeitung}}

=Definition=
Schwachstellen in Internetanwendungen sind heutzutage allgegenwärtig. Die große Vielfalt an Technologien in Verbindung mit der Struktur für eine Softwareanwendung im Internet bieten daher viele verschiedene Angriffsmöglichkeiten und Schwachstellen. Um das Potenzial so gering wie möglich zu halten, ist es wichtig keine offensichtlichen oder bekannten Fehler in den Algorithmen und Strukturen der Anwendung zu haben.

=Verfahren=

Basierend auf dem Maßnahmenkatalog „Sicherheit von Webanwendungen[2]“ des „Bundesamt für Sicherheit in der Informationstechnik“ (kurz BSI) kann eine Analyse der typischen Schwachstellen durchgeführt. Das Dokument beinhaltet einen sehr übersichtlichen Maßnahmenkatalog. Die einzelnen Maßnahmen müssen für die Analyse nach ihrer Relevanz für die Anwendung sortiert und gewertet.

=Beispiele=

==M100 Data Validation: Filterung==
Alle Daten, die von außen in die Anwendung gelangen, sind zu validieren und zu fil
tern. Neben den offensichtlichen Eingabedaten in Form-Variablen existieren eine
Reihe weiterer Quellen. Ebenso sind Ausgaben an den Browser zu filtern, wenn dies
nicht bereits durch die Inputfilterung mit abgedeckt ist. Der Abschnitt "Output Filte
rung" geht auf diese Frage näher ein.

==M110 Data Validation: Whitelisting statt Blacklisting==

Eine grundsätzliche Entscheidung ist die Wahl des Validierungs- bzw. Filterprinzips:
Blacklisting oder Whitelisting. Beim Blacklisting werden die Muster definiert, die
aus dem Eingabestrom herausgefiltert werden, alles andere wird durchgelassen. Beim
Whitelisting ist es umgekehrt: was nicht ausdrücklich erlaubt ist, ist verboten. Black
listing ist dann problematisch, wenn als "nicht kritisch" erkannte Zeichen im Verlaufe
der weiteren Verarbeitung zu einem ungewollten Systemverhalten führen.

==M140 Data Validation: SQL-Injection verhindern==

Durch Verwendung von Prepared Statements anstatt dynamisch zusammengebauter
SQL-Statements kann dem Problem der SQL-Injection aus dem Weg gegangen wer
den. Software-Entwickler müssen sich im Rahmen des Designs einer Funktion oder
hat bzw. was die Menge aller möglichen Abfragestrukturen ist, die in Abhängigkeit
vom Input zur Ausführung gelangen können.

==M150 Data Validation: Diverse Maßnahmen==
* Namen von Formularen überprüfen
* Länge/Größe der Eingabedaten begrenzen
* Serverseitig validieren
* Datentypen der Eingabedaten
* Ausgabedaten filtern

==M170 Session Management==

* SessionID nach Authentisierung erneuern
* Cookies einschränken
* Session beenden

=Quellen=

*[www.bsi.bund.de/literat/studien/websec/WebSec.pdf Sicherheit von Webanwendungen]

[[Kategorie:Programmierung]]
[[Kategorie:Internet]]