[exe]

Das Problem beschränkt sich aber nicht nur auf Bulletin Boards sondern gilt generell für Webapplikationen auf PHP Basis. Wo die Gründe liegen ist eine gute Frage.
Das die Programmierer keine Ahnung von Sicherheit haben würde ich weitgehend ausschliessen da die Programmierer der bekannteren Boards doch recht fundierte PHP Kentnisse haben. Zeitdruck fällt ebenfalls weg, da wie du schon sagtest ein intval() oder is_numeric() reicht um den Typ eines URL Parameters sicherzustellen.
Ich denke das Problem ist schlicht und ergreifend Schlamperei. Das man mal das intval() oder is_numeric() vergisst oder das es nach einer Copy & Paste Session unbemerkt verschwunden ist kann passieren und ist mir auch schonmal passiert. Das in einer grösseren Software wie dem vB 2-3 Sicherheitslücken auftauchen ist dann kein Wunder mehr.
Die Gründe für XSS vulnerabilities fussen wohl auch auf Schlamperei. Wobei es bei XSS vulnerabilities auch schnell passiert das mal ein regulärer Ausdrück in den Sicherheitsroutinen versagt oder sich auf ähnliche Weisen Fehler einschleichen.
Eine Abhilfe könnte ein globales Sicherheitskonzept sein bei dem beispielsweise GPC Variablen global entschärft und überprüft werden, so das es nicht von intval() Aufrufen in irgendeiner Verzweigung des Scripts abhängt ob Daten sicher sind oder nicht ..

[itst]

Ein solches globales Abfangen ist ja erst in den neueren PHP-Versionen mittels den neuen Superglobals möglich. Vorher war es unmöglich bzw. zu sehr aufwändig. Doch man sieht das immer öfter. vBulletin macht das so, wenn ich das richtig verstanden habe, phpBB 2.2 wird es so machen und die anderen machen es auch oder werden es in der nächsten Zeit machen.

[Björn]

was genau sind den SQL-Injactions? *ma ganz dumm frag*

[MrNase]

ja Sascha, beim vBulletin3 ist es so gelöst. Trotzdem muss man aufpassen wenn man Hacks schreibt. Man blickt nicht direkt durch und öffnet deshalb bestimmt auch mal ein Scheunentor

[exe]

Zitat von trashar

was genau sind den SQL-Injactions? *ma ganz dumm frag*

Der Begriff sagt eigentlich schon fast was SQL-Injections sind. Das Prinzip ist relativ einfach: über eine Variable, die nicht richtig überprüft und entschärft wird, fügt ein Angreifer SQL Befehle in eine SQL-Abfrage ein und verändert sie irgendwie. Die Möglichkeiten so etwas auszunutzen sind recht vielfältig. In manchen Situationen kann man externe Programme über MySQL starten (und mit denen vielleicht andere Datenbanken ausspionieren), in anderen Sessioninformationen oder Passwörter anderer Benutzer auslesen. Man kann vielleicht auch einfach einen Login umgehen, der Kreativität sind da keine Grenzen gesetzt
Kleines Beispiel eines verwundbaren Login Scripts:

PHP-Code:

<?PHP
if($_SERVER['REQUEST_METHOD'] == 'POST') {
        $username = $_POST['username'];
        $password = $_POST['password'];

        $result = mysql_query("SELECT * FROM users WHERE username = '$username' AND password = '$password'");

        if(mysql_num_rows($result) == 1) {
                echo "Login erfolgreich!";
        } else {
                echo "Login fehlgeschlagen.";
        }
} 
?>

Wie man sieht trägt das Script den Benutzernamen und das Passwort ungefiltert in die MySQL Abfrage ein. Nehmen wir an ich wollte mich als Benutzer "Administrator" einloggen, kenne aber das Passwort nicht. Da die Abfrage verwundbar ist gebe ich einfach folgendes als Benutzername an:

Administrator'#

Was als Passwort eingegeben wird spielt keine Rolle mehr. Der Benutzername modifiziert die SQL Abfrage so das folgendes bei rauskommt:

SELECT * FROM users WHERE username = 'Administrator'#' AND password = ''

Da die Raute (#) in MySQL einen Kommentar einleitet wird alles hinter username = 'Administrator' auskommentiert, das Passwort wird bedeutungslos und ich als Angreifer als Administrator eingelogt.
Das war jetzt nur ein einfaches Beispiel, die Möglichkeiten bei SQL-Injections sind noch weitaus vielfältiger.

[Björn]

Oha
das ne richtig kack sicherheitslücke!!
ich habs grad mal lokal getestet uhuhuh..
was wär jetzt speziell bei dem beispiel hilfreich? addslashes()?
mfg

[printf]

Beitrag gelöscht.

[exe]

Ja, addslashes() auf alle Strings die in SQL-Abfragen eingesetzt werden sollte das Probleme beheben.

[Frederic Schneider]

Oder du globalisierst das ganze, indem du die superglobals bearbeitest.

[Michael Przybyla]

Meiner Meinung nach ist mysql_real_escape_string bzw. mysql_escape_string geeigneter.

@fredi: Und was sollte das bringen? Behebt ja nicht die Lücke.

Nebenbei: Statt intval kann man auch ctype_digit verwenden. (Ist meist auch sinnvoller)

[Frederic Schneider]

Zitat von CannabisCow

@fredi: Und was sollte das bringen? Behebt ja nicht die Lücke.

addslashes oder stripslashes auf alle superglobals anwenden, so was meinte ich.

[Björn]

wenn magic_quotes_gpc off sind werden $_GET $_POST und $_COOKIE mit addslashes behandelt..
die sicherheitslücke liegt also bei $_SESSION bei mir speziell!
und einfach anwenden auf alle wenn magic_quotes_gpc auf on ist dann kommt nur wir war ruas...
mfg

[Michael Przybyla]

Was viele vergessen, die $_SERVER Variablen sollte man auch behandeln.
Denn diese kann man ebf. manipulieren.

[Patrick Gotthardt]

Ich hoffe es ist ok, wenn ich nochmal was dazu frage...
Ich verwende für Felder, die Int sind meist (int) statt inval. Bsp.
$topicid = (int)$_REQUEST['topicid'];
Behebt das das Problem ebenfalls oder bringt nur intval den gewünschten Effekt?

[Michael Przybyla]

Das hat den gleichen Effekt wie void intval().
Allerdings solltest du beachten, dass dies nicht die Eingabe von -1 verhindert.

Wenn du nur Dezimalzeichen erlauben willst, empfehle ich die Benutzung von void ctype_digit() (Seit PHP 4.2.0 bzw. 4.3.0).

Die von dir angesprochene Typ-Umwandlung (int) (http://de2.php.net/manual/de/languag...e-juggling.php) wurde lediglich von C übernommen.