Ankündigung

Einklappen
Keine Ankündigung bisher.

wieso ist PHP_SELF unsicher?

Einklappen
X
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

  • wieso ist PHP_SELF unsicher?

    Huhu ihrs,

    grade hab ich so durch zufall des öffteren gelesen, das PHP_SELF unsicher wäre. wieso das denn?

    als beispiel wurden immer solche forms angegeben:
    PHP-Code:
    <form action="<?php echo $_SERVER['PHP_SELF']; ?>" method="post">
        <input type="text" name="search">
        <input type="submit" value="Suchen">
    </form>
    dann soll dort in der url böser code eingeschleußt werden. na und? wo ist denn dann die sicherheitslücke? der xss würde dann doch auf den angreifer selbst ausgeführt werden. also wo ist da das problem?


  • #2
    Das ist hier ganz gut erklärt:

    PHP_SELF ist böse! Potentielles Cross Site Scripting (XSS)! | Technik, Gothic und Anderes

    Gruß
    D.

    Kommentar


    • #3
      ja das hab ich auch gelesen, jedoch ist das nur für den jenigen ein problem, der diese url aufruft, oder sehe ich das falsch?

      Kommentar


      • #4
        Grundsätzlich hast du natürlich Recht, dass schadhafter Code nur auf den Angreifer selbst wirkt. Schadhaft wird es erst in Kombination mit weiteren Sicherheitslücken, beispielsweise falls ein Angreifer es schafft, zeitgleich einen <base> Tag einzuschleusen, denn PHP_SELF ist ein relativer Pfad und als solcher könnte man ein Formular plötzlich umleiten (wie gesagt in Kombination mit einer weiteren Sicherheitslücke).
        Solange immer konkrete Dateien hinter einem Aufruf stecken, hat ein Angreifer wenig Chancen. So ist es aber beispielsweise bei einem modernen Framework so, dass über mod_rewrite versucht wird, generische URLs zu einem Controller u.ä. weiterzuleiten. Und genau hier kann ein Angreifer durchaus bösen Code einschleusen, so dass neben der URL auch beispielsweise das Base-Tag eingeschleust wird.

        XSS ist das Prinzip, einen Code so einzuschleusen, dass er beispielsweise beim Klicken auf eine URL wirkt. Die URL veröffentlicht man dann beispielsweise in Phishing-Mails oder im eigenen Forum der Webseite.
        www.php-maven.org PHP und Maven vereint: Build/Deploy/Produktion/Konfiguration, Projekt Management, CI, PHPUnit, zahlreiche Frameworks
        Twitter @ https://twitter.com/#!/mepeisen und Facebook @ http://t.co/DZnKSUih

        Kommentar


        • #5
          hrm, naja ich seh das jetzt nicht so als sicherheitslücke.... wenn ich die daten des formulars auf einen anderen link umleiten will, kann ich auch mein firebug aufmachen und den link anpassen

          Kommentar


          • #6
            Es geht nicht darum, dass du selbst das bei dir machst. Es geht darum, eine URL zu bauen, mit der man schadhaften Code einschleusen kann. Und diese URL kann man dann verwenden, um beispielsweise Password-Phishing zu betreiben.
            99,9% der ermittelten Passwörter werden durch solches Phishing unter Ausnutzen der Sicherheitslücken gewonnen, einfach weil zu viele nicht genau hingucken und schnell einmal einen schadhaften Link angeklickt haben.
            www.php-maven.org PHP und Maven vereint: Build/Deploy/Produktion/Konfiguration, Projekt Management, CI, PHPUnit, zahlreiche Frameworks
            Twitter @ https://twitter.com/#!/mepeisen und Facebook @ http://t.co/DZnKSUih

            Kommentar


            • #7
              Zitat von DarkPrisma Beitrag anzeigen
              hrm, naja ich seh das jetzt nicht so als sicherheitslücke.... wenn ich die daten des formulars auf einen anderen link umleiten will, kann ich auch mein firebug aufmachen und den link anpassen
              Das ist das gleiche wie ungesicherte $_GET/$_POST Variablen.

              Der Aufruf erfolgt durch die URL, d.h. du kannst jemandem diese URL zukommen lassen und das Formular "manipulieren". Wenn dieser jemand nicht auf die URL achtet und das manipulierte Formular abschickt, tjoah...

              Anderes Beispiel ein Forum wo man ein Benutzerkontrollzentrum hat sowie einen Autologin per Cookie. Ist dort ein Formular mit $_SERVER['PHP_SELF'] angegeben brauchst du nur ein JavaScript einschleusen welches den Cookie des URL-Aufrufenden an DEINEN Server schickt.

              Jeder Benutzer des Forums der den "remeber me" Haken gesetzt hat und deinen Link aufruft hat ein Problem. Am besten verschleiert man die URL noch irgendwie das es harmlos aussieht und amcht nen heimlichen Redirect auf die "böse" URL.

              Das ist nicht möglich wenn die FormAction statisch eingetragen ist. Dann kannst du in deinem Firebug rumfummeln wie du möchtest.

              Wer da die Sicherheitslücke nicht sieht braucht ne Brille.
              "Alles im Universum funktioniert, wenn du nur weißt wie du es anwenden musst".

              Kommentar


              • #8
                also ist es wieder nur eine lücke für leute, die eine gefälschte url bekommen

                Kommentar


                • #9
                  Zitat von DarkPrisma Beitrag anzeigen
                  also ist es wieder nur eine lücke für leute, die eine gefälschte url bekommen
                  "Nur" ist gut...
                  "Alles im Universum funktioniert, wenn du nur weißt wie du es anwenden musst".

                  Kommentar


                  • #10
                    Hier noch das Fachwort dafür: cross site request forgery
                    --

                    „Emoticons machen einen Beitrag etwas freundlicher. Deine wirken zwar fachlich richtig sein, aber meist ziemlich uninteressant.
                    Wenn man nur Text sieht, haben viele junge Entwickler keine interesse, diese stumpfen Texte zu lesen.“


                    --

                    Kommentar


                    • #11
                      Zitat von DarkPrisma Beitrag anzeigen
                      hrm, naja ich seh das jetzt nicht so als sicherheitslücke.... wenn ich die daten des formulars auf einen anderen link umleiten will, kann ich auch mein firebug aufmachen und den link anpassen
                      Falsche Einstellung, auch geht es hier nicht um umleiten der URL, sondern um JavaScript u.a. auszuführen, um damit an sensible Daten zu kommen. Auch geht es darum, dass ein Angreifer Dir eine manipulierte URL unterschieben kann, wenn der Benutzer nicht auf die Statuszeile achtet. Nicht weniger gefährlich ist die kleine Manipulation, die ich bei der Homepage hier im Forum angegeben habe. Es ruft nur eine harmlose JavaScript-Warnmeldung auf, aber theoretisch könnte ich ggf. auch ein eigenes Script darüber starten lassen. Der Benutzer der nicht drauf achtet, wie hier die Links bei den Homepages gesetzt ist, bzw. JavaScript abschaltet, wird auch Opfer eines XSS.


                      Viel Spass beim Ausprobieren.

                      BTW. der Bug ist seit 08.10.2009 bekannt und gefixed.

                      http://www.securityfocus.com/archive...30/60/threaded

                      Kommentar


                      • #12
                        Zitat von DarkPrisma Beitrag anzeigen
                        also ist es wieder nur eine lücke für leute, die eine gefälschte url bekommen
                        Wenn durch deine Fahrlässigkeit Kundendaten verloren gehen, kannst du großen Ärger bekommen; zusätzlich zur schlechten Publicity.
                        "Mein Name ist Lohse, ich kaufe hier ein."

                        Kommentar

                        Lädt...
                        X