Diskussion:SQL-Injection

Dieser Artikel war am 6. Februar 2020 der Artikel des Tages.

Diese Diskussionsseite dient dazu, Verbesserungen am Artikel „SQL-Injection“ zu besprechen. Persönliche Betrachtungen zum Thema gehören nicht hierher. Für allgemeine Wissensfragen gibt es die Auskunft.

Füge neue Diskussionsthemen unten an:

Klicke auf Abschnitt hinzufügen, um ein neues Diskussionsthema zu beginnen, und unterschreibe deinen Beitrag bitte mit oder --~~~~.

• Diskussionsregeln
• Hilfe zu Diskussionsseiten
• Sei sachlich und freundlich!
• Greife niemanden persönlich an!
• Geh von guten Absichten aus.

Auf dieser Seite werden Abschnitte automatisch archiviert, deren jüngster Beitrag mehr als 360 Tage zurückliegt und die mindestens einen signierten Beitrag enthalten. Um die Diskussionsseite nicht komplett zu leeren, verbleiben mindestens 3 Abschnitte.

Archiv

Archiv

Wie wird ein Archiv angelegt?

MySQL Injection mit UNION

Im Text steht: "Allerdings kann ein Angreifer das UNION-Schlüsselwort verwenden, um weitere SQL-Statements (bei MySQL sogar UPDATE und DELETE) einzuschleusen." Das mit dem kombinieren zweier SELECT-Anweisungen durch UNION kann ich nachvollziehen. Ein Anhängen eines UPDATE, oder DELETE Befehls per UNION an einen SELECT Befehl funktioniert jedoch bei mir (PHP 5 und MySQL 5) nicht. Ist das wirklich möglich? (nicht signierter Beitrag von KnoXi (Diskussion | Beiträge) 23:53, 1. Mär. 2006 (CET))

---

So, ich habe gerade mal im Internet nachgeschaut. [1] UNION ist nur zum Verknüpfen von Anfragen (SELECT) da. Es vollkommener Schwachsinn, dass damit UPDATE bzw. DELETE Befehle eingeschleust werden können. In diesem Falle würde auch nur in einem Exploit-Code für z.B. phpBB ein Code existieren um die Adminrechte via. UNION zu ändern. FAZIT: Es geht nicht - ich entferne das eben. (nicht signierter Beitrag von 62.225.112.236 (Diskussion) 08:10, 23. Nov. 2006 (CET))

So ein Zufall aber auch...

https://www.tagesschau.de/investigativ/br-recherche/datenleck-drk-101.html (nicht signierter Beitrag von 109.42.1.9 (Diskussion) 22:11, 6. Feb. 2020 (CET))

Second Order SQL Injection

Im Artikel wird lediglich die "First-Order" SQL Injection behandelt, bei der das nächste (erste) ausgeführte SQL Statement direkt manipuliert wird. Hier ist aber noch lange nicht Schluss... Bei der "Second-Order" SQL Injection wird der Schadcode nicht unmittelbar ausgeführt. Ähnlich XSS (Cross-Site-Scripting Attacke) ist das Ziel, schadhaftes SQL in der Datenbank speichern zu lassen, um es an anderer Stelle (indirekt) ausführen zu lassen. Dabei kann die Ausführung des Schadcodes auch durch andere Personen (unwissentlich) erfolgen. Bemerkenswert ist, das Parametermaskierung NICHT gegen "Second-Order" Injections schützt. --94.31.101.215 10:43, 6. Okt. 2020 (CEST)