Ankündigung

Einklappen
Keine Ankündigung bisher.

Angriffsversuch oder Programmierfehler?

Einklappen

Neue Werbung 2019

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

  • Angriffsversuch oder Programmierfehler?

    Hallo!

    Ich habe seit heute Einträge wie "xxx.xxx.xxx.xx - - [16/Jul/2014:10:53:05 +0200] "GET /function.session-start" in meiner access_log. Ist das ein (erfolgloser) Angriffsversuch? Oder steckt irgendwo ein Fehler in meiner Programmierung den ich nicht identifizieren kann (bei meinen Tests funktioniert immer alles, Angriffsversuche werden dabei erfolgreich und wie gewünscht abgewehrt/quittiert)? Die IP verweist immer auf Istanbul. Danke!

    Gruß, René


  • #2
    Naja, da hat jemand versucht die Resource /function.session-start zu öffnen.
    Das Resourcen-Schema kenne ich von php.net:
    http://php.net/manual/de/function.session-start.php
    Standards - Best Practices - AwesomePHP - Guideline für WebApps

    Kommentar


    • #3
      Dann muss die Angriffsmeldung anders zustande gekommen sein. Denn wenn bei mir jemand versucht das Kontaktformular zu manipulieren bekommt er eine entsprechende Meldung angezeigt und ich per Email eine Angriffsmeldung. In meinem Kontaktformular prüfe ich nämlich ob auch nur die Felder gesendet/übergeben werden die ich haben möchte. Wird ein Feld zuviel übergeben lasse ich das Script sofort aussteigen. Und ausserdem ist nur "POST" erlaubt, bei "GET"-Übergaben lasse ich das Script ebenfalls sofort aussteigen.


      Wie die Angreifer nur auf die Idee kommen ich würde solche "Resourcen" offen zugänglich lassen!? Bei mir versuchten Angreifer auch ständig Joomla-Code als Parameter zu nutzen. Dabei habe ich noch nicht einmal Joomla, und wenn würde ich es absichern wie es sich gehört.

      Kommentar


      • #4
        Ich unterstelle dir jetzt einfach mal, dass du gar nicht weisst, was Angreifer so alles machen können.

        Ausserdem: Du kannst Joomla nicht "absichern". Du kannst es maximal weniger "anfällig" machen.
        Standards - Best Practices - AwesomePHP - Guideline für WebApps

        Kommentar


        • #5
          Zitat von rkr Beitrag anzeigen
          [...] Ich unterstelle dir jetzt einfach mal, dass du gar nicht weisst, was Angreifer so alles machen können [...]
          Du meinst "versuchen können". Ich weiss schon was alles möglich ist. Ich teste mein Kontaktformular selber auf Sicherheitslücken (DOM-Konsole, FireBug). Aber die Email-Meldungen zeigen mir dass mein Kontaktformular (bisher) sicher ist. Angriffsversuche gibt es in letzter Zeit viele. Bisher erfolglos, also muss ich ja irgend etwas richtig machen (hoffe ich).


          Zitat von rkr Beitrag anzeigen
          [...] Du kannst es maximal weniger "anfällig" machen [...]
          Der beste Schutz ist der Verzicht darauf.

          Kommentar


          • #6
            Hast du error reporting auf deinem Produktivsystem aktiviert?

            Falls ja hast du vermutlich "docref_root" auf ein falsches Verzeichnis verwiesen und ein Nutzer hat den Link angeklickt, den er gesehen hat. Stellt sich nur die Frage, warum ein Nutzer auf einem Produktivsystem eine Fehlermeldung sieht und warum session_start unter umständen an einem fehler beteiligt ist.



            http://php.net/manual/de/errorfunc.c...ni.docref-root

            "docref_root" nicht zu setzten erhählt die Nachricht, entfernt aber den Link.

            Beispiel:
            PHP-Code:
            error_reporting(E_ALL);
            ini_set('docref_root'' '); // Jeder, nicht leere String erzeugt einen Link in der Fehlermeldung.
            ini_set('html_errors''1');
            ini_set('display_errors''1');

            preg_match('\\\\i''abc'$m); 
            Erzeugt:
            PHP-Code:
            <b>Warning</b>:  preg_match() [<a href='function.preg-match'>function.preg-match</a>]: Delimiter must not be alphanumeric or backslash in <b>D:\test\new.php</bon line <b>8</b><br /> 
            Getestet auf dem CLI-Server unter 5.6RC?
            Zitat von nikosch
            Naja, anscheinend spricht die Steckdose kein HTTP. LOL

            Kommentar


            • #7
              Gute Analyse, Suralc!
              --

              „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


              • #8
                "docref_root"? Link? Produktivsystem? Was soll das bedeuten? Ich benutze weder "docref_root" noch "ini_set" (wozu sollte ich auch? Ich muss nichts initialisieren, da kein Datenbankzugriff erfolgt.). Man gibt in der Adresszeile die URL für das Kontaktformular ein. Oder man klickt im Navigationsmenü auf den entprechenden Punkt. Anscheinend gibt der Angreifer "function.session-start" direkt hinter der URL ein.

                Kommentar


                • #9
                  Zitat von mumpel Beitrag anzeigen
                  "docref_root"? Link? Produktivsystem? Was soll das bedeuten? Ich benutze weder "docref_root" noch "ini_set" (wozu sollte ich auch? Ich muss nichts initialisieren, da kein Datenbankzugriff erfolgt.).
                  ini_set hat i.d.R nichts mit einem Datenbankzugriff zutuen. Wenn du display_errors aktiviert hast (was auf einem System, welches offen im Netz hängt eine fragwürdige Entscheidung ist) gibt dir der Link in meinem Beitrag eine Erklärung für das Vorhandensein eines Links und warum ein Nutzer diesen klicken könnte. (Und auch warum er auf deine eigene Seite verweist und nicht ins manual).
                  Man gibt in der Adresszeile die URL für das Kontaktformular ein. Oder man klickt im Navigationsmenü auf den entprechenden Punkt. Anscheinend gibt der Angreifer "function.session-start" direkt hinter der URL ein.
                  Warum Angreifer? Es gibt für mich keinen ersichtlichen Grund warum jemand dies tuen sollte. Entweder der "Angreifer" denkt deine Seite ist das PHP-Manual oder du hast einen Link auf diese Ressource auf deiner Seite. Warum ein solcher Link vorhanden sein könnte, ist ebenfalls in meinem vorherigen Beitrag anhand einer anderen Funktion beispielhaft aufgezeigt.

                  Schau mal in dein Errorlog (und stelle vorher sicher, das Fehler überhaupt geloggt werden) ob Fehler gemeldet werden, die zeitlich zum Aufruf passen.
                  Zitat von nikosch
                  Naja, anscheinend spricht die Steckdose kein HTTP. LOL

                  Kommentar


                  • #10
                    Zitat von Suralc Beitrag anzeigen
                    [...] Wenn du display_errors aktiviert hast [...]
                    Steht natürlich auf 0 (Absicht). Die Fehlermeldung aktiviere ich sinniger Weise nur während der Entwicklung.

                    Zitat von Suralc Beitrag anzeigen
                    [...] was auf einem System, welches offen im Netz hängt eine fragwürdige Entscheidung ist [...]
                    Eben. Aber weshalb sprecht ihr immer von "System"? Das ist eine "normale Webseite" (ohne Datenbankzugriffe, bis auf "expCounter"), gehostet bei Host-Europe.

                    Zitat von Suralc Beitrag anzeigen
                    [...] Warum Angreifer? Es gibt für mich keinen ersichtlichen Grund warum jemand dies tuen sollte [...]
                    Um ein Einfallstor zu finden (Datendiebstahl)? Ich kann auch nicht verstehen weshalb jemand einen "Joomla-Request" auf meine Seite absetzt ohne meine Einwilligung und ohne zu wissen dass ich überhaupt kein Joomla einsetze.

                    Zitat von Suralc Beitrag anzeigen
                    [...] oder du hast einen Link auf diese Ressource auf deiner Seite [...]
                    Habe ich nicht. Wozu sollte man so leichtsinnig sein?


                    Zitat von Suralc Beitrag anzeigen
                    [...] ob Fehler gemeldet werden, die zeitlich zum Aufruf passen [...]
                    Fehler werden natürlich geloggt. Da steht nur drin dass "GET /function.session-start" nicht existiert. Ich habe selber mal "http://www.xxx.de/function.session-start" aufgerufen und damit die selbe Fehlermeldung in der error_log erzeugt.

                    Kommentar


                    • #11
                      Übrigens:
                      Auch Folgendes steht hin und wieder in der error_log, von dem ich nicht weiss wie das zustande kommt. Mir hat man gesagt dass sei das "üblich Hintergrundrauschen", oder anders gesagt "übliche Angriffsversuche".

                      PHP-Code:
                      File does not exist: /xx/xxx/xxx/www/xx/).length,l.htmlSerialize=!!b.getElementsByTagName 

                      Kommentar

                      Lädt...
                      X