Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen der Seite angezeigt.

--- faecher:informatik:oberstufe:datenbanken:projekt:dokuwiki_plugin:sicherheit:start [09.06.2021 12:55] – sbel
+++ faecher:informatik:oberstufe:datenbanken:projekt:dokuwiki_plugin:sicherheit:start [10.06.2021 13:27] (aktuell) – [SQL-Injections] sbel
@@ Zeile 22: / Zeile 22: @@
 ==== SQL-Injections ====
-Da wir hier vor allem mit Datenbanken und Datenbankabfragen arbeiten wollen, spielen sogenannte SQL-Injections eine große Rolle in unserem Setting. Dabei erwarten wir Beispielsweise einen Namen als Eingabe eines Formularfelds, nach dem wir in der Datenbank suchen wollen. Ein bösartiger Angreifer kann aber versuchen, im Namens-Eingabefeld SQL Befehle mit zu übergeben, die dann in unserem Programm in die Datenbankabfrage eingebaut werden. dadrurch können Daten abgefragt werden, auf die der Benutzer vielleicht gar keinen Zugriff haben sollte((Womöglich die gesamte Datenbank, mit gespeicherten Paswort-Hashes und Kreditkartennummern - wem das bekannt vorkommt...)) oder Daten gelöscht oder manipuliert werden.
+Da wir hier vor allem mit Datenbanken und Datenbankabfragen arbeiten wollen, spielen sogenannte SQL-Injections eine große Rolle in unserem Setting. Dabei erwarten wir beispielsweise einen //Namen// als Eingabe eines Formularfelds, nach dem wir in der Datenbank suchen wollen. Ein bösartiger Angreifer kann aber versuchen, im Namens-Eingabefeld SQL Befehle mit zu übergeben, die dann in unserem Programm in die Datenbankabfrage eingebaut werden. dadurch können Daten abgefragt werden, auf die der Benutzer vielleicht gar keinen Zugriff haben sollte((Womöglich die gesamte Datenbank, mit gespeicherten Paswort-Hashes und Kreditkartennummern - wem das bekannt vorkommt...)) oder Daten gelöscht oder manipuliert werden.
 Eine <wrap hi>**schlechte Idee**</wrap> ist es also, das naheliegende zu tun:
@@ Zeile 42: / Zeile 42: @@
 </code>
-Dies funktioniert zwar, ist aber anfällig für sogenannte SQL Injections. Ein Angreifer kann über den POST-Parameter die SQL-Abfrage manipulieren und weiteren SQL-Code einschleusen. Im schlimmsten Fall werden dadurch sensible Daten ausgegeben, Tabelle verändert oder gar ganze Tabellen gelöscht.
+Dies funktioniert zwar, ist aber anfällig für SQL Injections. Ein Angreifer kann über den POST-Parameter die SQL-Abfrage manipulieren und weiteren SQL-Code einschleusen.
 Gibt der Anwender nämlich ins Formularfeld beispielsweise folgendes ein:
 ''1 OR id > 1''
-Werden alle Datensätze ausgegeben, denn an die Datenbank wird die Abfrage ''SELECT * FROM schueler WHERE id =  OR id > 1'' geschickt.
+Werden alle Datensätze ausgegeben, denn an die Datenbank wird die Abfrage ''SELECT * FROM schueler WHERE id = 1 OR id > 1'' geschickt.
 {{ :faecher:informatik:oberstufe:datenbanken:projekt:dbphp:phppdo:exploits_of_a_mom.png |}}
@@ Zeile 73: / Zeile 74: @@
 </code>
+===== Blacklisting/Whitelisting =====
+Ebenfalls effektiv ist es, Parameterwerte mit Blacklisting oder Whitelisting zu überprüfen und die Verarbeitung abzubrechen, wenn der Eingabewert nicht den geforderten Kriterien entspricht. Dabei sind reguläre Ausdrücke ein wertvolles Werkzeug.
+  * Beim Blacklisting kann man beispielsweise festlegen, dass die Verarbeitung abgebrochen wird, wenn bestimmte Zeichen in der Eingabe enthalten sind. Beispiel: "Wenn eimn ''='', ein '';'' ''<'' oder ''>'' im Namensfeld übergeben werden, wird die Verarbeitung abgebrochen."
+  * Beim Whilelistinh legt man ein Muster fest, dem die Eingabe entsprechen muss um zur Weiterverarbeitung zugelassen zu werden. Beispiel. "Im Feld ''Postleitzahl'' muss eine Eingabe übergeben, die aus fünf Ziffern besteht."
+Dieses Vorgehen nennt man "Input Sanitization" und wie man das auf mannigfaltige Art vollständig verkacken kann, [[https://www.youtube.com/playlist?list=PLKuX6iczGb3kuDsm2RFgbmRkTugkR9-UE|kann man sehr gut an der Luca-App betrachten]].
+===== Andere Angriffsvektoren =====
+Die Mitigation andrer Angriffsvektoren - wie z.B. Authentifikation und Rechtemanagement können wir an DokuWiki abgegeben, beispielsweise indem wir unser Plugin nur auf Seiten einbauen, auf die Angemeldete (DokuWiki-)Benutzer mit den entsprechenden Rechten zugreifen dürfen. Nun ist aber zu beachten, dass unsere Applikation durch Sicherheitslücken im DokuWiki-System beeinträchtigt werden kann: Hat DokuWiki eine Sicherheitslücke in seinem Authentifikations- und Rechtemanagement, ist unsere WebApp davon möglicherweise auch betroffen.
+Auch bei der Implementation muss man hier große Sorgfalt walten lassen, um unerwünschte Nebeneffekte zu vermeiden, wenn man beispielsweise aus Rechten, die ein Benutzer in DokuWiki hat Rechte innerhalb der WebApp ableiten möchte.