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