+ Antworten
Seite 1 von 2 1 2 LetzteLetzte
Ergebnis 1 bis 15 von 29

Thema: Sichere Programmierung (ein PHP - CMS) ... suche Rat

  1. #1
    TP-Supporter screamfine macht alles soweit korrekt
    Registriert seit
    Sep 2002
    Ort
    Karlsruhe
    Beiträge
    404

    Sichere Programmierung (ein PHP - CMS) ... suche Rat

    Hallo zusammen!

    Ich habe bereits ein CMS mit php und mysql realisiert, es ist ein einfaches CMS und soll zukünftig stark erweitert werden. Momentan kann man halt Seiten und Inhalte sowie Benutzerkonten pflegen.

    Momentan habe ich es so programmiert, dass Seiten über id's aufgerufen werden. Also z.B. www.meineseite.de/index.php?id=seite1. Ebenso nutze ich globale Variablen wie z.Bsp. $HTTP_HOST ...

    Jetzt habe ich aber gelesen, dass diese Programmierung nicht sehr sicher ist.

    Ich möchte nun also zum einen mein bisheriges Script auf schnellstem und einfachstem Wege immun gegen SQL-Injektionen usw. machen und dass es mit REGISTER_GLOBALS OFF läuft und zum anderen suche ich Tipps wie ich die Programmierung in Zukunft von vorneherein sicherer gestalten kann.

    Ich hoffe ihr könnt mir helfen :-)

  2. #2
    TP-Supporter Driver ist auf einem guten Weg
    Registriert seit
    Feb 2005
    Beiträge
    365
    Es gibt da irgendeine MySQL Funktion, die mir grad nicht einfällt, aber ich benutze dagegen einfach ein eigenes Script:
    PHP-Code:
    function injections_protector() {

         
    $sql_commands = array(=> "DROP",

                               
    => "SELECT",

                               
    => "FROM",

                               
    => "WHERE",

                               
    => "DATABASE",

                               
    => "CREATE",

                               
    => "TABLE",

                               
    => "INSERT",

                               
    => "INTO",

                               
    10 => "UPDATE",

                               
    11 => "SET",

                               
    12 => "TRUNCATE",

                               
    13 => "PROCESSLIST",

                               
    14 => "--");

         foreach(
    $sql_commands as $command) {

              foreach(
    $_GET as $glob) {

                   
    $query preg_match("/".$command."/i",$glob,$results);

                   if(
    $results) {

                        die(
    "Sie versuchen diese Seite zu hacken!");

                   }

              }

              foreach(
    $_POST as $glob) {

                   
    $query preg_match("/".$command."/i",$glob,$results);

                   if(
    $results) {

                        die(
    "Sie versuchen diese Seite zu hacken!");

                   }

              }

              foreach(
    $_REQUEST as $glob) {

                   
    $query preg_match("/".$command."/i",$glob,$results);

                   if(
    $results) {

                        die(
    "Sie versuchen diese Seite zu hacken!");

                   }

              }

         }


    Kann sein, dass noch ein paar Begriffe fehlen, aber die wichtigsten dürften drin sein.

  3. #3
    TP-Insider HoRnominatoR ist auf einem guten Weg Avatar von HoRnominatoR
    Registriert seit
    Dec 2003
    Ort
    nienburg (raum hannover)
    Beiträge
    971
    Zitat Zitat von screamfine
    Ich möchte nun also zum einen mein bisheriges Script auf schnellstem und einfachstem Wege immun gegen SQL-Injektionen usw. machen und dass es mit REGISTER_GLOBALS OFF läuft und zum anderen suche ich Tipps wie ich die Programmierung in Zukunft von vorneherein sicherer gestalten kann.
    da gibt es zB quote_smart(). wenn register_globals=off ist, sind superglobale variablen in den arrays $_GET (URL), $_POST (zB formulardaten), $_COOKIE und $_SESSION zu finden (ein paar mehr gibts da noch). aber das machts nicht automatisch sicher, hilft nur, dass nicht einfach alle variablen ueberschrieben werden koennen.

    sicher machen kannst du dein programm nur, wenn du niemandem vertraust und alles ueberpruefst.
    in eile kam er,
    in schwarzem gewand,
    aus den tiefen des waldes,
    ein einsamer mann, ein geschoepf der freiheit,
    ein geschoepf ohne furcht,
    doch alle nannten sie ihn nur T O D

  4. #4
    TP-Supporter screamfine macht alles soweit korrekt
    Registriert seit
    Sep 2002
    Ort
    Karlsruhe
    Beiträge
    404
    Sind globale variablen wie $HTTP_HOST eigentlich generell unsicher .... welche Möglichkeiten habe ich ansonsten von diesen Variablen Gebrauch zu machen, sie sind ja shcon manchmal sehr hilfreich ?!

  5. #5
    TP-Special Mod steffenk lebt für das TP und seine User steffenk lebt für das TP und seine User steffenk lebt für das TP und seine User steffenk lebt für das TP und seine User steffenk lebt für das TP und seine User steffenk lebt für das TP und seine User steffenk lebt für das TP und seine User steffenk lebt für das TP und seine User steffenk lebt für das TP und seine User Avatar von steffenk
    Registriert seit
    Feb 2005
    Ort
    Haan / NRW
    Beiträge
    12.869
    Die Variablen sind nicht angreifbar, das grösste Problem ist die Urlmanipulation.

    Das kann man verhindern, indem man z.B. vermeidet

    - include($_GET['page']); (erlaubt inkludieren von fremden Dateien))

    oder

    - mysql_query("SELECT * from `tabelle` where `id`=".$_GET['id'])

    letzteres erlaubt Eindringen in MySQL
    Bei einer Url index.php?id=3
    könnte ein Eindringling schreiben
    index.php?id=3;DELETE * FROM `user`

    und schon wäre eine Tabelle futsch.

    Also am sichersten ist, man überprüft alle $_GET und $_POST-Variabeln, bevor man sie weiterverarbeitet. Bei MySQL muss man auf jedenfall maskieren, entweder so wie Horminator beschrieben hat oder mit addslashes oder ähnlichem


    TYPO3 · MySQLDumper · dislabs
    ·
    manche Mühlen mahlen schneller ...
    "Ich habe Rücken"
    Horst Schlämmer


  6. #6
    DSB
    DSB ist offline
    TP-Veteran DSB ist ein richtiges Arbeitstier - DANKE DSB ist ein richtiges Arbeitstier - DANKE DSB ist ein richtiges Arbeitstier - DANKE DSB ist ein richtiges Arbeitstier - DANKE Avatar von DSB
    Registriert seit
    Mar 2005
    Ort
    Weyhe
    Beiträge
    1.137
    Zitat Zitat von St@eff.en
    Also am sichersten ist, man überprüft alle $_GET und $_POST-Variabeln, bevor man sie weiterverarbeitet. Bei MySQL muss man auf jedenfall maskieren, entweder so wie Horminator beschrieben hat oder mit addslashes oder ähnlichem
    Auf alle Fälle!
    Ich jage immer alle Strings durch mysql_escape_string().
    Dadurch werden Hochkommas maskiert und ein Angreifer kann nicht durch absichtliche Manipulation der ungeprüft übergebenen Variable ein Ende des SQL-Befehls erreichen und einen eigenen Befehl anhängen.
    Gruß, DSB
    Einfaches Backup/ Restore Deiner MySQl-Datenbank
    Zend Certified Engineer PHP5

  7. #7
    TP-Veteran Scriff macht alles soweit korrekt Avatar von Scriff
    Registriert seit
    Nov 2002
    Ort
    bei Stuttgart (Esslingen)
    Beiträge
    1.356
    Zitat Zitat von St@eff.en
    Die Variablen sind nicht angreifbar, das grösste Problem ist die Urlmanipulation.

    Das kann man verhindern, indem man z.B. vermeidet

    - include($_GET['page']); (erlaubt inkludieren von fremden Dateien))

    oder

    - mysql_query("SELECT * from `tabelle` where `id`=".$_GET['id'])

    letzteres erlaubt Eindringen in MySQL
    Bei einer Url index.php?id=3
    könnte ein Eindringling schreiben
    index.php?id=3;DELETE * FROM `user`

    und schon wäre eine Tabelle futsch.

    Also am sichersten ist, man überprüft alle $_GET und $_POST-Variabeln, bevor man sie weiterverarbeitet. Bei MySQL muss man auf jedenfall maskieren, entweder so wie Horminator beschrieben hat oder mit addslashes oder ähnlichem

    nur woher soll der haker meine DB_Struktur kennen und die richtige tabelle ansprechen ???

  8. #8
    TP-Veteran walter hilft, wo's geht walter hilft, wo's geht walter hilft, wo's geht Avatar von walter
    Registriert seit
    Jan 2004
    Ort
    Bayern, Dürnhart
    Beiträge
    1.446
    Wenn du vorher alles richtig gemacht hast, dann wirds wirklich schwer den Namen der Tabelle zu finden.
    Wenn Du aber z.B. Fehlermeldungen nicht unterdrückst, dann kann da ganz schön was ausspioniert werden über deine Struktur.

  9. #9
    TP-Supporter screamfine macht alles soweit korrekt
    Registriert seit
    Sep 2002
    Ort
    Karlsruhe
    Beiträge
    404
    Zitat Zitat von St@eff.en
    letzteres erlaubt Eindringen in MySQL
    Bei einer Url index.php?id=3
    könnte ein Eindringling schreiben
    index.php?id=3;DELETE * FROM `user`

    und schon wäre eine Tabelle futsch.
    Verstehe ich nicht .... der Mysql Befehl den du da nach dem Semikolon geschrieben hast, wird doch gar nicht ausgeführt ....

  10. #10
    DSB
    DSB ist offline
    TP-Veteran DSB ist ein richtiges Arbeitstier - DANKE DSB ist ein richtiges Arbeitstier - DANKE DSB ist ein richtiges Arbeitstier - DANKE DSB ist ein richtiges Arbeitstier - DANKE Avatar von DSB
    Registriert seit
    Mar 2005
    Ort
    Weyhe
    Beiträge
    1.137
    Zitat Zitat von Scriff
    nur woher soll der haker meine DB_Struktur kennen und die richtige tabelle ansprechen ???
    SELECT * from `tabelle` where `id`=".$_GET['id'])
    und Aufruf [QUOTE]index.php?id=3;SHOW TABLES;[QUOTE]
    wird vom Script zusammengebaut zu:

    SELECT * from `tabelle` where `id`=3;SHOW TABLES
    Das sind 2 MySQL-Befehle, die beide nacheinander ausgeführt werden.
    Und schon kennt man Deine komplette Struktur und kann sich zu weiteren Angriffen aufmachen.
    Deshalb sollten alle Variablen, die in MySQL-Querys benutzt werden gesondert geprüft werden.
    Geändert von DSB (24.06.2005 um 11:05 Uhr)
    Gruß, DSB
    Einfaches Backup/ Restore Deiner MySQl-Datenbank
    Zend Certified Engineer PHP5

  11. #11
    TP-Greis Boris lebt für das TP und seine User Boris lebt für das TP und seine User Boris lebt für das TP und seine User Boris lebt für das TP und seine User Boris lebt für das TP und seine User Boris lebt für das TP und seine User Boris lebt für das TP und seine User Avatar von Boris
    Registriert seit
    Mar 2001
    Ort
    Stuttgart & Kornwestheim
    Beiträge
    9.420
    Das sind 2 MySQL-Befehle, die beide nacheinander ausgeführt werden.
    Nein, werden sie nicht - PHP leitet nur eine (die erste) Anweisung an MySQL weiter, andere nicht. Ist ein eingebautes Sicherheitsfeature
    My software never has bugs. It just develops random features ...

    » DevShack - die Website des freien Webentwicklers Boris

  12. #12
    TP-Special Mod steffenk lebt für das TP und seine User steffenk lebt für das TP und seine User steffenk lebt für das TP und seine User steffenk lebt für das TP und seine User steffenk lebt für das TP und seine User steffenk lebt für das TP und seine User steffenk lebt für das TP und seine User steffenk lebt für das TP und seine User steffenk lebt für das TP und seine User Avatar von steffenk
    Registriert seit
    Feb 2005
    Ort
    Haan / NRW
    Beiträge
    12.869
    PHP parst SQL-Anweisungen ? das wäre mir neu. Auch das abbrechen nach ; dürfte problematisch sein, es könnte auch Teil eines Wertes sein ...

    Hast Du dazu einen Beweis ?


    TYPO3 · MySQLDumper · dislabs
    ·
    manche Mühlen mahlen schneller ...
    "Ich habe Rücken"
    Horst Schlämmer


  13. #13
    TP-Supporter screamfine macht alles soweit korrekt
    Registriert seit
    Sep 2002
    Ort
    Karlsruhe
    Beiträge
    404
    Noch eine Frage: wenn ich mit $_REQUEST arbeite ... kommt das nicht letztlich auf dasselbe raus als wenn ich direkt die Variablen anspreche ... denn der böse Hacker kann doch dann Variablen über die URL mitgeben, und da ich $_REQUEST einsetze und nicht explizit z.Bsp. $_POST ... dann kann es doch passieren, dass der Wert von z.Bsp. 'id' überschrieben wird .... oder nicht?!

  14. #14
    TP-Special Mod steffenk lebt für das TP und seine User steffenk lebt für das TP und seine User steffenk lebt für das TP und seine User steffenk lebt für das TP und seine User steffenk lebt für das TP und seine User steffenk lebt für das TP und seine User steffenk lebt für das TP und seine User steffenk lebt für das TP und seine User steffenk lebt für das TP und seine User Avatar von steffenk
    Registriert seit
    Feb 2005
    Ort
    Haan / NRW
    Beiträge
    12.869
    $_REQUEST ist nichts anderes als die Zusammenfassung von $_GET und $_POST


    TYPO3 · MySQLDumper · dislabs
    ·
    manche Mühlen mahlen schneller ...
    "Ich habe Rücken"
    Horst Schlämmer


  15. #15
    TP-Greis Boris lebt für das TP und seine User Boris lebt für das TP und seine User Boris lebt für das TP und seine User Boris lebt für das TP und seine User Boris lebt für das TP und seine User Boris lebt für das TP und seine User Boris lebt für das TP und seine User Avatar von Boris
    Registriert seit
    Mar 2001
    Ort
    Stuttgart & Kornwestheim
    Beiträge
    9.420
    Zitat Zitat von St@eff.en
    PHP parst SQL-Anweisungen ? das wäre mir neu. Auch das abbrechen nach ; dürfte problematisch sein, es könnte auch Teil eines Wertes sein ...

    Hast Du dazu einen Beweis ?
    Versuch es doch einfach mal:

    $test="UPDATE FROM hier SET das='test'; UPDATE FROM hier SET das='anders'";
    mysql_query($test);

    Es wird nur das erste Update an MySQL geschickt, das zweite nicht. Das ist aber nicht neu (?) ...

    Steht auch hier:
    Um etwas schonmal vorweg zu nehmen, mehrere MySQL-Querys werden durch Semikolons getrennt. Aus Sicherheitsgründen führt PHP aber nur den 1. MySQL-Query aus. Wenn man mehrere MySQL-Querys ausführen möchte, muss man entsprechend so viele mysql_query-Befehle aufrufen, oder die Querys in einem Array speichern und eine foreach-Schleife benutzen.
    http://tut.php-q.net/mysql-query.html
    Geändert von Boris (24.06.2005 um 11:57 Uhr)
    My software never has bugs. It just develops random features ...

    » DevShack - die Website des freien Webentwicklers Boris

+ Antworten
Seite 1 von 2 1 2 LetzteLetzte

Aktive Benutzer

Aktive Benutzer

Aktive Benutzer in diesem Thema: 1 (Registrierte Benutzer: 0, Gäste: 1)

     

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51