Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

--- modul:m183:learningunits:lu10:03 [2025/09/19 10:11] – vdemir
+++ modul:m183:learningunits:lu10:03 [2025/09/19 10:37] (aktuell) – vdemir
@@ Zeile 50: / Zeile 50: @@
   }
   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 =====
@@ Zeile 77: / Zeile 81: @@
   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.