Sicherheitsvorkehrungen für PHP und MySQL

NetzUnity und Informatik-forum wurden zusammengelegt. Eine entsprechende Ankündigung wird demnächst noch folgen. Für 2025 ist hier einiges geplant! Bei Fragen bitte per DM an Maximilian Rupp wenden.
  • Also ich möchte eine web applikation mit php geschtützt auf mysql entwickeln. Ist aber eher noch neuland für mich: Ich wollte also mal eure Meinung über Sicherheitsvorkehrungen einholen: Es geht allgemein um zB login daten speichern, login daten mit sessions speichern und um daten die mit forms an sql datenbanken übergeben werden (query,insert,update).

    Dies ist was ich so aufgeschnappt habe in einschlägiger Literatur:

    • Login Daten für zb die sql datenbank sollte man in einer eigenen datei speichern auserhalb des public webspaces und als include dann in die jeweiligen datein integrieren und als variablen übernhemen
    • Für Fremdaten aus Formularen:

      1. Mit der funktion "strip_tag" spitze klammern und alles was dazwischen ist entfernen zb. $last_name = strip_tag($last_name)

      2.Mit der funktion "ereg" auf syntax überprüfen

      3. Um SQL Injection angriffe zu vermeiden: mit "addslashes" escape zeichen vor jede eingabe hinzuzufügen damit sql die zeichen nur als literale sieht und nie als befehlscode. Nur nötig wenn Magic Quotes in php.ini deaktiviert ist.

    Nun kennt ihr noch andere "tricks und kniffe" wie man seine applikation sicherer machen kann. (mein hoster bietet PHP ver. 5.1.4 und ich schätze MySQL v4 od v4.1)

  • [*]Für Fremdaten aus Formularen:

    Wichtigstes Prinzip: Alles, was der Benutzer eingibt, ist als böse zu betrachten. Wenn du das konsequent beachtest, bist du schon mal auf dem richtigen Weg.

    1. Mit der funktion "strip_tag" spitze klammern und alles was dazwischen ist entfernen zb. $last_name = strip_tag($last_name)

    Lass doch dem Benutzer den Spaß - wenn er unbedingt "<script type="text/javascript" src="irgendwas.js"></script>" heißen will... verwende daher html_entities, und zwar so, dass auch " durch &quot; ersetzt wird (siehe PHP-Dokumentation).

    3. Um SQL Injection angriffe zu vermeiden: mit "addslashes" escape zeichen vor jede eingabe hinzuzufügen damit sql die zeichen nur als literale sieht und nie als befehlscode.

    mysql_real_escape() verwenden, siehe - Überraschung! - PHP-Dokumentation. Dann können deine Benutzer auch so heißen als wären sie Teile von SQL-Statements.

    Allgemeine Ratschläge fallen mir sonst im Moment keine ein (ich bin auch zu faul um nachzudenken). :shinner:

  • Noch ne Frage: Wie sicher ist es mittels $_POST daten, informationen zwischen 2 php seiten zu vermitteln. Kann das jemand locker "abhören"? Macht es sinn die sensibleren daten mittels php zu ver- entschlüsseln?

    Und kann man SESSION variablen abhörn?

  • Noch ne Frage: Wie sicher ist es mittels $_POST daten, informationen zwischen 2 php seiten zu vermitteln. Kann das jemand locker "abhören"?

    Lass mal ngrep laufen und schick einen POST-Request an einen Webserver (einfaches HTTP, nicht HTTPS). Du wirst sehen, dass du alles im Klartext lesen kannst.

    Macht es sinn die sensibleren daten mittels php zu ver- entschlüsseln?

    Was willst du mit PHP ver- und entschlüsseln? Am Client? Geht ja wohl ned. Stattdessen Javascript verwenden? Hm, naja...

    Eher sinnvoll in diesem Zusammenhang: HTTPS statt HTTP verwenden.

    Und kann man SESSION variablen abhörn?

    So viel ich weiß nicht, jedoch die PHP-Session-ID, die als Teil der URL bzw. als Cookie übertragen wird. Dadurch wird Session-Hijacking möglich; dann ist es für Unberechtigte vielleicht nicht möglich, direkt die SESSION-Variablen auszulesen, aber es ist möglich, mit deiner Session weiterzuarbeiten und an deiner Stelle Unfug anzustellen.

  • Ok post ist völlig unsicher. Mit verschlüsseln meine ich so die "manuele" Variante von SSL -> Den Datenstring zB den Namen eben so untkenntlich zu machen mit einem algorithmus (im php script, server seitig natürlich), dass man ihn nur lesen kann mit dem richtigen schlüssel. Ist nicht völlig sicher, schon klar, aber gegen einen script kiddies angriff oder sowas gefeit.

    SSL is mir nämlich zu teuer.

  • So viel ich weiß nicht, jedoch die PHP-Session-ID, die als Teil der URL bzw. als Cookie übertragen wird. Dadurch wird Session-Hijacking möglich; dann ist es für Unberechtigte vielleicht nicht möglich, direkt die SESSION-Variablen auszulesen, aber es ist möglich, mit deiner Session weiterzuarbeiten und an deiner Stelle Unfug anzustellen.


    Dies kann allerdings erschwert werden, wenn Daten wie zb IP, User-Agent, etc. in die Session gespeichert und auf jeder geschützten Seite mit dem aktuellen Client verglichen werden.

    Weiters sollst du nicht mit ereg arbeiten, sondern mit preg_match (ereg ist zu langsam und veraltet).

  • Das mit der IP vergleichen werde ich wohl machen, das klingt logisch und dürfte einfach zu implementieren sein.

    Die Frage ist nun aber:

    Ich möchte eine Seite betreiben die auhc mit Kundendaten handelt, zwar keine hochsensiblen daten, wie creditcard, oder bankeinzug, oder offizielle pins, aber mit halt daten wie name, adresse, email, geldbeträge für rechnungen, etc.

    Bis jetzt werden daten nur mit POST von seite zu seite gehangelt - nun macht es definitiv sinn nun sich ssl anzuschaffen oder eben, die billigere, aber aufwendigere variante, eine mehrfachverschlüsselung in die POST daten zu implementieren?

    Das heißt, kann man, wenn man die spez. seite kennt, ohne probleme post daten abhören? Oder braucht man da schon einige kenntnisse?

    Was meint ihr?

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!