Skript Sicherheit

[splasch]

@igäl

Klar kanst du über Get alles übergeben was du möchtest. Da es nun mal um die Sicherheit geht ist es einfach naiv Buchstaben zu verwenden wenn es auch mit Zahlen geht. Sql injecten ist mit nur rein Zahlen nicht möglich daher schon um einiges Sicher.

Das die Datenbank an beläuft. Ist das so das im normal fall autoincrement verwendet wird.Und der trägt bekantlich nur zahlen ein.Daher spricht man auch die Datensätze mit der autoincrement erstellten zahl an.

Nur ein Db neuling würde ohne autoincrement feld arbeiten! Was früher oder später dann sicher in einen Datenbank-kaos sich ausweitet.

Nachtrag:
Natürlich kann man auch trennzeichen verwenden wie # oder | siehe meine Hp.
Dann mußte aber voher die Get werte ein wenig filtern im falle mit Trennzeichen.
Explode befehl und dann die einzel werte auf integer setzen.Dann haste auch wiederum nur reihne zahlen werte. Je nach was eben erwartet wird kanst du genauso float verwenden.
Aber wenn man von der Db ausgeht dann sind im autoincremt feld nur ganze zahlen möglich.

Mfg Splasch

 

[Igäl]

Klar kanst du über Get alles übergeben was du möchtest. Da es nun mal um die Sicherheit geht ist es einfach naiv Buchstaben zu verwenden wenn es auch mit Zahlen geht. Sql injecten ist mit nur rein Zahlen nicht möglich daher schon um einiges Sicher.

Naiv ist es, keine Werteüberprüfung zu machen und zu hoffen, dass keine "bösen" Eingaben gemacht werden. Aber warum sollten keine Strings übergeben werden? Es ist alles eine Frage der Validierung. Auch Parameter wo du blosse Zahlen erwartest, musst du (zumindest auf is_number) überprüfen.
Ich benutze beispielsweise für meine Modulverwaltung einen Übergabeparameter "action" an welchen die ID des Modules angehängt wird. Im Script selber wird dieser Parameter mit einer Whitelist (in diesem Falle ein Switch) abgeglichen. Das ist natürlich etwas mehr Aufwand, hat in meinem Fall aber kaum Einfluss auf die Performance und steigert die Lesbarkeit enorm. Es gibt halt gewisse Tradeoffs, denen man ich als Entwickler stellen muss.

Das die Datenbank an beläuft. Ist das so das im normal fall autoincrement verwendet wird.Und der trägt bekantlich nur zahlen ein.Daher spricht man auch die Datensätze mit der autoincrement erstellten zahl an.

Natürlich spricht nichts gegen auto_increment-Spalten, wenn sie gebraucht werden.

Nur ein Db neuling würde ohne autoincrement feld arbeiten! Was früher oder später dann sicher in einen Datenbank-kaos sich ausweitet.

Ich frage mich noch immer, auf welchen Daten du diese Behauptung abstützt. Wenn ich doch weiss, dass meine Liste von Modulen in der Datenbank nur endlich ist, brauch ich doch kein auto_increment Feld. Es ist doch alles eine Frage des Bedarfs und nicht, wie gut man sich auskennt. Wenns unausweichlich wäre, dass man mit auto_increment-Feldern arbeitet, wäre das doch mittlerweile Standard. Dann könnte man gar keine Tabellen mehr ohne die ID-Spalte machen

Nachtrag:
Natürlich kann man auch trennzeichen verwenden wie # oder | siehe meine Hp.
Dann mußte aber voher die Get werte ein wenig filtern im falle mit Trennzeichen.
Explode befehl und dann die einzel werte auf integer setzen.Dann haste auch wiederum nur reihne zahlen werte. Je nach was eben erwartet wird kanst du genauso float verwenden.

Warum sollte ich das tun? Es reicht doch, wenn ich den String einfach maskiere. Im Normalfall wird sowieso kein "böser" Code ankommen und wenn doch, dann wird er durch die Validation gefilter. Beim Beispiel von ID's wie #511.212 kannst du doch zum Beispiel mit substr() die ersten 8 Zeichen des Übergabeparameters auslesen und die dann durch die eigentliche Validation laufen lassen (Versuch mal Injection-Code in 8 Zeichen unterzubringen ). Man könnte auch mit regulären Ausdrücken prüfen, ob die Zeichenfolge den Vorstellungen entspricht oder man maskiert den Code mit mysql_real_escape_string oder ähnlichen Funktionen. Die Validation von Strings ist halt etwas umfangreicher als diejenige von reinen Zahlenwerten. Was aber nicht heisst, dass man es nicht machen soll, nur weil es mehr Arbeit gibt Und ich wehre mich entschieden gegen die Behauptung, dass es ein Zeichen von programmtechnischer Ahnungslosigkeit ist, wenn man mit ID's arbeitet, die nur aus den Zeichen 0 - 9 bestehen

Bald mal Mahlzeit
Dä Igäl

 

[splasch]

Ich will mit dir nicht streiten du kanst das so handhaben wie du willst. Wie sicher das ganze dann ist immer eine andere Frage.

Auch Parameter wo du blosse Zahlen erwartest, musst du (zumindest auf is_number) überprüfen.

Stimmt nicht ganz wenn man den Datentyp der Varible zu weißt also in dem Fall integer dann wird aus einen string eine 0
Bsp $Variable="irgendwas":
echo (integer)$Variable; ergibt 0

Mit (int)Variable erfolgte die Umwandlung vom Datentype string zum Datentype integer.Daraus ergibst das aus irgendwas dann 0 wird weils kein integer wert ist.

Du kanst auch den befehl settype verwenden kommt auf gleich raus das andere ist nur eine kurz schreibweise

Mfg Splasch

 

[schleckerbeck]

Ich freu mich ja, dass ich eine solch rege Diskussion angeregt hab, fangt aber bitte nicht zum streiten an.


Ich muss Igäl recht geben, dass man für ID's ohne Umstände auch alphanumerische Zeichen (in welcher Struktur auch immer) verwenden kann. Für mich persönlich hat sich aber die Arbeit mit ID's die nur aus Nummern bestehen bewährt. auto_increment ist ne feine Sache! Alles andere Funktioniert natürlich auch.
Warum soll man nicht als ID für seine Modul oder Komponenten Liste Werte wie mod_guestbook und für sein Gästebuch ID'S per auto_increment verwenden? Kommt halt ganz auf die Verwendung an.

In diesem Sinne,
sc.

 

[schleckerbeck]

Also hab mir das ganze jetzt noch ein wenig genauer angeschaut.
Ich übergebe meiner DB Klasse den SQL Befehl im "ganzen", also $db->select("Select * from test where name='".$_GET['name']."'");.
Der SQL Befehl kommt nun in der function select als Variable $arg an.

function select($arg) {
        $sql=mysql_query($arg);
        while($select=mysql_fetch_assoc($sql))
        {
            $s[] = (object) $select;
        }
        return $s;
    }

Wie filtere und validier ich jetzt das SQL Statement in der Variablen $arg so, dass nichts eingeschleust werden kann, bzw. irgenwas anderes 'böses' passiert?
Gibt's irgend eine Stringfunktion, dass mir den Teil zwischen den ' ' bei name='".$_GET['name']."' rausfiltert, sodass ich das ganze per mysql_real_escape_string (oder etwas anderes, Idee?) prüfen kann?

Danke,
sc.

 

[schleckerbeck]

Keiner ne Idee?
Irgendwie find ich das ganze ein wenig verwirrend...

 

[splasch]

Frag doch Igäl der wird dir das sicher sagen!

Mfg Splasch

 

[schleckerbeck]

Wär natürlich schon super, wenn er ne Lösung hätte.
@splasch: evtl. hast ja du noch nen Ansatz.

sc.