Sammlung von möglichen Sicherheitslücken in PHP gesucht!

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

  • Sammlung von möglichen Sicherheitslücken in PHP gesucht!

    Hallo,

    ich schreibe zur Zeit ein Programm, das sehr sicher sein MUSS!
    Und dafür brauche ich alle möglichen Sicherheitslücken die es in PHP gibt...

    Also das z.B. PHP_SELF eine sicherheitslücke ist, habe ich gehört.. aber warum ist das so?

    Das ist z.B. ein Sache und ich wette es gibt noch ettliche davon, die ich NOCH nicht kenne ...

    Danke für jede Hilfe!

  • #2
    Warum sollte PHP_SELF eine Sicherheitslücke sein?
    Sicherheitslücken einbauen kannst du viele, wenn du willst... aber eine PHP-Sicherheitslücke an sich ist mir beim aktuellen PHP nicht bekannt.

    Kommentar


    • #3
      Original geschrieben von jmc
      Warum sollte PHP_SELF eine Sicherheitslücke sein?
      Per Path-Info kann man da ggf. etwas einschleusen, htmlspecialchars($_SERVER[PHP_SELF]) ist zu empfehlen.

      Ansonsten: Eingaben escapen, wenn nötig. Ausgaben escapen, wenn nötig. Google "Sicherheitsücken php". Oder so.

      Ein netter Guide zum übersichtlichen Schreiben von PHP/MySQL-Code!

      bei Klammersetzung bevorzuge ich jedoch die JavaCoding-Standards
      Wie man Fragen richtig stellt

      Kommentar


      • #4
        Re: Sammlung von möglichen Sicherheitslücken in PHP gesucht!

        Original geschrieben von BananaJo
        Hallo,

        ich schreibe zur Zeit ein Programm, das sehr sicher sein MUSS!
        Verwende kein PHP.
        *SCNR*

        Und dafür brauche ich alle möglichen Sicherheitslücken die es in PHP gibt...
        http://php.net/manual/ listet sie alle auf. ;-)

        Nee, im Ernst. Wenn du so kommst:
        Also das z.B. PHP_SELF eine sicherheitslücke ist, habe ich gehört.. aber warum ist das so?
        ... dann solltest du das Schreiben dieses sehr sicheren Programms besser jemanden überlassen, der sich damit auskennt.

        Falls du dir das nicht leisten kannst|willst, wären mehr Informationen zum Einsatzbereich des Scripts hilfreich. Sonst bleibts nämlich bei Allgemeinplätzen, wie:
        * prüfe alle Eingabedaten (z.B. die superglobalen Arrays) und lasse nur die durch, die du benötigst|verstehst|sicher verarbeiten kannst.
        * wandle Daten so um, dass sie in der Zielanwendung (Browserausgabe, Datenbank, etc.) keinen Schaden anrichten können.
        * Vermeide PHP-Funktionen, die mit "unerwarteten" Eingabe-Daten nicht umgehen können (wie beispw. parse_url())
        * Informiere dich allgemein über Sicherheitsprobleme die bei deinem Projekt auftreten können (bspw. XSS, SQL- und Code-Injections, Directory-Traversal-Attacks, etc. pp.)

        Original geschrieben von ghostgambler
        Per Path-Info kann man da ggf. etwas einschleusen, htmlspecialchars($_SERVER[PHP_SELF]) ist zu empfehlen.
        Es gibt $_SERVER['SCRIPT_NAME'] für den relativen Pfad zum ausgeführten Script und notfalls $_SERVER['REQUEST_URI'] für die angehängten GET-Parameter. Das sollte für die Freunde des Affenformulars eigentlich ausreichen. ;-)

        Und was soll das HTML-Escapen eines Dateipfades bringen?
        Dass man (nur) bei der HTML-Ausgabe (für "CDATA") htmlspecialchars() benutzt, ist schon klar -- aber das gilt nicht nur für diese eine Variable ...
        Zuletzt geändert von fireweasel; 21.01.2009, 12:30.
        Klingon function calls do not have “parameters”‒they have “arguments”‒and they always win them!

        Kommentar


        • #5
          Was sollte man den bei PHP_SELF einschleusen können, was jemand anderen oder das interne Script beeinflusst? Kannst du mir ein nachvollziehbares Beispiel nennen? Dass es möglich ist damit eine Sicherheitslücke zu erstellen glaube ich gerne, aber da muss man sich schon ziemlich Mühe geben und die Variable auf eine abartige Weise benutzen, oder etwa nicht?

          Kommentar


          • #6
            Nein, XSS-Attacken sind damit ganz einfach möglich.
            Per Path-Info lassen sich z.B. Konstruktue wie
            /meinephpdatei/aktion/snostwas/
            bilden, wobei meinephpdatei eine Datei ohne .php-Endung ist.
            Wenn man dann ein switch für aktion mit default macht und überall nur PHP_SELF ausgibt, kann man z.B.
            /meinephpdatei/" /><script type="text/html">document.location = "test.htm"</script><
            aufrufen, und das im Formular eingesetzt macht dann offensichtlich irgendwas ekliges raus, wenn man nicht htmlspecialchars darauf anwendet.

            Ein netter Guide zum übersichtlichen Schreiben von PHP/MySQL-Code!

            bei Klammersetzung bevorzuge ich jedoch die JavaCoding-Standards
            Wie man Fragen richtig stellt

            Kommentar


            • #7
              Die Formulare kannst du ja auch ganz einfach selbst erstellen und abschicken und ausserdem würdest du damit ja wohl nur die Ausgabe bei dir selbst beeinflussen. Was stört es also, ausser dass dîe Anzeige (oder was auch immer), bei dir selbst dadurch fehlerhaft wird?
              Bei deinem Beispiel ja wohl nichts.
              Und bei der Verarbeitung eines Formulares, von welchem Daten auch für andere Benutzer gespeichert werden oder so muss die Eingabe ja wohl so oder so geprüft/bearbeitet werden, ob PHP_SELF oder nicht macht keinen Unterschied.

              Kommentar


              • #8
                Bitte informiere dich darüber was eine XSS-Attacke ist.
                Wenn du das getan hast, formuliere eventuell weitere Rückfragen - NACHDEM du das Beispiel mal ausprobiert hast - bitte erneut.

                Ein netter Guide zum übersichtlichen Schreiben von PHP/MySQL-Code!

                bei Klammersetzung bevorzuge ich jedoch die JavaCoding-Standards
                Wie man Fragen richtig stellt

                Kommentar


                • #9
                  Ich weiss was ne XSS Attacke ist, aber die wirkt sich hier auf niemanden aus, ausser auf den, welcher die Attacke gestartet hat.Damit das bei jemand anderem "irgendwas ekliges ausmacht" müsste man zumindest einige andere Fehler bei der Verarbeitung der empfangenen Daten machen, den interne Fehler entstünden sonst keine und auch keine Ausgabefehler ausser beim Verursacher.
                  Das selbe gilt bei QUERY_STRING und ä.

                  Kommentar


                  • #10
                    vielleicht ist hier was bei?

                    peter
                    Nukular, das Wort ist N-u-k-u-l-a-r (Homer Simpson)
                    Meine Seite

                    Kommentar


                    • #11
                      Allein schon die Weiterleitung auf eine andere Seite kann bei unbedarften Benutzern ein Sicherheitsproblem sein.

                      Ein netter Guide zum übersichtlichen Schreiben von PHP/MySQL-Code!

                      bei Klammersetzung bevorzuge ich jedoch die JavaCoding-Standards
                      Wie man Fragen richtig stellt

                      Kommentar


                      • #12
                        Wer hat etwas von einer Weiterleitung gesagt? Ausserdem wird ja höchstens der Verursacher der Weiterleitung (wenn z.B. javascript mit Absicht in den Query eingefügt) selbst weitergeleitet.

                        Wenn du mir ein konkretes Beispiel geben kannst, wo nicht nur das der Fall ist und PHP_SELF eine Sicherheitslücke darstellt kannst du mir sehr gerne eines zeigen.

                        @Peter Kropff -> Ich finde bei deinen Beispielen nur Fehler - die noch etwas mit diesem Thema zu tun haben, welche aufgrund von nicht verarbeiteten Daten, die wiederum anderen Benutzern zur Verfgung gestellt werden, entstehen. Und dass diese Daten geprüft/bearbeitet werden müssen ist ja wohl so oder so klar, aber das hat eigentlich nichts mit dem Gebrauch der variable $_SERVER['PHP_SELF'] zu tun.

                        Kommentar


                        • #13
                          Original geschrieben von jmc
                          Wer hat etwas von einer Weiterleitung gesagt? Ausserdem wird ja höchstens der Verursacher der Weiterleitung (wenn z.B. javascript mit Absicht in den Query eingefügt) selbst weitergeleitet.
                          Hast du dir mein Beispiel überhaupt mal angesehen? Geschweige denn ausprobiert (oder auch wenigstens nur verstanden)?!
                          Sagt dir der Begriff Phishing etwas?

                          Wenn du das Potential der Attacke nicht erkennen vermagst, und das selbst erkannt hast, arbeite an deinem Wissen. Wenn du der Meinung bist das ist vollkommen irrelevant und ungefährlich, soll mir auch recht sein.

                          Ein netter Guide zum übersichtlichen Schreiben von PHP/MySQL-Code!

                          bei Klammersetzung bevorzuge ich jedoch die JavaCoding-Standards
                          Wie man Fragen richtig stellt

                          Kommentar


                          • #14
                            Sprachunabhängige Sicherheitslücken sind deutlich häufiger. Du suchst ganz bestimmt die.

                            Kurz: http://www.sans.org/top25errors/
                            Details: http://cwe.mitre.org/top25/

                            edit: BananaJo, spielst du Q3?
                            Zuletzt geändert von CadEx; 23.01.2009, 12:17.
                            PHP-Code:
                            function verrecke_elend()
                            {
                                die(
                            'Aaargh!');

                            Kommentar


                            • #15
                              Original geschrieben von jmc
                              Wer hat etwas von einer Weiterleitung gesagt? Ausserdem wird ja höchstens der Verursacher der Weiterleitung (wenn z.B. javascript mit Absicht in den Query eingefügt) selbst weitergeleitet.
                              Du hast XXS nicht ganz verstanden. Die manipulierte URL kann Dir z.B. per E-Mail geschickt werden, bei einer HTML-Mail siehst Du das nichtmal.

                              Hier ist auch noch ein "nettes" Beispiel:

                              http://blog.oncode.info/2008/05/07/p...scripting-xss/

                              Wenn das ein Login-Formular wäre, hätte der Angreifer die Zugangsdaten Deines Kontos.

                              Kommentar

                              Lädt...
                              X