Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

--- modul:m183:learningunits:lu10:03 [2025/09/19 10:05] – [Parametrisierte Werteübergabe] vdemir
+++ modul:m183:learningunits:lu10:03 [2025/09/19 10:37] (aktuell) – vdemir
@@ Zeile 14: / Zeile 14: @@
 Die //parametrisierte Werteübergabe//, kurz //Parametrisierung// genannt, kann eine mögliche Gegenmassnahme gegen SQLI sein. Dabei werden die von User eingegebenen Werte in lokale Parameter geschrieben. Diese Werte werden dann einen Schritt später durch Platzhalter in das SQL-Statement eingefügt.
-Das nachfolgende JavaScript/MySQL-Beispiel soll diese Technik verdeutlichen:
+**Beispiel mit JavaScript/MySQL-Beispiel**
   // 1. Schritt: Zusammenbau des SQL-Statements mit Platzhaltern
@@ Zeile 49: / Zeile 49: @@
     }
   }
+  updateInventory();
-updateInventory();
+===== Input Validation =====
+**Input Validation** bedeutet, dass alle Eingaben aus unsicheren Quellen (User, Formulare, API-Aufrufe, Cookies, Query-Strings, etc.) müssen überprüft werden, bevor sie in die Anwendung oder die Datenbank gelangen. Das Ziel ist es nur Werte zulassen, die dem erwarteten Format entsprechen. Alles andere wird abgelehnt oder bereinigt.
+**Oder kurz:** <color #ed1c24>Traue nie dem Input – prüfe ihn, bevor du ihn anfasst.</color>
+===== Prepared Statement =====
+Ein //Prepared Statement// trennt klar Code (das SQL) von Daten (Benutzereingaben). Dadurch kann ein Angreifer die Struktur der Abfrage nicht durch manipulierte Eingaben verändern — und genau das ist der Kern jeder SQL-Injection.
+**Wie funktionieren sie?**
+  - Die Anwendung schickt ein SQL-Template an die Datenbank, in dem Platzhalter statt konkreter Werte stehen.
+    * Beispiel (pseudo): SELECT * FROM users WHERE id = ?
+  - Die Datenbank parst und compiliert dieses Template, legt einen Ausfuehrungsplan an.
+  - Zur Laufzeit werden die Platzhalter separat mit Werten gefuellt — diese Werte werden nie als Teil des SQL-Codes interpretiert, sondern rein als Daten behandelt.
+Ergebnis: Eingaben wie 1; DROP TABLE users; koennen nicht als zusätzlicher SQL-Code ausgefuehrt werden — sie landen als sicherer Datenwert in der Abfrage.
+**Warum das gegen SQLi hilft**
+  * **Trennung von Code und Daten:** Eingaben koennen die SQL-Syntax nicht mehr verändern.
+  * **Schutz gegen die meisten Angriffsvarianten:** Union-, Error- und Blind-SQLi werden dadurch weitgehend unwirksam, weil die Datenbank die Struktur bereits fixiert hat.
+  * Performance-Bonus: Bei wiederholten Abfragen wird der vorbereitete Plan wiederverwendet — das ist ein netter Nebeneffekt.
+**Beispiel JavaScript**
+Die Werte in [...] sind rein Daten — kein Code.
+  // Platzhalter $1, $2 — Parameter separat uebergeben
+  const sql = 'UPDATE Production.ProductInventory SET Quantity = $1 WHERE ProductID = $2';
+  await client.query(sql, [quantity, productId]);
+===== Stored Procedure =====
+Kurzfassung zuerst: Stored Procedures (SPs) verlagern SQL-Logik in die Datenbank. Richtig verwendet trennen sie Code (die prozedurale Logik in der DB) von Daten (die Parameter), reduzieren Angriffsflächen und erleichtern Zugriffssteuerung. Keine Zauberformel — sie helfen, sind aber kein Freifahrtschein.
+{{:modul:m183:learningunits:lu10:lu10c_2.png?1000|}}
+**Wie stored procedures grundsätzlich schützen**
+  * Die SQL-Struktur liegt in der Datenbank und nicht in applikationsseitig zusammengesetzten Strings.
+  * Parameter werden (wenn sie als Parameter benutzt werden) von der DB engine als Daten behandelt — nicht als Teil des SQL-Codes.
+  * DB-Accounts können nur EXECUTE-Rechte auf die SP erhalten, nicht direkte SELECT/UPDATE/DELETE-Rechte auf Tabellen. Damit wird least privilege einfacher durchsetzbar.
+  * SPs erlauben zentralisierte Validierung/Logging und vereinfachen Auditing.
+**Kurz:** SP  machen es einem Angreifer schwerer, per manipulierten Input die Abfrage-Struktur zu verändern — sofern diese nicht durch unsauberen Code zunichte gemacht wurde.