Water drops

Blog

Spam-Statistik

Meine offizielle Spam-Statistik für August 2003

Insgesamt erhielt ich im August 595 Spam-Mails und 4 Viren, das macht im Schnitt 19,3 Mails pro Tag. Wenn der Spam halten würde, was er verspricht, hätte ich am Monatsende folgendes zusammen gehabt:

Körper und Gesundheit

  • Diät: 45 Monatsrationen HGH umsonst. Damit hätte ich in fast 4 Jahren gut 1350 kg abnehmen können.
  • Penis: Verlängerung um 325 inches. Das entspricht einer Penislänge von über 8 Metern.
  • Viagra: 2 Flaschen und 5 Tabletten kostenlos.
  • Brustvergrößerung: 3 Flaschen umsonst. Das entspräche einer Vergrößerung um 9 Cups.
  • Rauchen: 2 mal Rauchen aufhören in zwei Wochen. Dabei bin ich Nichtraucher.

Geld

  • Nigeria-Connection: US $273.520.000,00 hätte ich als "vertrauenswürdiger Partner" anteilig bekommen.
  • Lottogewinne: US $7.000.000,00 habe ich im Lotto gewonnen, obwohl ich kein Lotto spiele.
  • Geldgewinne: US $30,00 habe ich einfach so gewonnen.
  • Versicherungen: € 8.000,00 pro Jahr hätte ich an Versicherungsprämien sparen können. Das ist mehr, als ich pro Jahr für Versicherungen ausgebe.

Partnerschaft

  • Videonachrichten: 9 mal habe ich eine Videonachricht erhalten, aber nie abgerufen. Wie gemein von mir!
  • Nette Nacht: 1 mal bedankte sich eine unbekannte Frau für die nette Nacht mit mir.
  • Kontaktanfrage: 2 Frauen wollten mit mir zwecks Partnerschaft in Kontakt treten.

Sonstiges

  • Diplome: 2 Diplome beliebiger Art hätte ich mir kaufen können.
  • Reisen: 12 Tage Bahamas und 9 Tage Orlando mit freiem Eintritt in Disney World habe ich geschenkt bekommen.

Mit anderen Worten: Ich würde nun mehrfacher Multimillionär sein und mich am Strand der Bahamas als Prof. Dr. mit athletischer Figur, einem 8 Meter langen Schwanz und Titten, die Dolly Buster erblassen lassen würde, mit einem Dutzend schöner Frauen amüsieren. Und da sag noch mal einer, Spam macht nicht glücklich... Nur das Viagra könnte ich nicht nehmen, da der Blutsturz mich umbringen würde. 😆

Erste Woche ermitteln

Dieses Script ermittelt den Timestamp der ersten Woche eines Jahres.

Die Wochen eines Jahres werden durchnummeriert. Das ist leider ein wenig komplizierter, als es auf den ersten Blick aussehen mag, da die erste Woche nicht mit dem 1. Januar beginnt.

Nach ISO 8601 ist die erste Woche des Jahres die Woche mit dem 4. Januar.

Das folgende Script ermittelt nun zu einem Jahr den Timestamp von Mitternacht des Montags der ersten Woche.

/** 
 * Get a timestamp of midnight of the first week's Monday of the given
 * year.
 *
 * @param   $year     Year to compute the timestamp for (4 digits)
 * @return  Timestamp of the first week's Monday
 */
function computeFirstWeek($year) {
  // Get the timestamp of January 4th of this year
  $jan4 = mktime(0,0,0,1,4,$year);

  // Get the weekday of that day (with Monday being 0)
  $wd = (date('w',$jan4) + 6) % 7;

  // Go back those number of days, to reach Monday
  $jan4 -= $wd*24*60*60;

  return $jan4;
}
SQL-Injections

Dieser Artikel geht über SQL-Injections, und wie man sie verhindern kann.

Was sind SQL-Injections?

Bei SQL-Injections macht ein Angreifer sich zu Nutze, dass Parameter an das Script ungeprüft an das SQL-Statement weitergereicht werden. Durch geschickte Manipulation des Parameters erreicht er so, dass das SQL-Statement eine völlig andere Bedeutung erhält.

Ein Beispiel: Wir haben ein Login-Script, welches einen Usernamen und ein Passwort übergeben bekommt. Das Script sucht nun in der users-Tabelle nach einem passenden User mit dem gleichen Passwort, und liefert im Erfolgsfall die User-ID zurück. Der Einfachheit halber gehen wir davon aus, dass der übergebene Username in $user und das Passwort in $pwd abgelegt ist.

Folgendes SELECT würde sich für die Aufgabe anbieten:

mysql_query("SELECT id FROM users WHERE name=$name AND pwd=$pwd");

Der Angreifer könnte nun jedoch als Passwort $pwd = "foo OR 1=1" an das Script übergeben. Dadurch sähe der fertige SELECT-Statement so aus:

SELECT id FROM users
  WHERE name=meier
    AND pwd=foo OR 1=1

Der Angreifer wäre damit trotz falschem Passwort erfolgreich als meier eingeloggt worden.

Abwehrmaßname 1: Hochkommata

Um dies abzuwehren, sollten grundsätzlich alle Variablen im SQL-Statement in einfache Hochkommata gesetzt werden. 1

mysql_query("SELECT id FROM users WHERE name='$name' AND pwd='$pwd'");

Der ursprüngliche Angriff mit $pwd = "foo OR 1=1" würde dann folgendes SELECT-Statement ergeben:

SELECT id FROM users
  WHERE name='meier'
    AND pwd='foo OR 1=1'

Die Datenbank nimmt in dem Fall an, dass das Passwort "foo OR 1=1" lautet. Der Angriff wäre damit wirkungslos. Allerdings kann der Angreifer selbst Hochkommata einsetzen. Mit folgendem Passwort wäre er wieder erfolgreich: $pwd = "foo' OR ‘1’='1". Dies würde das folgende SELECT-Statement ergeben:

SELECT id FROM users
  WHERE name='meier'
    AND pwd='foo' OR '1'='1'

Und schon würde der User meier erneut trotz falschem Passwort eingeloggt werden.

Abwehrmaßnahme 2: addslashes()

Um auch diesen Angriff abzuwehren, muss man sicher stellen, dass Hochkommata im Parameter ordentlich mit einem Backslash escaped werden. Dafür sorgt PHP mit den Magic Quotes automatisch, sofern sie aktiviert sind. Man sollte sich aber nicht darauf verlassen, sondern den Magic Quotes-Modus abschalten und sich selbst mit der Funktion addslashes() um ordentliches Escapen kümmern.

Der oben genannte Angriff lässt sich abwehren, indem man die Parameter $user und $pwd mit addslashes() sichert:

$user = addslashes($user);
$pwd  = addslashes($pwd);
mysql_query("SELECT id FROM users WHERE name='$name' AND pwd='$pwd'");

addslashes() würde im Angriffs-Passwort ein Backslash vor die Hochkommata stellen, was dann folgendes SELECT-Statement ergibt:

SELECT id FROM users
  WHERE name='meier'
    AND pwd='foo\' OR \'1\'=\'1'

Damit wäre die Abfrage wieder sicher. Der Angreifer hat nun keine Möglichkeit mehr, die Abfrage zu manipulieren. SQL-Injections sind nun nicht mehr möglich.

Weitere Sicherungsmaßnahmen

Zunächst sollten alle Parameter an das Script auf Plausibilität geprüft werden. Wenn man zum Beispiel eine Zahl erwartet, sollte man den Parameter mit intval() in eine Zahl wandeln und anschließend eine Bereichsprüfung durchführen.

Weiterhin gilt grundsätzlich, wirklich niemals ganze SQL-Kommandos per Parameter an das nächste Script weiter zu reichen. Dem Angreifer wird es damit ermöglicht, direkt SQL-Kommandos an die Datenbank zu schicken. Die Palette reicht von kleinen Spionage-SELECTs bis hin zu einem katastrophalen DROP DATABASE.

Um ein SQL-Kommando von einem Script zum nächsten zu transportieren, sollte man Sessions verwenden. In dem Fall bleibt das Kommando auf dem Server und kann vom Benutzer weder eingesehen noch verändert werden.

Zusammenfassung

Um SQL-Injections erfolgreich zu vermeiden, sollte man also:

  • alle übergebenen Parameter auf Plausibilität prüfen.
  • sämtliche Variablen in SQL-Statements mit Hochkommata einschließen.
  • Magic Quotes abschalten, und stattdessen
  • alle Parameter vor der Übergabe an das SQL-Statement mit addslashes() sauber escapen.
  • zum Weiterreichen eines SQL-Statements an das nächste Script niemals Parameter, sondern nur Sessions verwenden.

1 Dies erlaubt MySQL auch bei numerischen Spalten. Andere Datenbanken können darauf allerdings mit einer Fehlermeldung reagieren.