[HaBo]

Flashkobb · 25.06.10, 00:58

Hi,

heute bin ich wieder über etwas gestolpert, was ich nicht nachvollziehen kann:

?id=-54+union+select+concat_ws(0x3a,version(),database( ),user()),2,3,4

Mir ist klar, daß diese Injection die MySQL Version den Datenbanknamen und den User ausgibt... aber warum?

Ich habe dieses Ding auf russischen Seiten gefunden, die eine Vielzahl an Internet Seiten gehackt haben und die Ergebnisse dort veröffentlichen...

Ich möchte diese Links nicht posten, da dort Passwörter etc aufgelistet worden sind und die Sicherheitslücken nach wie vor auf den meisten Seiten bestehen. Die Webmaster haben diese Lücken scheinbar noch nicht entdeckt.

**bitmuncher** · 25.06.10, 01:06

Das sind die Daten, die man zum Raussuchen eines versionsspezifischen Exploits und zum durchführen eines möglichst klein gehaltenen Bruteforce mindestens braucht.

Anzeige

- Anzeige -

happytreefriend · 04.11.10, 00:40

Zitat:

Zitat von Flashkobb

Hi,

heute bin ich wieder über etwas gestolpert, was ich nicht nachvollziehen kann:

?id=-54+union+select+concat_ws(0x3a,version(),database( ),user()),2,3,4

Mir ist klar, daß diese Injection die MySQL Version den Datenbanknamen und den User ausgibt... aber warum?

Ich habe dieses Ding auf russischen Seiten gefunden, die eine Vielzahl an Internet Seiten gehackt haben und die Ergebnisse dort veröffentlichen...

Ich möchte diese Links nicht posten, da dort Passwörter etc aufgelistet worden sind und die Sicherheitslücken nach wie vor auf den meisten Seiten bestehen. Die Webmaster haben diese Lücken scheinbar noch nicht entdeckt.

Was genau möchtest du jetzt wissen? Wieso SQLi funktionieren?

?id=-54+union+select+concat_ws(0x3a,version(),database( ),user()),2,3,4

Ich spalte mal die Abfrage auf

So würe sie normal ausschauen:?id=-54

Mit dem Befehl UNION kann man bei SQL abfragen verbinden+union+

danach kommt halt die Abfrage wenn dafür noch Felder für die Ausgabe Vorhanden sind.

select+concat_ws(0x3a,version(),database(),user()) ,2,3,4

Und so würde es im Quellcode ausschaue

Nur als Beispiel
$sql = "SELECT * FROM tabelle where id = '$_GET['id']'"

Und somit schließt er mit union noch eine Abfrage hinten an

Vyger · 15.11.10, 16:14

Mich würden mögliche Gegenmaßnahmen interessieren, vielleicht direkt am obigen Beispiel.

mime · 15.11.10, 17:32

Zitat:

Zitat von Vyger

Mich würden mögliche Gegenmaßnahmen interessieren, vielleicht direkt am obigen Beispiel.

Na ja...der Entwickler muss den Inhalt der per GET-Request übergebenen Variable "id" mit den Mitteln der von ihm benutzen Sprache "aufräumen".

In php z.B.

PHP-Code:

  $id = intval( $_GET['id'] );

if( $id > 0 ) { 
  $sql = "SELECT bar,foo FROM tabelle where id = " . $id;
} else {
  // ERROR_HANDLING...
}

Micha

beavisbee · 15.11.10, 17:51

Zitat:

Zitat von Vyger

Mich würden mögliche Gegenmaßnahmen interessieren, vielleicht direkt am obigen Beispiel.

ganz allgemein gesagt:
Never trust an user-input!!!

Werte, wo Zahlen erwartet werden, explizit als int oder float (was eben erwartet wird) casten
Wahrheitswerte (boolean) ebenfalls explizit casten
Zeichenketten escapen (z.B. mit mysql_real_escape_string())

Thunderb0lt · 15.11.10, 19:36

Zitat:

Zitat von beavisbee

Werte, wo Zahlen erwartet werden, explizit als int oder float (was eben erwartet wird) casten
Wahrheitswerte (boolean) ebenfalls explizit casten

IMHO sollte nicht versucht werden irgendwelchen ungültigen Userinput nachträglich zu validieren. Wenn da ungültige Daten reinkommen, dann sind diese zu verwerfen.
Das heißt, wird eine Zahl erwartet, und man bekomme einen String, dann sollte man nicht versuchen diesen in eine Zahl zu casten.
In PHP gibts dafür z.B. is_numeric() und Strings kann man mit Regulären Ausdrücken über z.B. preg_match() prüfen. Ein mysql_real_escape_string() sollte natürlich trotzdem nicht fehlen

beavisbee · 15.11.10, 23:09

Zitat:

Zitat von Thunderb0lt

In PHP gibts dafür z.B. is_numeric() und Strings kann man mit Regulären Ausdrücken über z.B. preg_match() prüfen.

Das ist IMO zum Teil Geschmackssache und hängt zum anderen Teil vom Einsatzgebiet ab.
Wenn es eine ehr unwichtige numerische Eingabe ist, bei der ein "0" im Zweifelsfall keinen Schaden anrichtet, dann brauche ich ja nicht unbedingt zusätzliche Rechenleistung für Fehler-Routinen beanspruchen.
Beispiel: Wenn eine Bildergallerie bei manipuliertem Start-Bild-Wert eben als Wert 'ne 0 annimmt und somit die erste Seite der Gallerie anzeigt, dann ist das ja nicht weiter tragisch.

Wenn die Zahl natürlich 'nen wichtigen Einfluss hat und nicht vernachlässigt werden darf (meinetwegen 'ne Postleitzahl bei der Adress-Eingabe), dann hast du Recht - da sollte man abfragen und gegebenen Falls 'ne Fehlermeldung bringen.

Inliferty · 16.11.10, 00:44

Weil ich das Schlagwort nochnicht gehört habe werfe ich einfach mal prepared Statements in den Raum

http://de.wikipedia.org/wiki/Prepared_Statement
Dabei werden die Daten als _DATEN_ interpretiert und haben nichts mit dem SQL-Statement zu tun.

Für PHP gibts dazu eine schöne Klasse(PDO):
http://php.net/manual/de/pdo.prepared-statements.php

MfG
Inliferty

mime · 16.11.10, 11:42

Zitat:

Zitat von Thunderb0lt

Das heißt, wird eine Zahl erwartet, und man bekomme einen String, dann sollte man nicht versuchen diesen in eine Zahl zu casten.

PHP-Code:

  <?php
print gettype($_GET['id']) . "\n";
?>

Code:

mime@kira:~ %  GET http://localhost/x.php?id=1
string

Eine GET-Variable ist immer vom Typ String.

Micha

beavisbee · 16.11.10, 12:00

Zitat:

Zitat von mime

Eine GET-Variable ist immer vom Typ String.

wenn der String jedoch nur aus Zahlen besteht, gibt is_numeric() trotzdem true zurück und somit das von Thunderb0lt gewünschte Ergebnis.

PHP-Code:

  <?php
function getinfo($num)
{
    echo 'Typ         : ' . gettype($num) . chr(10);
    echo 'numeric     : ' . (is_numeric($num)?'ja':'nein') . chr(10);
    echo 'cast to int : ' . (int)$num . chr(10) . chr(10);
}
getinfo('123');
getinfo(123);
getinfo('12a3b');
getinfo(null);

?>

Code:

martin@lenotux:~$ php test.php 
Typ         : string
numeric     : ja
cast to int : 123

Typ         : integer
numeric     : ja
cast to int : 123

Typ         : string
numeric     : nein
cast to int : 12

Typ         : NULL
numeric     : nein
cast to int : 0

martin@lenotux:~$

ich persönlich handhabe das meist so:
Wenn ich irgendwelche Model-Klassen programmiere, wird dort (mit wenigen Ausnahmen) hart gecastet - eine Klasse soll schließlich Funktionalität darstellen und nicht Dummheit oder Böswilligkeit des Users anmeckern.
Wenn eine Fehler-Behandlung stattfinden soll, dann werden die Daten, bevor sie an das Model gegeben werden, im Controller validiert und dort wird dann für die Ausgabe einer Fehlermeldung oder dergleichen gesorgt.

mime · 16.11.10, 13:25

Zitat:

und somit das von Thunderb0lt gewünschte Ergebnis.

Ja, ich habe nichts anderes behauptet...

Ich persönlich bin kein Freund von is_numeric. Das akzeptiert mir zu viel. Ich will z.B. keine Hex Values in meinen Querys. Und sowas auch nicht.

PHP-Code:

  <?php

include("db.inc");

if(is_numeric($_GET['id'])) {
  db_query("SELECT id FROM results WHERE id = " . $_GET['id']);
}  
?>

Code:

mime@kira:~ %  GET http://localhost/x.php?id=123e4567
1367 - Illegal double '123e4567' value found during parsing -- SELECT id FROM results WHERE id = 123e4567

Das ist doch Mist...

Micha

beavisbee · 16.11.10, 13:43

Zitat:

Zitat von mime

Das ist doch Mist...

FullACK! Deshalb wird bei mir auch alles gecastet

Thunderb0lt · 16.11.10, 18:38

Zitat:

Zitat von mime

Ich persönlich bin kein Freund von is_numeric. Das akzeptiert mir zu viel. Ich will z.B. keine Hex Values in meinen Querys.

Ein interessanter Punkt, den ich zugegebenermaßen bisher gar nicht auf meiner Liste hatte. Danke für den Hinweis!

Hackse · 11.10.11, 15:38

Bei Usereingaben überprüfe ich min. und max. Länge, sowie Definitionsbereich (zulässige Zeichen) und Zeichenmuster via regular Expression. Hierzu schrieb ich folgende Funktion:

PHP-Code:

  /*
function check_user_input(): validation of user input by length check and regex-check

$value:     user input to be checked
$len_min:   allowed min. length
$len_max:   allowed max. length
$regex:     allowed regex. pattern for $value

return values:
-1 : $value too short
+1 : $value too long
+2 : $value doesn't match regex pattern
 0 : $value is O.K.

*/

function check_user_input($value, $len_min, $len_max, $regex) {
  $len=strlen($value);
  if ($len < $len_min) return -1;
  if ($len > $len_max) return  1;
  return (preg_match($regex, $value)) ? 0 : 2;
}

Gibt es Einwände?

Anzeige

- Anzeige -

25.06.10, 00:58	#1 (permalink)
Flashkobb Registriert seit: 23.05.10 Likes: 0	SQL Injections Anzeige Hi, heute bin ich wieder über etwas gestolpert, was ich nicht nachvollziehen kann: ?id=-54+union+select+concat_ws(0x3a,version(),database( ),user()),2,3,4 Mir ist klar, daß diese Injection die MySQL Version den Datenbanknamen und den User ausgibt... aber warum? Ich habe dieses Ding auf russischen Seiten gefunden, die eine Vielzahl an Internet Seiten gehackt haben und die Ergebnisse dort veröffentlichen... Ich möchte diese Links nicht posten, da dort Passwörter etc aufgelistet worden sind und die Sicherheitslücken nach wie vor auf den meisten Seiten bestehen. Die Webmaster haben diese Lücken scheinbar noch nicht entdeckt.

25.06.10, 01:06	#2 (permalink)
bitmuncher Moderator Registriert seit: 30.09.06 Likes: 443	Das sind die Daten, die man zum Raussuchen eines versionsspezifischen Exploits und zum durchführen eines möglichst klein gehaltenen Bruteforce mindestens braucht. __________________ Mein Blog - Mein Job - Diaspora Der Ring uns zu knechten besteht aus 12 Sternen auf blauem Grund. Neue Beiträge im Habo via Twitter - Das HaBo auf FB - Das HaBo bei G+

11.10.11, 15:38	#15 (permalink)
Hackse Registriert seit: 31.07.06 Likes: 32	Bei Usereingaben überprüfe ich min. und max. Länge, sowie Definitionsbereich (zulässige Zeichen) und Zeichenmuster via regular Expression. Hierzu schrieb ich folgende Funktion: PHP-Code: /* function check_user_input(): validation of user input by length check and regex-check $value: user input to be checked $len_min: allowed min. length $len_max: allowed max. length $regex: allowed regex. pattern for $value return values: -1 : $value too short +1 : $value too long +2 : $value doesn't match regex pattern 0 : $value is O.K. */ function check_user_input($value, $len_min, $len_max, $regex) { $len=strlen($value); if ($len < $len_min) return -1; if ($len > $len_max) return 1; return (preg_match($regex, $value)) ? 0 : 2; } Gibt es Einwände?

Themen-Optionen
Druckbare Version zeigen Jemanden per E-Mail auf dieses Thema hinweisen
Ansicht
Linear-Darstellung Zur Hybrid-Darstellung wechseln Zur Baum-Darstellung wechseln

15.11.10, 16:14	#4 (permalink)
Vyger Registriert seit: 04.12.03 Likes: 11	Mich würden mögliche Gegenmaßnahmen interessieren, vielleicht direkt am obigen Beispiel.

16.11.10, 00:44	#9 (permalink)
Inliferty Registriert seit: 05.10.05 Likes: 5	Weil ich das Schlagwort nochnicht gehört habe werfe ich einfach mal prepared Statements in den Raum http://de.wikipedia.org/wiki/Prepared_Statement Dabei werden die Daten als _DATEN_ interpretiert und haben nichts mit dem SQL-Statement zu tun. Für PHP gibts dazu eine schöne Klasse(PDO): http://php.net/manual/de/pdo.prepared-statements.php MfG Inliferty

[HaBo]

SQL Injections