SQL-Injection - Versionsgeschichte

Spacetimebread: /* growthexperiments-addlink-summary-summary:2|0|0 */

2025-05-08T12:01:42Z

Linkvorschlag-Funktion: 2 Links hinzugefügt.

← Nächstältere Version		Version vom 8. Mai 2025, 14:01 Uhr
Zeile 24:		Zeile 24:

	== Beispiel ==		== Beispiel ==
	Ein Beispiel für eine SQL-Abfrage, die in einem Redaktionssystem nach Artikeln aus einer bestimmten Kategorie sucht, ist:		Ein Beispiel für eine SQL-Abfrage, die in einem [[Redaktionssystem]] nach Artikeln aus einer bestimmten Kategorie sucht, ist:

	:<syntaxhighlight lang="SQL">SELECT id, titel, artikeltext FROM artikel WHERE kategorie = 'gesuchte Kategorie';</syntaxhighlight>		:<syntaxhighlight lang="SQL">SELECT id, titel, artikeltext FROM artikel WHERE kategorie = 'gesuchte Kategorie';</syntaxhighlight>
Zeile 395:		Zeile 395:

	=== ColdFusion Markup Language ===		=== ColdFusion Markup Language ===
	Unter ColdFusion kann das <code><cfqueryparam></code>-Tag verwendet werden, welches sämtliche notwendigen		Unter [[ColdFusion]] kann das <code><cfqueryparam></code>-Tag verwendet werden, welches sämtliche notwendigen
	Validierungen übernimmt:<ref>{{Webarchiv\|text=ColdFusion Online-Hilfe \|url=http://livedocs.macromedia.com/coldfusion/7/htmldocs/00000317.htm \|wayback=20061124152957}}</ref>		Validierungen übernimmt:<ref>{{Webarchiv\|text=ColdFusion Online-Hilfe \|url=http://livedocs.macromedia.com/coldfusion/7/htmldocs/00000317.htm \|wayback=20061124152957}}</ref>

TenWhile6: /* Python */ typo

2025-01-07T08:02:29Z

Python: typo

← Nächstältere Version		Version vom 7. Januar 2025, 10:02 Uhr
Zeile 233:		Zeile 233:

	=== Python ===		=== Python ===
	In Python gibt es mehrere Möglichkeiten, mit einer Datenbank zu kommunizieren. Eine davon ist [[SQLAlchemy]]. Um hierbei SQL Injection zu entgehen, sollte man rohe SQL Befehle vermeiden, sofern ~~dieser~~ durch Form- oder URL Anfragen manipuliert werden könnten. Nachfolgend ist ein solches Beispiel zu sehen:		In Python gibt es mehrere Möglichkeiten, mit einer Datenbank zu kommunizieren. Eine davon ist [[SQLAlchemy]]. Um hierbei SQL-Injection zu entgehen, sollte man rohe SQL-Befehle vermeiden, sofern diese durch Form- oder URL Anfragen manipuliert werden könnten. Nachfolgend ist ein solches Beispiel zu sehen:
	<syntaxhighlight lang="python3">		<syntaxhighlight lang="python3">
	db.engine.execute("SELECT * FROM table")		db.engine.execute("SELECT * FROM table")
	</syntaxhighlight>		</syntaxhighlight>
	Stattdessen wird dazu geraten die internen Funktionen und Methoden von SQLAlchemy zu nutzen, wie z. B. die Folgenden:<ref>{{Internetquelle \|url=http://pajhome.org.uk/blog/10_reasons_to_love_sqlalchemy.html \|titel=10 Reasons to love SQLAlchemy \|werk=pajhome.org.uk \|~~zugriff~~=2016-12-20}}</ref>		Stattdessen wird dazu geraten die internen Funktionen und Methoden von SQLAlchemy zu nutzen, wie z. B. die Folgenden:<ref>{{Internetquelle \|url=http://pajhome.org.uk/blog/10_reasons_to_love_sqlalchemy.html \|titel=10 Reasons to love SQLAlchemy \|werk=pajhome.org.uk \|abruf=2016-12-20}}</ref>
	<syntaxhighlight lang="python3">		<syntaxhighlight lang="python3">
	session.query(Order).get(order_id)		session.query(Order).get(order_id)

Invisigoth67: typo, form

2024-10-11T13:14:54Z

typo, form

← Nächstältere Version		Version vom 11. Oktober 2024, 15:14 Uhr
Zeile 45:		Zeile 45:
	:<syntaxhighlight lang="SQL">SELECT id, titel, artikeltext FROM artikel WHERE kategorie = 'asdfasdf' OR id < 100 OR kategorie = 'sdfgsdfg';</syntaxhighlight>		:<syntaxhighlight lang="SQL">SELECT id, titel, artikeltext FROM artikel WHERE kategorie = 'asdfasdf' OR id < 100 OR kategorie = 'sdfgsdfg';</syntaxhighlight>

	Diese Abfrage ist aus Sicht der Datenbank völlig korrekt, sie enthält 3 einzelne Bedingungen, von denen mindestens eine wahr sein muss. Die erste und dritte Bedingung haben in diesem Beispiel nur die Aufgabe, dass die SQL-Abfrage weiterhin [[Syntax#~~Syntax_formaler_Sprachen~~\|wohlgeformt]] ist, und es ist unwahrscheinlich, dass es in der Datenbank tatsächlich Kategorien dieses Namens gibt. Daher bleibt als einzig relevante Bedingung <code>id < 100</code> übrig. Aus der ursprünglichen SQL-Abfrage, die nur Artikel aus einer bestimmten Kategorie liefert, ist durch geschickte Wahl des Suchbegriffs eine strukturell andere SQL-Abfrage geworden, die nun die Artikel anhand ihrer ID sucht, unabhängig von der Kategorie.		Diese Abfrage ist aus Sicht der Datenbank völlig korrekt, sie enthält 3 einzelne Bedingungen, von denen mindestens eine wahr sein muss. Die erste und dritte Bedingung haben in diesem Beispiel nur die Aufgabe, dass die SQL-Abfrage weiterhin [[Syntax#Syntax formaler Sprachen\|wohlgeformt]] ist, und es ist unwahrscheinlich, dass es in der Datenbank tatsächlich Kategorien dieses Namens gibt. Daher bleibt als einzig relevante Bedingung <code>id < 100</code> übrig. Aus der ursprünglichen SQL-Abfrage, die nur Artikel aus einer bestimmten Kategorie liefert, ist durch geschickte Wahl des Suchbegriffs eine strukturell andere SQL-Abfrage geworden, die nun die Artikel anhand ihrer ID sucht, unabhängig von der Kategorie.

	Durch diese geänderte SQL-Abfrage kann ein Angreifer möglicherweise Daten aus der Datenbank sehen, die nicht für ihn bestimmt sind. Durch andere gezielte Suchbegriffe kann der Angreifer möglicherweise Daten in der Datenbank ändern oder löschen, je nach Einzelfall.		Durch diese geänderte SQL-Abfrage kann ein Angreifer möglicherweise Daten aus der Datenbank sehen, die nicht für ihn bestimmt sind. Durch andere gezielte Suchbegriffe kann der Angreifer möglicherweise Daten in der Datenbank ändern oder löschen, je nach Einzelfall.
Zeile 324:		Zeile 324:

	=== Java (JDBC) ===		=== Java (JDBC) ===
	Eine SQL-Injection kann leicht durch eine bereits vorhandene Funktion verhindert werden. In [[Java (Programmiersprache)\|Java]] wird zu diesem Zweck die PreparedStatement-Klasse verwendet ([[Java Database Connectivity\|JDBC]]-Technologie) und die Daten unsicherer Herkunft werden als getrennte Parameter übergeben. Um die Daten von der SQL-Anweisung zu trennen wird der Platzhalter „?“ verwendet.		Eine SQL-Injection kann leicht durch eine bereits vorhandene Funktion verhindert werden. In [[Java (Programmiersprache)\|Java]] wird zu diesem Zweck die PreparedStatement-Klasse verwendet ([[Java Database Connectivity\|JDBC]]-Technologie) und die Daten unsicherer Herkunft werden als getrennte Parameter übergeben. Um die Daten von der SQL-Anweisung zu trennen, wird der Platzhalter „?“ verwendet.

	Anstatt		Anstatt

InternetArchiveBot: InternetArchiveBot hat 1 Archivlink(s) ergänzt und 0 Link(s) als defekt/tot markiert.) #IABot (v2.0.9.5

2024-05-01T18:56:44Z

InternetArchiveBot hat 1 Archivlink(s) ergänzt und 0 Link(s) als defekt/tot markiert.) #IABot (v2.0.9.5

← Nächstältere Version		Version vom 1. Mai 2024, 20:56 Uhr
Zeile 361:		Zeile 361:
	</syntaxhighlight>		</syntaxhighlight>

	Bis zur PHP-Version 5.3 gab es die Konfigurationsoption „magic_quotes_gpc“. War diese auf „on“ gestellt, wurden von außen kommende Benutzereingaben automatisch maskiert. Manche Skripte nutzen Funktionen wie etwa <code>addslashes()</code><ref>[http://de.php.net/manual/de/function.addslashes.php addslashes] PHP Manual</ref> oder <code>mysql_real_escape_string()</code><ref>[http://de.php.net/manual/de/function.mysql-real-escape-string.php mysql_real_escape_string] PHP Manual</ref>. Das heißt, dass bereits allen relevanten Zeichen in den Benutzereingaben durch so genannte Magic Quotes<ref>[http://www.php.net/manual/de/security.magicquotes.php Magic Quotes] PHP Manual</ref> ein [[Backslash]] vorangestellt wurde und nun durch die Escape-Funktion erneut ein Backslash vorangestellt wird. Somit werden die Benutzereingaben verfälscht und man erhält beispielsweise anstatt eines einfachen Anführungszeichens ein Anführungszeichen mit vorangestelltem Backslash (<code>\"</code>). Auch aus Gründen der [[Plattformunabhängigkeit\|Portabilität]] sollte bei der Entwicklung von Anwendungen auf diese Einstellung verzichtet und stattdessen alle Eingaben manuell validiert und maskiert werden, da nicht davon ausgegangen werden kann, dass auf allen Systemen dieselben Einstellungen vorherrschen oder möglich sind. Darüber hinaus sollte <code>addSlashes()</code> nicht zum Maskieren von Datenbank-Eingaben benutzt werden, da es keine ausreichende Sicherheit gegenüber <code>mysql_real_escape_string()</code> gewährleistet.<ref>Chris Shiflett: [http://shiflett.org/blog/2006/jan/addslashes-versus-mysql-real-escape-string addslashes() Versus mysql_real_escape_string()] (englisch)</ref>		Bis zur PHP-Version 5.3 gab es die Konfigurationsoption „magic_quotes_gpc“. War diese auf „on“ gestellt, wurden von außen kommende Benutzereingaben automatisch maskiert. Manche Skripte nutzen Funktionen wie etwa <code>addslashes()</code><ref>[http://de.php.net/manual/de/function.addslashes.php addslashes] PHP Manual</ref> oder <code>mysql_real_escape_string()</code><ref>[http://de.php.net/manual/de/function.mysql-real-escape-string.php mysql_real_escape_string] PHP Manual</ref>. Das heißt, dass bereits allen relevanten Zeichen in den Benutzereingaben durch so genannte Magic Quotes<ref>{{Webarchiv\|url=http://www.php.net/manual/de/security.magicquotes.php \|wayback=20210103050704 \|text=Magic Quotes \|archiv-bot=2024-05-01 18:56:44 InternetArchiveBot }} PHP Manual</ref> ein [[Backslash]] vorangestellt wurde und nun durch die Escape-Funktion erneut ein Backslash vorangestellt wird. Somit werden die Benutzereingaben verfälscht und man erhält beispielsweise anstatt eines einfachen Anführungszeichens ein Anführungszeichen mit vorangestelltem Backslash (<code>\"</code>). Auch aus Gründen der [[Plattformunabhängigkeit\|Portabilität]] sollte bei der Entwicklung von Anwendungen auf diese Einstellung verzichtet und stattdessen alle Eingaben manuell validiert und maskiert werden, da nicht davon ausgegangen werden kann, dass auf allen Systemen dieselben Einstellungen vorherrschen oder möglich sind. Darüber hinaus sollte <code>addSlashes()</code> nicht zum Maskieren von Datenbank-Eingaben benutzt werden, da es keine ausreichende Sicherheit gegenüber <code>mysql_real_escape_string()</code> gewährleistet.<ref>Chris Shiflett: [http://shiflett.org/blog/2006/jan/addslashes-versus-mysql-real-escape-string addslashes() Versus mysql_real_escape_string()] (englisch)</ref>

	Nach der PHP-Version 5.3 wurde <code>mysql_real_escape_string()</code> durch [[MySQLi]] ersetzt. Ab der Version 7.0 ist <code>mysql_real_escape_string()</code> nicht mehr verfügbar. Ab PHP 7.x heißt die Funktion <code>mysqli_real_escape_string()</code>.		Nach der PHP-Version 5.3 wurde <code>mysql_real_escape_string()</code> durch [[MySQLi]] ersetzt. Ab der Version 7.0 ist <code>mysql_real_escape_string()</code> nicht mehr verfügbar. Ab PHP 7.x heißt die Funktion <code>mysqli_real_escape_string()</code>.

Ayzen am 20. März 2024 um 01:48 Uhr

2024-03-20T01:48:28Z

← Nächstältere Version		Version vom 20. März 2024, 03:48 Uhr
Zeile 45:		Zeile 45:
	:<syntaxhighlight lang="SQL">SELECT id, titel, artikeltext FROM artikel WHERE kategorie = 'asdfasdf' OR id < 100 OR kategorie = 'sdfgsdfg';</syntaxhighlight>		:<syntaxhighlight lang="SQL">SELECT id, titel, artikeltext FROM artikel WHERE kategorie = 'asdfasdf' OR id < 100 OR kategorie = 'sdfgsdfg';</syntaxhighlight>

	Diese Abfrage ist aus Sicht der Datenbank völlig korrekt, sie enthält 3 einzelne Bedingungen, von denen mindestens eine wahr sein muss. Die erste und dritte Bedingung haben in diesem Beispiel nur die Aufgabe, dass die SQL-Abfrage weiterhin [[Syntax#Syntax_formaler_Sprachen\|wohlgeformt]] ist, und es ist unwahrscheinlich, dass es in der Datenbank tatsächlich Kategorien ~~diesen~~ Namens gibt. Daher bleibt als einzig relevante Bedingung <code>id < 100</code> übrig. Aus der ursprünglichen SQL-Abfrage, die nur Artikel aus einer bestimmten Kategorie liefert, ist durch geschickte Wahl des Suchbegriffs eine strukturell andere SQL-Abfrage geworden, die nun die Artikel anhand ihrer ID sucht, unabhängig von der Kategorie.		Diese Abfrage ist aus Sicht der Datenbank völlig korrekt, sie enthält 3 einzelne Bedingungen, von denen mindestens eine wahr sein muss. Die erste und dritte Bedingung haben in diesem Beispiel nur die Aufgabe, dass die SQL-Abfrage weiterhin [[Syntax#Syntax_formaler_Sprachen\|wohlgeformt]] ist, und es ist unwahrscheinlich, dass es in der Datenbank tatsächlich Kategorien dieses Namens gibt. Daher bleibt als einzig relevante Bedingung <code>id < 100</code> übrig. Aus der ursprünglichen SQL-Abfrage, die nur Artikel aus einer bestimmten Kategorie liefert, ist durch geschickte Wahl des Suchbegriffs eine strukturell andere SQL-Abfrage geworden, die nun die Artikel anhand ihrer ID sucht, unabhängig von der Kategorie.

	Durch diese geänderte SQL-Abfrage kann ein Angreifer möglicherweise Daten aus der Datenbank sehen, die nicht für ihn bestimmt sind. Durch andere gezielte Suchbegriffe kann der Angreifer möglicherweise Daten in der Datenbank ändern oder löschen, je nach Einzelfall.		Durch diese geänderte SQL-Abfrage kann ein Angreifer möglicherweise Daten aus der Datenbank sehen, die nicht für ihn bestimmt sind. Durch andere gezielte Suchbegriffe kann der Angreifer möglicherweise Daten in der Datenbank ändern oder löschen, je nach Einzelfall.

Pockensupperl am 20. März 2024 um 01:40 Uhr

2024-03-20T01:40:53Z

← Nächstältere Version		Version vom 20. März 2024, 03:40 Uhr
Zeile 45:		Zeile 45:
	:<syntaxhighlight lang="SQL">SELECT id, titel, artikeltext FROM artikel WHERE kategorie = 'asdfasdf' OR id < 100 OR kategorie = 'sdfgsdfg';</syntaxhighlight>		:<syntaxhighlight lang="SQL">SELECT id, titel, artikeltext FROM artikel WHERE kategorie = 'asdfasdf' OR id < 100 OR kategorie = 'sdfgsdfg';</syntaxhighlight>

	Diese Abfrage ist aus Sicht der Datenbank völlig korrekt, sie enthält 3 einzelne Bedingungen, von denen mindestens eine wahr sein muss. Die erste und dritte Bedingung haben in diesem Beispiel nur die Aufgabe, dass die SQL-Abfrage weiterhin wohlgeformt ist, und es ist unwahrscheinlich, dass es in der Datenbank tatsächlich Kategorien diesen Namens gibt. Daher bleibt als einzig relevante Bedingung <code>id < 100</code> übrig. Aus der ursprünglichen SQL-Abfrage, die nur Artikel aus einer bestimmten Kategorie liefert, ist durch geschickte Wahl des Suchbegriffs eine strukturell andere SQL-Abfrage geworden, die nun die Artikel anhand ihrer ID sucht, unabhängig von der Kategorie.		Diese Abfrage ist aus Sicht der Datenbank völlig korrekt, sie enthält 3 einzelne Bedingungen, von denen mindestens eine wahr sein muss. Die erste und dritte Bedingung haben in diesem Beispiel nur die Aufgabe, dass die SQL-Abfrage weiterhin [[Syntax#Syntax_formaler_Sprachen\|wohlgeformt]] ist, und es ist unwahrscheinlich, dass es in der Datenbank tatsächlich Kategorien diesen Namens gibt. Daher bleibt als einzig relevante Bedingung <code>id < 100</code> übrig. Aus der ursprünglichen SQL-Abfrage, die nur Artikel aus einer bestimmten Kategorie liefert, ist durch geschickte Wahl des Suchbegriffs eine strukturell andere SQL-Abfrage geworden, die nun die Artikel anhand ihrer ID sucht, unabhängig von der Kategorie.

	Durch diese geänderte SQL-Abfrage kann ein Angreifer möglicherweise Daten aus der Datenbank sehen, die nicht für ihn bestimmt sind. Durch andere gezielte Suchbegriffe kann der Angreifer möglicherweise Daten in der Datenbank ändern oder löschen, je nach Einzelfall.		Durch diese geänderte SQL-Abfrage kann ein Angreifer möglicherweise Daten aus der Datenbank sehen, die nicht für ihn bestimmt sind. Durch andere gezielte Suchbegriffe kann der Angreifer möglicherweise Daten in der Datenbank ändern oder löschen, je nach Einzelfall.

BrunoBoehmler: /* Python */ Kolon vor statt hinter ref

2023-10-14T18:53:55Z

Python: Kolon vor statt hinter ref

← Nächstältere Version		Version vom 14. Oktober 2023, 20:53 Uhr
Zeile 237:		Zeile 237:
	db.engine.execute("SELECT * FROM table")		db.engine.execute("SELECT * FROM table")
	</syntaxhighlight>		</syntaxhighlight>
	Stattdessen wird dazu geraten die internen Funktionen und Methoden von SQLAlchemy zu nutzen, wie z. B. die Folgenden<ref>{{Internetquelle \|url=http://pajhome.org.uk/blog/10_reasons_to_love_sqlalchemy.html \|titel=10 Reasons to love SQLAlchemy \|werk=pajhome.org.uk \|zugriff=2016-12-20}}</ref>:		Stattdessen wird dazu geraten die internen Funktionen und Methoden von SQLAlchemy zu nutzen, wie z. B. die Folgenden:<ref>{{Internetquelle \|url=http://pajhome.org.uk/blog/10_reasons_to_love_sqlalchemy.html \|titel=10 Reasons to love SQLAlchemy \|werk=pajhome.org.uk \|zugriff=2016-12-20}}</ref>
	<syntaxhighlight lang="python3">		<syntaxhighlight lang="python3">
	session.query(Order).get(order_id)		session.query(Order).get(order_id)

BrunoBoehmler: /* Delphi */ Ellipsen

2023-10-14T18:50:27Z

Delphi: Ellipsen

← Nächstältere Version		Version vom 14. Oktober 2023, 20:50 Uhr
Zeile 268:		Zeile 268:
	Seit der BDE kennen die Querys Parameter. Die Syntax ist bei verschiedenen Komponentensammlungen nicht immer identisch aber ähnlich.		Seit der BDE kennen die Querys Parameter. Die Syntax ist bei verschiedenen Komponentensammlungen nicht immer identisch aber ähnlich.

	Anstatt~~...~~		Anstatt …

	<syntaxhighlight lang="Delphi">		<syntaxhighlight lang="Delphi">
Zeile 287:		Zeile 287:
	</syntaxhighlight>		</syntaxhighlight>

	~~...~~sollte definitiv mit Parametern gearbeitet werden:		… sollte definitiv mit Parametern gearbeitet werden:

	<syntaxhighlight lang="Delphi">		<syntaxhighlight lang="Delphi">

TenWhile6: Änderungen von Svenbansemer (Diskussion) wurden auf die letzte Version von Honigmacher zurückgesetzt: Problem oder Vandalismus

2023-09-01T08:29:50Z

Änderungen von Svenbansemer (Diskussion) wurden auf die letzte Version von Honigmacher zurückgesetzt: Problem oder Vandalismus

← Nächstältere Version		Version vom 1. September 2023, 10:29 Uhr
Zeile 422:		Zeile 422:
	* [https://xkcd.com/327/ SQL-Injection im Comic xkcd] ([[xkcd\|xkcd.com]])		* [https://xkcd.com/327/ SQL-Injection im Comic xkcd] ([[xkcd\|xkcd.com]])
	* [https://www.youtube.com/watch?v=8vM8b2P5uOo&list=PL4aVL6eAcvHnfoZ0aVKzQFVA0AZK7bn2f SQLi: Videos zur Durchführung und Gegenmaßnahmen]		* [https://www.youtube.com/watch?v=8vM8b2P5uOo&list=PL4aVL6eAcvHnfoZ0aVKzQFVA0AZK7bn2f SQLi: Videos zur Durchführung und Gegenmaßnahmen]
	* Was ist SQL-Injection und wie kann man sich verteidigen by

	== Einzelnachweise und Ressourcen ==		== Einzelnachweise und Ressourcen ==

Svenbansemer: /* Weblinks */ Ich habe einen Link zu einer Website gepostet, auf der erklärt wird, wie man sich gegen SQL-Injection verteidigt

2023-09-01T08:29:35Z

Weblinks: Ich habe einen Link zu einer Website gepostet, auf der erklärt wird, wie man sich gegen SQL-Injection verteidigt

← Nächstältere Version		Version vom 1. September 2023, 10:29 Uhr
Zeile 422:		Zeile 422:
	* [https://xkcd.com/327/ SQL-Injection im Comic xkcd] ([[xkcd\|xkcd.com]])		* [https://xkcd.com/327/ SQL-Injection im Comic xkcd] ([[xkcd\|xkcd.com]])
	* [https://www.youtube.com/watch?v=8vM8b2P5uOo&list=PL4aVL6eAcvHnfoZ0aVKzQFVA0AZK7bn2f SQLi: Videos zur Durchführung und Gegenmaßnahmen]		* [https://www.youtube.com/watch?v=8vM8b2P5uOo&list=PL4aVL6eAcvHnfoZ0aVKzQFVA0AZK7bn2f SQLi: Videos zur Durchführung und Gegenmaßnahmen]
			* Was ist SQL-Injection und wie kann man sich verteidigen by

	== Einzelnachweise und Ressourcen ==		== Einzelnachweise und Ressourcen ==