Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

--- modul:m183:learningunits:lu10:03 [2025/09/19 09:58] – 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**
-  // mit mysql2 (Promise-API)
+  // 1. Schritt: Zusammenbau des SQL-Statements mit Platzhaltern
-  const sql1 = `UPDATE Production.ProductInventory
+  const sql1 = `
-                SET Quantity = ?
+    UPDATE Production.ProductInventory
-                WHERE ProductID = ?`;
+    SET Quantity = @qty
-  const [result] = await connection.execute(sql1, [quantity, productId]);
+    WHERE ProductID = @productId
-  // connection.execute schützt vor SQLi, Platzhalter = ?
+  `;
+  // 2. Schritt: Parametrisieren der Übergabewerte
+  const qty = 10;
+  const productId = 709;
+  // 3. Schritt: Zusammenbauen und Ausführen mit Laufzeitwerten
+  const sql = require('mssql');
+  async function updateInventory() {
+    try {
+      // Verbindung herstellen (Beispielconfig anpassen!)
+      const pool = await sql.connect({
+        user: 'username',
+        password: 'password',
+        server: 'localhost',
+        database: 'AdventureWorks'
+      });
+      //
+      const request = pool.request();
+      request.input('qty', sql.Int, qty);
+      request.input('productId', sql.Int, productId);
+      //
+      const result = await request.query(sql1);
+      console.log('Update erfolgreich:', result.rowsAffected);
+    } catch (err) {
+      console.error('Fehler beim Update:', err);
+    }
+  }
+  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.