1. Diese Seite verwendet Cookies. Wenn du dich weiterhin auf dieser Seite aufhältst, akzeptierst du unseren Einsatz von Cookies. Weitere Informationen

Sicherheit in PHP

Dieses Thema im Forum "PHP" wurde erstellt von Dennis Wronka, 5. April 2006.

  1. versuch13

    versuch13 Erfahrenes Mitglied

    Zwar nicht speziell auf PHP bezogen, dennoch vllt für den ein oder anderen interessant, heute bei http://entwickler-press.de/ ein kosenloses EBook mit dem Thema "Sicherere Webanwendungen" downloadbar.
     
  2. S-lord

    S-lord Mitglied

    http://koandagfx.de/index.php?action=<b><u><h1>GAR NICHT GUT</h1>

    Das ist meine Seite...
    Und den Link hat ein User gepostet...
    Wie hat er das gemacht?
    Auzug aus der Datei...
    PHP:
    1. if(mysql_num_rows($query))
    2. {
    3.     while($row = mysql_fetch_assoc($query)) {
    4.         echo "<div class='div_title' align='center'>" . $row['header'] . "</div>";
    5.         echo "<div class='div_content' align='center'>" . $row['content'] . "<br /><br />geschrieben am: " . $row['date'] . "</div>";
    6.         }
    7. } else {
    8.     die ("Keine Daten in der Tabelle.");
    9. }
     
  3. Flex

    Flex (aka Felix Jacobi)

    Die Sicherheitslücke liegt in dem Bereich, wo die $_GET Variable "action" verarbeitet wird. Diesen Auszug bräuchten wir.
     
  4. S-lord

    S-lord Mitglied

    PHP:
    1. switch($_GET['action']){
    PHP:
    1. default: require("inc/news.php"); break;
    2. }
    Mh stimmt sieht recht unsicher aus.:D
    Aber was kann ich da machen?
    Wenn ich mich recht entsinne gibts eine Funktion, komme aber nicht drauf.
     
  5. maeTimmae

    maeTimmae Erfahrenes Mitglied

    Das ist nicht wirklich der gesuchte Teil, denn ein nicht vorhandener Fall wird durch das default abgefangen.

    Vielmehr müsste in irgendeiner Datei sowas stehen, wie:
    echo $_GET['action'];, was dazu führt, dass die Requestvariable einfach ausgegeben wird. Besser ist da schon echo htmlentities($_GET['action']); (htmlentities, htmlspecialchars), aber auch recht unsauber, da der Nutzer immer noch Daten einbringen kann, die so nicht eingebunden werden sollten.

    Kann es sein, dass die Überschrift der Sektion auch durch das entsprechende GET-Feld produziert wird? Ganz unsauber!
    Alles so statisch wie möglich und so dynamisch wie nötig machen, dann sollten solche Unfeinheiten nicht mehr auftreten. Ein Beispiel könnte sein:

    Modul einbinden
    Code (PHP):
    1. <?php
    2. switch ( $_GET['action'] ) {
    3.     case "news":
    4.         $title = "Neuigkeiten";
    5.         include "News.php";
    6.         break;
    7.     case "somewhat":
    8.         $title = "Was anderes";
    9.     // ...
    10.     default:
    11.         $title = "N/A";
    12.         include "Default.php";
    13.         break;
    14. }
    Ausgabe - Rahmentemplate
    Code (PHP):
    1. <?php
    2. echo $title;
    3. // ...
     
  6. Gumbo

    Gumbo Erfahrenes Mitglied

    Für Fragen ist das PHP-Forum gedacht und nicht dieses Schwerpunktthema, in dem – wie aus dem Eingangsbeitrag hervorgeht – keine Fragen zu bestimmten Quellcodes oder Algorithmen gewünscht sind. Diese sind hier zwar auch erlaubt, sollen aber nur zusammen mit einer Lösung des Problems in der Form „Problem ? Ursache ? Lösung“ genannt werden. Für Fragen zu spezifischen Problemen soll bitte ein eigenes Thema eröffnet werden.
     
    Zuletzt von einem Moderator bearbeitet: 25. September 2011
  7. Flex

    Flex (aka Felix Jacobi)

    Zuletzt von einem Moderator bearbeitet: 25. September 2011
  8. Gumbo

    Gumbo Erfahrenes Mitglied

    Sean Coates hat nicht nur diese Sicherheitslücke eher als Gareth Hayes „entdeckt“, sondern beschreibt zusätzlich sowohl die Ursache als auch eine Lösung.

    Die Ursache ist nämlich Apaches „AcceptPathInfo“-Feature, mit dem auch nur Teile des Pfads für eine erfolgreiche Abbildung auf das Dateisystem dienen können. So reicht in dem genannten Beispiel bereits das „…/php_self.php“ aus, das auf die gleichnamige Datei abgebildet wird. Der Rest wird in der Umgebungsvariable PATH_INFO gespeichert.
    Das Problem hierbei ist wieder einmal der naive Umgang mit den von außen kommenden Benutzereingaben, zu denen auch die URL zählt. Und da PHP_SELF nicht nur den tatsächlichen Pfad zur Skriptdatei sondern auch den PATH_INFO-Teil enthält, der wiederum beliebig sein kann (und so auch Schadcode enthalten kann), ist dieser Variablenwert ebenfalls mit Vorsicht zu behandeln.
     
    versuch13 gefällt das.
  9. Tangarama

    Tangarama Mitglied

    Ersteinmal, recht herzlichen Dank für diesen interessanten Threat.

    Was mich bezüglich des PHP_SELF sehr interessieren würde, wie sieht es denn hier bei Smartys SCRIPT_NAME aus? Wurde das von Seiten der Smarty-Entwickler ausreichend entschärft, oder muss man bei den Templates in denen man SCRIPT_NAME verwendet nacharbeiten?

    kind regards
    JCB
     
  10. Chaosengel_Gabriel

    Chaosengel_Gabriel Erfahrenes Mitglied

    Supi Thread das hier is :D
    Hab mir bislang auch nicht wirklich Gedanken, um die Sicherheit meiner Skripte gemacht...
    Andererseits ist mir aufgefallen, dass ich einige Tipps/Ratschläge diese Threads bereits instinktiv befolgt habe :D

    Was mich persönlich dazu interessieren würde, wäre, wie bereits genannt, wie man solche Ausnutzungen von Sicherheitslücken selber nutzen kann...
    Wie kann ich selber dafür sorgen, dass ich meine Skripte "missbrauche"?

    Die nun folgende Frage ist verständlicherweise richtig dumm und unangebracht, aber ich möchte sie trotzdem stellen:
    Könnte mir jemand einen "Beispiel"-Skript nennen, der sämtliche "Löcher" auf meiner Web-Site findet, nutzt und/oder ausbügelt?

    Geht mir dabei nich darum, was fertiges zu haben, dass ich benutze, sondern nur darum, dass ich sehe wie man sowas macht... Ne entsprechende Klasse o.ä. zum verwenden auf meiner Site schreibe ich mir dann selber...

    [EDIT]:
    Was mir grad noch einfällt... Hab ne Idee, die meiner Überlegung nach zumindest theoretisch die Unsicherheit von $_GET-Übergaben in der URL beheben könnte...
    Unzwar halt statt $_GET einfach $_POST verwenden...
    Aber wie benutze ich in einem Link $_POST!?
    Meine Idee dazu:
    Anstelle des Links ein unsichtbares Formular, welches die nötigen Daten POSTet...
    Und den submit-Button entsprechend formatiert, sodass er aussieht wie ein einfacher Link...

    Was haltet ihr von dem Gedanken?
     
    Zuletzt bearbeitet: 14. März 2008
  11. Dennis Wronka

    Dennis Wronka Soulcollector

    Ich finde die Nutzung von GET nicht grundsaetzlich unsicherer als POST. Klar, GET-Daten zu manipulieren ist einfacher, da es einfach ueber die Addresszeile geht, aber vernuenftig validieren muss man die Daten eh, egal wie sie nun zum Server gelangen.

    Zum Thema Testing der eigenen Seite: Ich hab mal angefangen, auf Basis meiner HTTP-Klasse, eine Klasse zum Penetration Testing zu schreiben.
    Hab aber schon lange nicht mehr daran gearbeitet, und die bisher existierende Version kann auch noch nichts.
    Zudem gibt es wohl auch bessere Tools fuer sowas.
     
  12. Gumbo

    Gumbo Erfahrenes Mitglied

    Was die Transparenz der Daten angeht, ist GET eindeutig unsicherer als POST. Denn der Webserver protokolliert gewöhnlich sämtliche Anfragen samt Anfragezeile, in der auch die angefragte URL enthalten ist.

    Von automatisierten Tests halte ich allerdings nicht viel. Denn ich halte es für schwierig, einem Algorithmus einerseits das Finden von Schwachstellen und andererseits das Ausnutzen dieser Schwachstellen zu überlassen. Bis auf die üblichen Angriffe wie Schadcode-Injektionen ist da nicht viel zu machen.
     
  13. Herror

    Herror Mitglied

    PHP und sicherheit

    Hallo,

    ich programmiere seit kurzer Zeit für ein paar Leute das cms und dazu habe ich halt ein Loginsystem gebastelt.

    nun stellt sich mir die Frage der sicherheit.
    Eine Frage: Die verschlüsselung. Bringt die was?

    Ich meine, wenn man das verschlüsselte passwort hat, dann muss man doch nur einmal schnell md5 in google eingeben und entschlüsselt es schnell... ich meine, das bringt's doch nicht.

    Wie warscheinlich ist es, dass jemand die Daten für den Server über z.B. Suchprogramme finden kann?

    habe z.B. eine Datenbank, in der der komplette Inhalt der Seite ist.
    Dann habe ich eine Suchfunktion, die auf die Datenbank zugreift und die ergebnisse auflistet.

    Gibt es irgendwie unsichere Loginverfahren? oder ist php von haus aus sicher?
     
    Zuletzt bearbeitet: 23. April 2008
  14. Flex

    Flex (aka Felix Jacobi)

    Ist PHP sicher? Nein, es gibt auch hier immer wieder Lücken.
    Ist dein Skript sicher? Keine Ahnung, man kann es nicht sehen.

    PHP ist ein beliebtes Angriffsziel weil es einfach zu erlernen ist, dabei man aber wichtige Dinge oft außer Augen lässt. Wie z. B. folgendes Motto:
    "Filter Input, Escape Output"

    Sprich: Alles was reinkommt ist böse und sollte validiert und gefiltert werden.
    Alles was rausgeht, sollte sicherheitshalber nochmal maskiert werden.

    Und md5 ist keine Verschlüsselung, sondern eine Hash-Funktion.
     
  15. Loomis

    Loomis Mitglied Bunt

    Teste es doch einfach mal.
    Ich wette du schaffst es nicht ;)
     
  16. Herror

    Herror Mitglied

    habe md5 in google eingegeben:

    http://www.google.de/search?q=md5&i...&rls=org.mozilla:de:official&client=firefox-a

    drittes erbegnis: MD5-Decrypter by xpzone.de

    Wenn ich jetzt bei einer Übertragung den mitgesnifften Hash da eingebe, bekomme ich die eingabe, die der Benutzer getätigt hat.

    das hier z.B.: 21232f297a57a5a743894a0e4a801fc3

    in meinem PHP-Buch steht das "hashen" unter Sicherheit... aber was soll das bringen? da kann man das Passwort doch auch unverschlüsselt versenden
     
  17. Loomis

    Loomis Mitglied Bunt

    ... Ok wenn du mein DB Passwort rauskriegst, bekommst du nen Preis... das steht in der DB: 6b60cfd4b896e17cc09097a33d37e48b
     
  18. Gumbo

    Gumbo Erfahrenes Mitglied

    Eine Programmiersprache selbst kann nur grundlegende Sicherheit wie etwa Typsicherheit, Geltungsbereiche bieten. Dadurch werden die damit geschriebenen Anwendungen aber noch lange nicht sicher.

    PHP ist in diesem Sinne eine leider zu einfach zu lernende Sprache. Die subjektive Erfolgskurve ist steil, die objektive hingegen eher flach. Dadurch überschätzt sich so manch einer in seinen Fähigkeiten und grundlegende Regeln für den Umgang mit Benutzereingaben, wie Felix sie beispielsweise nannte, werden völlig außer Acht gelassen. Das Resultat davon ist millionenfach im Internet in der Form von schlechten Tutorials und Code-Schnipseln zu finden, die dennoch allzu gerne kopiert werden. Viele verstehen nicht einmal, was der kopierte Code tatsächlich tut. Es klingt fast absurd, aber selbst die einfachsten Probleme stellen für manche Programmierer eine unüberwindbare Hürde dar.

    Ein kennwortgesichertes System ist nur so sicher wie das Kennwort selbst. Wenn du ein häufig verwendetes Kennwort wie „test“, „12345“ oder eben „admin“ verwendest, ist es kein Wunder, dass dies bereits in einer MD5-Datenbank zu finden ist. Verbesserung kann neben der Verwendung eines ungeläufigeren Kennworts übrigens auch durch so genannte Salted Hashes mit konstantem oder auch zufälligem Salt-Wert bieten.
     
    Loomis gefällt das.
  19. Loomis

    Loomis Mitglied Bunt

    Guter Beitrag und gut erklärt, danke (!)
     
  20. Flex

    Flex (aka Felix Jacobi)

    Zuletzt von einem Moderator bearbeitet: 25. September 2011
Die Seite wird geladen...