PDO gigatische error

    This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

    • FangorN wrote:

      MiCa- wrote:

      Het is veilig zolang je weet wat je doet..
      Mja, als de maan van kaas is ben ik Napoleon.
      Met andere woorden: als je uitgangsstelling niet klopt kun je zeggen wat je wilt (false => true).

      Getuige bovenstaande code van @ruttydm, die zo lek is als maar kan zijn.
      als het niet klopt genereer je een default of een error message om de gebruiker er op te wijzen..
      Tenslotte is het de programmeur die bepaald wat de code moet doen en niet de gebruiker, daarmee moet de programmeur altijd rekening houden.

      Het is zeker niet verkeerd om ALTIJD je query input te gaan binden, maar het is ook gewoon niet altijd nodig, gebruikers input zonder enige validatie moet gewoon altijd gebind worden om inderdaad injectie tegen te gaan.
      Web developer

      The post was edited 3 times, last by MiCa- ().

    • MiCa- wrote:


      Tenslotte is het de programmeur die bepaald wat de code moet doen en niet de gebruiker, daarmee moet de programmeur altijd rekening houden.
      Helaas is het tegenwoordig meer de gebruiker die bepaald hoe een product gebruikt wordt dan andersom. Als programmeur moet je daarom input van gebruikers nooit, maar dan ook nooit vertrouwen!

      Verder ben ik het compleet met je opmerking eens MiCa-!
      Opzoek naar een hoster die echt met je meedenkt? - Puurhost.nl Webhosting

    • Ik heb het gefixt, ik hzb gebruik gemaakt van whitelists en deze code:

      PHP Source Code

      1. <?php
      4. $result = $db->prepare("SELECT * FROM faucets ORDER BY ".$sorton." ".$order."");
      5. $result->execute();
      6. $nr=0;
      7. while ($row = $result->fetch(PDO::FETCH_ASSOC))
      8. {
      9. $nr = $nr + 1;
      10. echo "<tr>
      11. <td>".$nr."</td>
      12. <td><a href='".$row['faucet_url']."'>".$row['faucet_name']."</a></td>
      13. <td>".$row['average_reward']."</td>
      14. <td>".$row['reward_hour']."</td>
      15. <td>".$row['wait_time']."</td>
      16. <td>".$row['payement']."</td>
      17. </tr>";
      18. }
      22. ?>
      Display All

    • MiCa- wrote:

      Het is zeker niet verkeerd om ALTIJD je query input te gaan binden, maar het is ook gewoon niet altijd nodig, gebruikers input zonder enige validatie moet gewoon altijd gebind worden om inderdaad injectie tegen te gaan.
      Sterker nog, het *kan* niet altijd, en dat is hier juist het probleem. Zoveel stond al in mijn eerste reactie.

      Vervolgens begint de discussie een beetje te vervagen met wat de rol van een programmeur en een gebruiker zou zijn. Ik heb sinds mijn eerste reactie eigenlijk geen nieuwe relevante informatie ten aanzien van dit topic de revue zien passeren.

      De topicstarter moet gewoon alle input die niet via prepared statements verloopt filteren, te meer omdat deze rechtstreeks uit $_GET lijkt te komen.

      Hoe je vervolgens fouten afvangt (of je nu een foutmelding produceert -wat niet erg gebruiksvriendelijk is- of terugvalt op een default waarde) is uitwerking / zijn details, en heeft ook weinig van doen met het oorspronkelijke probleem. Het oorspronkelijke probleem was dat de topicstarter iets probeerde te binden wat niet gebind kon worden. Vervolgens geef ik aan:

      - dat / waarom dit niet altijd kan
      - hoe je dit dan wel doet
      - en waar je daarbij op moet letten

      Volgens mij kun je geen vollediger antwoord dan dat geven, behalve misschien dat je ook de complete oplossing uitschrijft. Maar als je dat (in dit eenvoudige geval) niet zelf kunt, dan zou je deze tak van sport niet moeten bedrijven.

      @ruttydm uit jouw code kan niet opgemaakt worden hoe $sorton en $order "veilig gemaakt" zijn.