#1 30. März 2007 Zuletzt von einem Moderator bearbeitet: 15. April 2017 Typecasting für HTML - Formulardaten Guten Abend, da in diesem Thread hier PHP: String nur aus Zahlen ? Preg_match ? - RR : Board [/ URL ] davon ausgegangen wurde , dass is_numeric effektiv gegen SQL Injections hilft , hab ich diesen Thread geöffnet . Denn es ist nicht so , dass is_numeric dafür sorgen kann , dass eure Queries zerstört werden . Über Codierung , Rechenzeichen etc . kann is_numeric "geknackt" werden . Anbei möchte ich euch meine Methode vorstellen , typensichere formulardaten zu erhalten . [ PHP ] function InputTo ( $type , $value ) { switch ( $type ) { //switch tree for the var type case 'string' : //stringarm if( get_magic_quotes_runtime () == true || get_magic_quotes_gpc () == true ) { $value = stripcslashes ( $value );} //Bei magic quotes $value = htmlspecialchars ( strip_tags ( trim ( $value )), ENT_QUOTES ); //Sonderzeichen URI kompatibel kodieren return $value ; //end - stringarm case 'integer' : //integer arm $newValue = (int) $value ; if ((string) $newValue !== $value ) { die( 'Es wurde eine Parametermanipulation festgestellt.' ); } else { return $newValue ; //end - integer arm } case 'bool' : //boolean arm $newValue = (bool) $value ; if((string) $newValue !== $value ) { die( 'Es wurde eine Parametermanipulation festgestellt.' ); } else { return $newValue ; //end - boolean arm } } //end - switch tree for the var type } //end - function InputTo($type, $value) + Multi-Zitat Zitieren
#2 2. April 2007 AW: Typecasting für HTML - Formulardaten @MakenX du hast glaube ich ich ein = zuviel in deiner if abfrage ( !== anstatt != ) schüzt das hier nicht gegen sql-injektion, und gleichzeitig noch type überprüft: Code: $query = sprintf("SELECT * FROM `__ka_` WHERE `__ka_` = '%s' and `__ka_` = '%s'", mysql_real_escape_string(__deine_var___), mysql_real_escape_string(__deine_var___)); % - ein Prozent-Zeichen ("%"). Es ist kein Argument erforderlich. b - das Argument wird als Integer angesehen und als Binär-Wert ausgegeben. c - das Argument wird als Integer angesehen und das entsprechende ASCII-Zeichen wird ausgegeben. d - das Argument wird als Integer angesehen und ein Dezimalwert (signed) ausgegeben. u - das Argument wird als Integer angesehen und ein Dezimalwert (unsigned) ausgegeben. f - das Argument wird als float angesehen und eine Fließkomma-Zahl ausgegeben. o - das Argument wird als Integer angesehen und und als Oktalzahl ausgegeben. s - das Argument wird als String angesehen und auch als solcher ausgegeben. x - das Argument wird als Integer angesehen und als Hexadezimal-Wert ausgegeben (mit Kleinbuchstaben). X - das Argument wird als Integer angesehen und als Hexadezimal-Wert ausgegeben (mit Großbuchstaben). + Multi-Zitat Zitieren
#3 2. April 2007 AW: Typecasting für HTML - Formulardaten Nein ich hab kein Gleichheitszeichen zu viel. Wir gehen davon aus, dass jede Forumularvariable ein String ist und ich überprüfe mit dem zusätzlichen gleichheitszeichen nach wert UND typ....eine Funktion global z.B. anzuwenden, ist sinnvoller als jeden Query seperat anzupassen und format strings zu benutzen .... Den Rest was du schriebst kann ich noch weniger nachvollziehen, ist für mich auch kein Sinnvoller SQL Query ... Ach jetzt seh ich erst was du meinst, jo, aber ist doch recht unpraktikabel besonders weil du dann den String noch mit mysql_real_escape string wrapst! und was ist wenn du z.B. kein mysql benutzen willst? Benutze doch auch nächstes mal bitte das eingebaute Highlighting! + Multi-Zitat Zitieren
#4 2. April 2007 AW: Typecasting für HTML - Formulardaten Das mit dem if ist ok. Das setzt zur Gueltigkeit des ifs noch den gleichen Typ der Variablen vorraus. + Multi-Zitat Zitieren
#5 2. April 2007 AW: Typecasting für HTML - Formulardaten jo,gut erstmal danke wegen den !==, habe ich nicht gewusst :] 2. kannst ja auch so etwas schreiben: PHP: $mein_int = sprintf ( "%b" , (int) $var_int ); wobei grundsätzlich ich nur auf die SQL Injections ansprechen wollte. trotzdem ist es fein, wenn man eine funktion hat die alles mact, klar !!! + Multi-Zitat Zitieren
#7 2. April 2007 AW: Typecasting für HTML - Formulardaten Gegen SQL Injections hat mir bisher immer diese Funktion geholfen. (Nein, kommt nich von mir, hab ich mal irgendwo gefunden aber ich find sie ganz hilfreich... ) PHP: <? php function Query ( $query ){ $args = func_get_args (); $vargs =array(); for( $i = 1 ; $i < func_num_args (); $i ++) { if( get_magic_quotes_gpc ()) { $args [ $i ]= stripslashes ( $args [ $i ]); } $vargs []= mysql_real_escape_string ( $args [ $i ]); } $query = vsprintf ( $query , $vargs ); $res = mysql_query ( $query ); return( $res ); } ?> Aufruf ála: PHP: Query ( "SELECT ID FROM `my_table` WHERE Name = '%s' OR Alter = %d" , 'Peter' , 4 ); Ist ziemlich übersichtlich und hilfreich... Viel Spaß damit. + Multi-Zitat Zitieren
#8 2. April 2007 AW: Typecasting für HTML - Formulardaten rofl, hast recht, wollts aber nur mal zeigen @ Telefonzelle die funktion teste ich gleich mal ^^ :tongue: + Multi-Zitat Zitieren
#9 2. April 2007 AW: Typecasting für HTML - Formulardaten Also tut mir leid, ich halte eure Methoden nicht für die sinnvollsten. Denn entweder man muss sich um jeden Query seperat kümmern und/oder die Auswirkungen sind nur lokal auf die Funktion begrenzt. Bei meiner Methode, kann man das auf komplette Scripte anwenden, zum Beispiel in einem Framework, man kann im kompletten Script typensicher programmieren, es sind für die eigentlich umwandlung deutlich weniger Funktionsaufrufe notwendig, und es wird überprüft ob der geänderte Wert dem ursprünglichen entspricht ... das was ihr zwei gepostet habt, ist ein rückschritt in Performance, Ressourcenschonung, Abstraktion und Kapselung und würde für mich nicht reichen. Natürlich muss man bei mir im weiteren Verlauf des Scripts darauf achten, seine eigenen Typen nicht wieder kaputt zu machen, aber wer sich selbst Injections baut ist selber schuld ... + Multi-Zitat Zitieren