mysqli - Was muss in Sachen Sicherheit bedacht werden?

Jump to last post
C

Cyperfriend

Der ohne Avatar
Registriert
14 Juli 2013
Beiträge
1.123
Ich fange gerade mit mysqli an und habe in diesem Zusammenhang gelesen, dass mysql_real_escape_string als veraltet markiert ist und auf mysqli verwiesen wird (
You do not have permission to view link please Anmelden or Registrieren
)

Jetzt frage ich mich, welche Sicherheitsvorkehrungen getroffen werden müssen, wenn man Datenbankeinträge tätigen will. Reicht es einfach die Daten mittels mysqli zu übertragen oder gibt es neue Befehle die man voranstellen muss?
 
Am sichersten wäre es wenn du PDO benützen würdest. Dort hast du prepared Statements:

You do not have permission to view link please Anmelden or Registrieren
 
Bin jetzt schon 6 Jahre aus dem Thema raus. Aber damals hatte ich auch schon mysqli mit Prepared Statements verwendet. Stored procedures kannte ich damals noch nicht.

mysql_real_escape_string war damals ein beliebter Workaround zur Unterbindung von SQL-Injections. Gerade im Gulli-Board wurde das Kommando immer mit Vehemenz empfohlen. Allerdings war das Kommando schon damals eine dreckige Lösung. Prepared Statements und Stored Procedures sind die richtige Lösung.

Alternativ kannst du auch auf andere Datenbanken gehen, z.B.
You do not have permission to view link please Anmelden or Registrieren
. Dort speicherst du ganze Objekte in der Datenbank anstatt Tabellen zu basteln.
 
Generell kann ich dir hier zwei Links reinwerfen, wo eigentlich nochmal alles niedergeschrieben steht:

You do not have permission to view link please Anmelden or Registrieren

You do not have permission to view link please Anmelden or Registrieren


Nicht top aktuell, aber das kann es einfach nicht geben. Wichtig ist das "wie" zu verstehen. Dann kannst du auch damit umgehen, die Sachen auszuspielen.
 
Ich bin kein Webentwickler und vor allem kein Datenbankexperte. Aber ich bin ein bisschen im Thema drin, da ich oft am Tisch bei den Diskussionen sitze :)

Was auf jeden Fall wichtig ist: Jede, also wirklich JEDE Benutzereingabe auf Gültigkeit überprüfen. Das betrifft auch sowas wie Bilduploads und andere Daten, bei denen man erstmal nicht an SQL Injections denken würde. Beispiel:
You do not have permission to view link please Anmelden or Registrieren

Da wurde Schadcode im Kommentarfeld eines JPGs mitgeschickt und da die Überprüfung ungenügend ist, wurde der Code ausgeführt.

Daher würde ich an deiner Stelle überall wo Benutzer etwas an den Server oder in die Datenbank schicken doppelt und dreifach überprüfen.
 
Yash schrieb:
Beispiel:
You do not have permission to view link please Anmelden or Registrieren
Zum Vergrößern anklicken....
Murray untersuchte zunächst, ob er eine ausführbare Datei mit der Endung JPG auf den Windows-Webserver hochladen konnte … Er platzierte Schadcode in das Kommentarfeld der Exif-Informationen in einer Jpeg-Datei. Dieser gab er wiederum die Endung aspx, wie sie bei Web Forms bei Microsofts Active Server Pages üblich sind. Der Webserver erkannte zwar das Jpeg als Bild, übersah aber die Dateiendung. Die Vorschaufunktion, die eigentlich das hochgeladene Bild anzeigen sollte, führte dann den Code in dem Kommentarfeld in Form einer Shell aus.
Zum Vergrößern anklicken....

Ich will mich jetzt nicht zu weit aus dem Fenster lehnen. Aber wenn ein Webserver einen Exif-Kommentar eines Bildes ausführt, läuft da irgendwie was gewaltig schief. Gibt's den Exploit auch auf richtigen Webserverplattformen (Linux + Nginx, Apache, NodeJS, JavaEE-Geraffel)?
 
@musv:
Der genannte Exploit ist nicht wirklich IIS/Asp-spezifisch. Mit genug Nachlässigkeit beim Coden kann sowas auch schnell in typischen PHP-Anwendungen oä. entstehen (hatte nicht sogar Joomla mal das gleiche Problem)?
Das Problem entsteht, wenn Webserver und Upload-Script verschiedene Methoden nutzen, um den Dateityp zu bestimmen (Script: Dateiformat-Header, Server: Dateiendung). Dann kannst du eine jpg-Datei in *.php umbenennen und hochladen (der Dateiinhalt bleibt ja gültiges Jpeg). Beim Abrufen der Datei interpretiert der Webserver diese dann als PHP-Script - steht dann bspw. in der Comment-Section ein "<?php... ", wird das eben ausgeführt.
Funktioniert auf Linux/Nginx/Apache/... wunderbar, bei JavaEE eher nicht (dort sind Code und Daten besser getrennt).
 
Hihi - schon cool das hier jeder erst mal schreibt das er sich eigentlich nicht auskennt :D - nicht böse sein, finde jeden Post gut - und stehen ja auch gute sachen da.

Ich würde noch diesen Artikel zum Thema Empfehlen:
You do not have permission to view link please Anmelden or Registrieren
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben