kritische Stellen in php Code
Auf was muss ich beim Programmieren meiner Website achten ?
Hallo,
ich bin schon seit einiger Zeit dabei meine Website auf php umzustellen. Die Website hat auch eine MySQL DB. Da ich keine Ahnung von möglichen Gefahren bei php habe, würde ich mich freuen, wenn ihr mir einige Stichwörter zu dem Thema geben würdet
mfg
ThermoTubbie
Hallo,
ich bin schon seit einiger Zeit dabei meine Website auf php umzustellen. Die Website hat auch eine MySQL DB. Da ich keine Ahnung von möglichen Gefahren bei php habe, würde ich mich freuen, wenn ihr mir einige Stichwörter zu dem Thema geben würdet
mfg
ThermoTubbie
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 18429
Url: https://administrator.de/forum/kritische-stellen-in-php-code-18429.html
Ausgedruckt am: 23.01.2025 um 22:01 Uhr
8 Kommentare
Neuester Kommentar
@ThermoTubbie
Hi,
die Gefahr bei PHP oder ähnl. Scriptsprachen liegt darin, dass diese
schreibend auf's Dateisystem des Webservers zugreifen können.
Deshalb bieten die meisten Webhoster diese Möglichkeit, z.B. PHP zu
nutzen, gar nicht erst an, oder wenn, muß diese Leistung extra bezahlt werden.
Gruß
Günni
Hi,
die Gefahr bei PHP oder ähnl. Scriptsprachen liegt darin, dass diese
schreibend auf's Dateisystem des Webservers zugreifen können.
Deshalb bieten die meisten Webhoster diese Möglichkeit, z.B. PHP zu
nutzen, gar nicht erst an, oder wenn, muß diese Leistung extra bezahlt werden.
Gruß
Günni
Also was du wahrscheinlich meinst ist SQL-Injektion.
Also wenn z.B. ein Parameter mit GET uebergeben wird, der dann in einer Datenbankabfrage weiterverwendet wird.
Wenn also beispielsweise die Adresszeile so aussieht:
und die SQL-Abfrage so aussieht:
Koennte ein User an die Adresszeile einfach '; drop database;' anhaengen. Das gehoert ja dann schliesslich immer noch zu der GET-Variable 'id'.
Die SQL-Abfrage sieht dann so aus:
Mit GET uebergebene Parameter sollten also IMMER ueberprueft werden. Das selbe gilt auch fuer jede andere Schnittstelle, wo der User eingaben machen kann. Also Login-Felder etc.
Uebergebene Variablen sollten also erstens immer mit $_POST["bla"] oder $_GET["bla"] abgenommen werden und mit der Funktion addslashes() ueberprueft werden.
Also in dem Beispiel muesste das so aussehen:
Wenn durch die Variable nur Zahlen uebergeben werden sollen, sollte man als zusaetzliche Sicherheit auch noch pruefen, ob der Inhalt auch nur aus Zahlen besteht:
Einen sehr guten Artikel dazu findet man bei Wikipedia: http://de.wikipedia.org/wiki/SQL-Injection
Gruss Markus
Also wenn z.B. ein Parameter mit GET uebergeben wird, der dann in einer Datenbankabfrage weiterverwendet wird.
Wenn also beispielsweise die Adresszeile so aussieht:
http://www.host.tld/index.php?id=3
und die SQL-Abfrage so aussieht:
$sql = "SELECT * FROM `table` WHERE `id` = '$id'";
Koennte ein User an die Adresszeile einfach '; drop database;' anhaengen. Das gehoert ja dann schliesslich immer noch zu der GET-Variable 'id'.
Die SQL-Abfrage sieht dann so aus:
SELECT * FROM `table` WHERE `id` = 3; drop database;
Mit GET uebergebene Parameter sollten also IMMER ueberprueft werden. Das selbe gilt auch fuer jede andere Schnittstelle, wo der User eingaben machen kann. Also Login-Felder etc.
Uebergebene Variablen sollten also erstens immer mit $_POST["bla"] oder $_GET["bla"] abgenommen werden und mit der Funktion addslashes() ueberprueft werden.
Also in dem Beispiel muesste das so aussehen:
$id = addslashes($_GET["id"]);
Wenn durch die Variable nur Zahlen uebergeben werden sollen, sollte man als zusaetzliche Sicherheit auch noch pruefen, ob der Inhalt auch nur aus Zahlen besteht:
if (!is_numeric($id)) die("Hacking Attemt");
Einen sehr guten Artikel dazu findet man bei Wikipedia: http://de.wikipedia.org/wiki/SQL-Injection
Gruss Markus
da sehe ich keine Sicherheitsluecken. Sicherheitsluecken bestehen sowieso nur dann, wenn vom User veraenderbare Daten in dem php-Script ausgegeben werden. Also z.B. durch echo oder eben eine SQL-Abfrage.
Meiner Meinung nach besteht das groesste Sicherheitsrisiko bei SQL-Abfragen. Wenn die Rechte aber aussreichend eng gesetzt sind, kann der Hacker auch nur so viel machen, wie die Scripts.
In deinem Script wird nirgends das GET-Array ausgegeben, es besteht also kein Risiko. Man kann an dem uebergebenen Parameter veraendern, was man will - alles, was dadurch passieren kann ist, dass die switch-Abfrage ein anderes Ergebnis bringt und damit in einen anderen case-Zweig springt. Mehr als im case-Zweit steht kann aber auch nicht ausgefuehrt werden.
Gruss Markus
Meiner Meinung nach besteht das groesste Sicherheitsrisiko bei SQL-Abfragen. Wenn die Rechte aber aussreichend eng gesetzt sind, kann der Hacker auch nur so viel machen, wie die Scripts.
In deinem Script wird nirgends das GET-Array ausgegeben, es besteht also kein Risiko. Man kann an dem uebergebenen Parameter veraendern, was man will - alles, was dadurch passieren kann ist, dass die switch-Abfrage ein anderes Ergebnis bringt und damit in einen anderen case-Zweig springt. Mehr als im case-Zweit steht kann aber auch nicht ausgefuehrt werden.
Gruss Markus
Dann sollte eine SQL-Injection nicht moeglich sein.
Markus
Markus