https://glossar.hs-augsburg.de/w/api.php?action=feedcontributions&feedformat=atom&user=Sauterbe 2026-07-19T11:44:17Z Benutzerbeiträge MediaWiki 1.43.3 https://glossar.hs-augsburg.de/w/index.php?title=Sicherheitsanalyse_Webanwendung&diff=12005 2008-07-08T05:59:10Z

<p>Sauterbe: /* Quellen */</p> <hr /> <div>{{In Bearbeitung}}<br /> <br /> =Definition=<br /> 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. <br /> <br /> =Verfahren=<br /> <br /> 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. <br /> <br /> =Beispiele=<br /> <br /> Im folgenden sind ein paar Beispielmaßnahmen aus dem Katalog aufgelistet.<br /> <br /> ==M100 Data Validation: Filterung==<br /> Alle Daten, die von außen in die Anwendung gelangen, sind zu validieren und zu fil­<br /> tern. Neben den offensichtlichen Eingabedaten in Form-Variablen existieren eine<br /> Reihe weiterer Quellen. Ebenso sind Ausgaben an den Browser zu filtern, wenn dies<br /> nicht bereits durch die Inputfilterung mit abgedeckt ist. Der Abschnitt &quot;Output Filte­<br /> rung&quot; geht auf diese Frage näher ein.<br /> <br /> <br /> ==M110 Data Validation: Whitelisting statt Blacklisting==<br /> <br /> Eine grundsätzliche Entscheidung ist die Wahl des Validierungs- bzw. Filterprinzips:<br /> Blacklisting oder Whitelisting. Beim Blacklisting werden die Muster definiert, die<br /> aus dem Eingabestrom herausgefiltert werden, alles andere wird durchgelassen. Beim<br /> Whitelisting ist es umgekehrt: was nicht ausdrücklich erlaubt ist, ist verboten. Black­<br /> listing ist dann problematisch, wenn als &quot;nicht kritisch&quot; erkannte Zeichen im Verlaufe<br /> der weiteren Verarbeitung zu einem ungewollten Systemverhalten führen.<br /> <br /> ==M140 Data Validation: SQL-Injection verhindern==<br /> <br /> Durch Verwendung von Prepared Statements anstatt dynamisch zusammengebauter<br /> SQL-Statements kann dem Problem der SQL-Injection aus dem Weg gegangen wer­<br /> den. Software-Entwickler müssen sich im Rahmen des Designs einer Funktion oder<br /> hat bzw. was die Menge aller möglichen Abfragestrukturen ist, die in Abhängigkeit<br /> vom Input zur Ausführung gelangen können. <br /> <br /> ==M150 Data Validation: Diverse Maßnahmen==<br /> * Namen von Formularen überprüfen<br /> * Länge/Größe der Eingabedaten begrenzen<br /> * Serverseitig validieren<br /> * Datentypen der Eingabedaten<br /> * Ausgabedaten filtern<br /> <br /> ==M170 Session Management==<br /> <br /> * SessionID nach Authentisierung erneuern<br /> * Cookies einschränken<br /> * Session beenden<br /> <br /> <br /> <br /> =Quellen=<br /> <br /> *[http://www.bsi.bund.de/literat/studien/websec/WebSec.pdf Sicherheit von Webanwendungen]<br /> *[http://www.heise.de/security/Sicherheit-von-Webanwendungen--/artikel/84149 Gesundes Misstrauen]<br /> <br /> [[Kategorie:Programmierung]]<br /> [[Kategorie:Internet]]</div>

Sauterbe https://glossar.hs-augsburg.de/w/index.php?title=Sicherheitsanalyse&diff=12004 2008-07-08T05:58:23Z

<p>Sauterbe: hat Sicherheitsanalyse nach Sicherheitsanalyse Webanwendung verschoben: passt mehr, das war ja auch mein Thema aus der Arbeit</p> <hr /> <div>#REDIRECT [[Sicherheitsanalyse Webanwendung]]</div>

Sauterbe https://glossar.hs-augsburg.de/w/index.php?title=Sicherheitsanalyse_Webanwendung&diff=12003 2008-07-08T05:58:23Z

<p>Sauterbe: hat Sicherheitsanalyse nach Sicherheitsanalyse Webanwendung verschoben: passt mehr, das war ja auch mein Thema aus der Arbeit</p> <hr /> <div>{{In Bearbeitung}}<br /> <br /> =Definition=<br /> 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. <br /> <br /> =Verfahren=<br /> <br /> 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. <br /> <br /> =Beispiele=<br /> <br /> Im folgenden sind ein paar Beispielmaßnahmen aus dem Katalog aufgelistet.<br /> <br /> ==M100 Data Validation: Filterung==<br /> Alle Daten, die von außen in die Anwendung gelangen, sind zu validieren und zu fil­<br /> tern. Neben den offensichtlichen Eingabedaten in Form-Variablen existieren eine<br /> Reihe weiterer Quellen. Ebenso sind Ausgaben an den Browser zu filtern, wenn dies<br /> nicht bereits durch die Inputfilterung mit abgedeckt ist. Der Abschnitt &quot;Output Filte­<br /> rung&quot; geht auf diese Frage näher ein.<br /> <br /> <br /> ==M110 Data Validation: Whitelisting statt Blacklisting==<br /> <br /> Eine grundsätzliche Entscheidung ist die Wahl des Validierungs- bzw. Filterprinzips:<br /> Blacklisting oder Whitelisting. Beim Blacklisting werden die Muster definiert, die<br /> aus dem Eingabestrom herausgefiltert werden, alles andere wird durchgelassen. Beim<br /> Whitelisting ist es umgekehrt: was nicht ausdrücklich erlaubt ist, ist verboten. Black­<br /> listing ist dann problematisch, wenn als &quot;nicht kritisch&quot; erkannte Zeichen im Verlaufe<br /> der weiteren Verarbeitung zu einem ungewollten Systemverhalten führen.<br /> <br /> ==M140 Data Validation: SQL-Injection verhindern==<br /> <br /> Durch Verwendung von Prepared Statements anstatt dynamisch zusammengebauter<br /> SQL-Statements kann dem Problem der SQL-Injection aus dem Weg gegangen wer­<br /> den. Software-Entwickler müssen sich im Rahmen des Designs einer Funktion oder<br /> hat bzw. was die Menge aller möglichen Abfragestrukturen ist, die in Abhängigkeit<br /> vom Input zur Ausführung gelangen können. <br /> <br /> ==M150 Data Validation: Diverse Maßnahmen==<br /> * Namen von Formularen überprüfen<br /> * Länge/Größe der Eingabedaten begrenzen<br /> * Serverseitig validieren<br /> * Datentypen der Eingabedaten<br /> * Ausgabedaten filtern<br /> <br /> ==M170 Session Management==<br /> <br /> * SessionID nach Authentisierung erneuern<br /> * Cookies einschränken<br /> * Session beenden<br /> <br /> <br /> <br /> =Quellen=<br /> <br /> *[http://www.bsi.bund.de/literat/studien/websec/WebSec.pdf Sicherheit von Webanwendungen]<br /> <br /> <br /> [[Kategorie:Programmierung]]<br /> [[Kategorie:Internet]]</div>

Sauterbe https://glossar.hs-augsburg.de/w/index.php?title=Sicherheitsanalyse_Webanwendung&diff=12002 2008-07-08T05:54:25Z

<p>Sauterbe: </p> <hr /> <div>{{In Bearbeitung}}<br /> <br /> =Definition=<br /> 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. <br /> <br /> =Verfahren=<br /> <br /> 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. <br /> <br /> =Beispiele=<br /> <br /> Im folgenden sind ein paar Beispielmaßnahmen aus dem Katalog aufgelistet.<br /> <br /> ==M100 Data Validation: Filterung==<br /> Alle Daten, die von außen in die Anwendung gelangen, sind zu validieren und zu fil­<br /> tern. Neben den offensichtlichen Eingabedaten in Form-Variablen existieren eine<br /> Reihe weiterer Quellen. Ebenso sind Ausgaben an den Browser zu filtern, wenn dies<br /> nicht bereits durch die Inputfilterung mit abgedeckt ist. Der Abschnitt &quot;Output Filte­<br /> rung&quot; geht auf diese Frage näher ein.<br /> <br /> <br /> ==M110 Data Validation: Whitelisting statt Blacklisting==<br /> <br /> Eine grundsätzliche Entscheidung ist die Wahl des Validierungs- bzw. Filterprinzips:<br /> Blacklisting oder Whitelisting. Beim Blacklisting werden die Muster definiert, die<br /> aus dem Eingabestrom herausgefiltert werden, alles andere wird durchgelassen. Beim<br /> Whitelisting ist es umgekehrt: was nicht ausdrücklich erlaubt ist, ist verboten. Black­<br /> listing ist dann problematisch, wenn als &quot;nicht kritisch&quot; erkannte Zeichen im Verlaufe<br /> der weiteren Verarbeitung zu einem ungewollten Systemverhalten führen.<br /> <br /> ==M140 Data Validation: SQL-Injection verhindern==<br /> <br /> Durch Verwendung von Prepared Statements anstatt dynamisch zusammengebauter<br /> SQL-Statements kann dem Problem der SQL-Injection aus dem Weg gegangen wer­<br /> den. Software-Entwickler müssen sich im Rahmen des Designs einer Funktion oder<br /> hat bzw. was die Menge aller möglichen Abfragestrukturen ist, die in Abhängigkeit<br /> vom Input zur Ausführung gelangen können. <br /> <br /> ==M150 Data Validation: Diverse Maßnahmen==<br /> * Namen von Formularen überprüfen<br /> * Länge/Größe der Eingabedaten begrenzen<br /> * Serverseitig validieren<br /> * Datentypen der Eingabedaten<br /> * Ausgabedaten filtern<br /> <br /> ==M170 Session Management==<br /> <br /> * SessionID nach Authentisierung erneuern<br /> * Cookies einschränken<br /> * Session beenden<br /> <br /> <br /> <br /> =Quellen=<br /> <br /> *[http://www.bsi.bund.de/literat/studien/websec/WebSec.pdf Sicherheit von Webanwendungen]<br /> <br /> <br /> [[Kategorie:Programmierung]]<br /> [[Kategorie:Internet]]</div>

Sauterbe https://glossar.hs-augsburg.de/w/index.php?title=Sicherheitsanalyse_Webanwendung&diff=12001 2008-07-08T05:53:24Z

<p>Sauterbe: /* Quellen */</p> <hr /> <div>{{In Bearbeitung}}<br /> <br /> =Definition=<br /> 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. <br /> <br /> =Verfahren=<br /> <br /> 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. <br /> <br /> =Beispiele=<br /> <br /> <br /> ==M100 Data Validation: Filterung==<br /> Alle Daten, die von außen in die Anwendung gelangen, sind zu validieren und zu fil­<br /> tern. Neben den offensichtlichen Eingabedaten in Form-Variablen existieren eine<br /> Reihe weiterer Quellen. Ebenso sind Ausgaben an den Browser zu filtern, wenn dies<br /> nicht bereits durch die Inputfilterung mit abgedeckt ist. Der Abschnitt &quot;Output Filte­<br /> rung&quot; geht auf diese Frage näher ein.<br /> <br /> <br /> ==M110 Data Validation: Whitelisting statt Blacklisting==<br /> <br /> Eine grundsätzliche Entscheidung ist die Wahl des Validierungs- bzw. Filterprinzips:<br /> Blacklisting oder Whitelisting. Beim Blacklisting werden die Muster definiert, die<br /> aus dem Eingabestrom herausgefiltert werden, alles andere wird durchgelassen. Beim<br /> Whitelisting ist es umgekehrt: was nicht ausdrücklich erlaubt ist, ist verboten. Black­<br /> listing ist dann problematisch, wenn als &quot;nicht kritisch&quot; erkannte Zeichen im Verlaufe<br /> der weiteren Verarbeitung zu einem ungewollten Systemverhalten führen.<br /> <br /> ==M140 Data Validation: SQL-Injection verhindern==<br /> <br /> Durch Verwendung von Prepared Statements anstatt dynamisch zusammengebauter<br /> SQL-Statements kann dem Problem der SQL-Injection aus dem Weg gegangen wer­<br /> den. Software-Entwickler müssen sich im Rahmen des Designs einer Funktion oder<br /> hat bzw. was die Menge aller möglichen Abfragestrukturen ist, die in Abhängigkeit<br /> vom Input zur Ausführung gelangen können. <br /> <br /> ==M150 Data Validation: Diverse Maßnahmen==<br /> * Namen von Formularen überprüfen<br /> * Länge/Größe der Eingabedaten begrenzen<br /> * Serverseitig validieren<br /> * Datentypen der Eingabedaten<br /> * Ausgabedaten filtern<br /> <br /> ==M170 Session Management==<br /> <br /> * SessionID nach Authentisierung erneuern<br /> * Cookies einschränken<br /> * Session beenden<br /> <br /> <br /> <br /> =Quellen=<br /> <br /> *[http://www.bsi.bund.de/literat/studien/websec/WebSec.pdf Sicherheit von Webanwendungen]<br /> <br /> <br /> [[Kategorie:Programmierung]]<br /> [[Kategorie:Internet]]</div>

Sauterbe https://glossar.hs-augsburg.de/w/index.php?title=Sicherheitsanalyse_Webanwendung&diff=12000 2008-07-08T05:53:05Z

<p>Sauterbe: </p> <hr /> <div>{{In Bearbeitung}}<br /> <br /> =Definition=<br /> 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. <br /> <br /> =Verfahren=<br /> <br /> 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. <br /> <br /> =Beispiele=<br /> <br /> <br /> ==M100 Data Validation: Filterung==<br /> Alle Daten, die von außen in die Anwendung gelangen, sind zu validieren und zu fil­<br /> tern. Neben den offensichtlichen Eingabedaten in Form-Variablen existieren eine<br /> Reihe weiterer Quellen. Ebenso sind Ausgaben an den Browser zu filtern, wenn dies<br /> nicht bereits durch die Inputfilterung mit abgedeckt ist. Der Abschnitt &quot;Output Filte­<br /> rung&quot; geht auf diese Frage näher ein.<br /> <br /> <br /> ==M110 Data Validation: Whitelisting statt Blacklisting==<br /> <br /> Eine grundsätzliche Entscheidung ist die Wahl des Validierungs- bzw. Filterprinzips:<br /> Blacklisting oder Whitelisting. Beim Blacklisting werden die Muster definiert, die<br /> aus dem Eingabestrom herausgefiltert werden, alles andere wird durchgelassen. Beim<br /> Whitelisting ist es umgekehrt: was nicht ausdrücklich erlaubt ist, ist verboten. Black­<br /> listing ist dann problematisch, wenn als &quot;nicht kritisch&quot; erkannte Zeichen im Verlaufe<br /> der weiteren Verarbeitung zu einem ungewollten Systemverhalten führen.<br /> <br /> ==M140 Data Validation: SQL-Injection verhindern==<br /> <br /> Durch Verwendung von Prepared Statements anstatt dynamisch zusammengebauter<br /> SQL-Statements kann dem Problem der SQL-Injection aus dem Weg gegangen wer­<br /> den. Software-Entwickler müssen sich im Rahmen des Designs einer Funktion oder<br /> hat bzw. was die Menge aller möglichen Abfragestrukturen ist, die in Abhängigkeit<br /> vom Input zur Ausführung gelangen können. <br /> <br /> ==M150 Data Validation: Diverse Maßnahmen==<br /> * Namen von Formularen überprüfen<br /> * Länge/Größe der Eingabedaten begrenzen<br /> * Serverseitig validieren<br /> * Datentypen der Eingabedaten<br /> * Ausgabedaten filtern<br /> <br /> ==M170 Session Management==<br /> <br /> * SessionID nach Authentisierung erneuern<br /> * Cookies einschränken<br /> * Session beenden<br /> <br /> <br /> <br /> =Quellen=<br /> <br /> *[www.bsi.bund.de/literat/studien/websec/WebSec.pdf Sicherheit von Webanwendungen]<br /> <br /> <br /> [[Kategorie:Programmierung]]<br /> [[Kategorie:Internet]]</div>

Sauterbe