Ralf Hüsing

Ich kapiers nicht.

Während das Chaos Communication Camp 2007 lief und sich die Hacked Seite füllte hab ich selber auch mal ein wenig unqualifiziert im Netz rumgeklickt.

Es ist einfach mal vollkommen unklar. Eine simple Suche nach XSS Problemen hat nahezu 99% Erfolg. Warum?! Packen es die Leute nicht ausgaben entsprechend sinnvoll zu enkodieren?

SQL Injections zu finden stellt auch kein wirkliches Problem dar, eine simple Google Suche liefert passable Ergebnisse.

Es stellt sich natürlich immer die Frage wie gravierend die Probleme sind. Aber sobald man die Preise in einem Online Shop selber definieren kann wird es meiner Meinung nach dann doch etwas haarig.

Generell aber denke ich das es an der am meisten benutzten Programmiersprache für Webanwendungen liegt. Diese macht es dem (angehenden) Programmierer viel zu einfach Mist zu bauen. Es muss doch irgendwo normal sein das alle Werte die einem SQL Statement übergeben werden entsprechend gequotet werden? Sowas muss einfach vollkommen automatisch im Hintergrund geschehen. Desweiteren müssen natürlich alle Ausgaben entsprechend dem HTML Standard gequotet werden. Aber selbst das scheint vermutlich nicht allzu leicht.

Kurzum: Es nervt!

Nach dem Upgrade von Debian Sarge auf Etch und einem damit verbundenem MySQL Update von 4.x auf 5.x nervt mysqlcheck mit folgendem rum:

*datenbank*.*tabelle*
error    : Table upgrade required. Please do "REPAIR TABLE `*tabelle*`" to fix it!

Bis zum Ende lesen - es gibt eine Super einfache Kösung statt dieses Pipeline-SQL-Foo gefrickels.

Da jeder der mehr als eine Datenbank/Tabelle laufen hat sicherlich keine Lust hat das “fix it” manuell durchzuführen hier ein paar shell einzeiler:

# Temporäres Verzeichniss und syslog wegsichern
mkdir ~/mysql-repair/
cp /var/log/syslog ~/mysql-repair/
cd ~/mysql-reqair

# Fehlerhafte Datenbanken/Tabellen - Repair SQL Statement ermitteln
egrep  'debian-start.+: [^-: ]+$'  syslog | perl -nle 'print "USE `$1`; REPAIR TABLE `$2`;"  if /([^\s]+)\.([^\s]+)$/' > repair.sql

# Manuell Prüfen
less repair.sql

# Und Reparieren
mysql -u root -p < repair.sql > repair.log

# MySQL neustarten
/etc/init.d/mysql restart

# Prüfen mysqlcheck immer noch was zu meckern hat (hoffentlich nicht!)
tail -n50 /var/log/syslog

# Und aufräumen
rm -rf ~/mysql-repair

Ich wette das “mysqlcheck” obiges Feature direkt mitliefert, aber ich hab natürlich nicht nachgeschaut …

Und ja, nach dem raussuchen des Links zu mysqlcheck steht etwas von einem repair Parameter.