Warum dabei mit Sprintf() formartieren?

Einklappen
X
 
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

  • Warum dabei mit Sprintf() formartieren?

    Hallo zusammen

    Ich hab im Netzt die Folgende Funktion gefunden die vor MySQL Injections schützen soll.

    PHP-Code:
    function db_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);
      }

    BspAbfrage
      
    db_query('SELECT * FROM %s WHERE `%s`=%d','user','id',123456); 
    Was ich dabei nicht verstehe ist, warum die Query unbedingt mit sprintf() Formartiert werden muss obwohl das eintragen in die DB auch ohne diese Formartierung geht und warum das erst ab dem 2. Parameter vor SLQ Injections schützen soll?

    Mit dem sprintf() wird das zwar als String (reiner Text bei %s) bzw. Integer (bei %d) angesehen jedoch wird das was in $query da ankommt ja mit ysql_real_escape_string schon alles Maskiert. Deswegen versteh ich nicht warum unbedingt nochmal das Formartieren mit sprintf() notwendig sein soll.

    Kann mir das bitte einer erklären?
    Zuletzt geändert von marcaust; 27.11.2006, 20:21.

  • #2
    Hast du mal nachvollzogen was die funktion macht?

    das sprintf dient nicht als schutz, sondern ist lediglich dafür da, die werte (optinale parameter) an die entsprechenden stellen in der query zu setzen.

    Kommentar


    • #3
      Darüber hinaus sorgt es dafür, dass der Input auch vom erwarteten Typ ist (string, integer, etc.). Selbiges ließe sich natürlich auch mit (string), (int), strval() oder intval() erreichen, ich persönlich finde (v)sprintf da auch "komfortabler".
      Nieder mit der Camel Case-Konvention

      Kommentar


      • #4
        wobei ich ganz ehrlich ein bisschen an der übersicht der query zweifel...

        Kommentar


        • #5
          Bei kleinen Abfragen und ordentlichem Einrücken eigentlich kein Problem, bei großen Abfragen kann die Übersicht durchaus leiden, das stimmt. Da muss man sich halt Alternativen warm halten.
          Nieder mit der Camel Case-Konvention

          Kommentar


          • #6
            Original geschrieben von TobiaZ
            Hast du mal nachvollzogen was die funktion macht?

            das sprintf dient nicht als schutz, sondern ist lediglich dafür da, die werte (optinale parameter) an die entsprechenden stellen in der query zu setzen.
            Zumindest versuch ich das zu verstehen.

            Was mir bisher nicht in den Kopf will ist, das diese Formatierung mit sprintf() sein MUSS obwohl z.bsp.: ein
            dbquery("SELECT * FROM tabelle WHERE user='$_POST[userid]'");
            ebenfalls Funktioniert. (Was ich persönlich bisher übersichtlicher finde).

            Daher die Überlegung halt das für mich übersichtlichere zu verwenden zumal ich schon am Anfang vom Script prüfe ob z.Bsp.: $_Post[userid] nur zahlen enthält und somit auch gleich noch vermeide das mir da noch anderer PHP Code ausgeführt wird der gar nicht vorgesehen ist.

            Von daher sehe ich derzeit keine Vorteile darin nochmal zusätzlich sicher zu stellen ob eine Variable vom erwarteten Datentyp ist oder nicht.

            Da beide Methoden Funktionieren müsten doch beide wege (also mit und ohne sciherstellung des Datentyps mit sprintf bei der Query) sicher sein.
            Oder seh ich da etwas falsch?

            Kommentar


            • #7
              wie du es machst, ist ja latte. hauptsache du stellst sicher, dass die daten auch die sind, die du erwartest.

              Kommentar

              Lädt...
              X