Angriffsversuch oder Programmierfehler?

[mumpel]

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é

[rkr]

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

[mumpel]

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.

[rkr]

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.

[mumpel]

[...] 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).

[...] Du kannst es maximal weniger "anfällig" machen [...]

Der beste Schutz ist der Verzicht darauf.

[Suralc]

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:

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:

<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</b> on line <b>8</b><br /> 

Getestet auf dem CLI-Server unter 5.6RC?

[nikosch]

Gute Analyse, Suralc!

[mumpel]

"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.

[Suralc]

"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.

[mumpel]

[...] Wenn du display_errors aktiviert hast [...]

Steht natürlich auf 0 (Absicht). Die Fehlermeldung aktiviere ich sinniger Weise nur während der Entwicklung.

[...] 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.

[...] 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.

[...] oder du hast einen Link auf diese Ressource auf deiner Seite [...]

Habe ich nicht. Wozu sollte man so leichtsinnig sein?

[...] 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.

[mumpel]

Ü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".

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