Scripter aangeboden

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

    • De code hierboven kwam enkel uit een stukje kop of munt code. Dmv een stukje json script code herlaadt die het uitvoer stukje uit een ander script. HTML en opmaak wordt in een ander script in opgemaakt.

      Met escaping van SQL bedoel je dit neem ik aan:

      Connect::query("UPDATE `gebruikers` SET `silver`=`silver`+'".$bedrag."' WHERE `user_id`='".$_SESSION['id']."'");

      Met escaping moet het dit zijn:

      Connect::query("UPDATE `gebruikers` SET `score`=`score`+''".$score."'' WHERE `user_id`=''".$_SESSION[''id'']."''");
    • Nee, met escaping bedoel ik meer het ontdoen van enige speciale betekenis van tekstpassages in een bepaalde context.

      Escaping is belangrijk om zaken als SQL-injectie tegen te gaan. Het beste lijkt mij gewoon om dit altijd consequent te doen, ook al is het soms niet direct nodig. Het voordeel hiervan is dat je DATA in queries altijd hetzelfde behandelt, en je je dus ook niet elke keer hoeft af te vragen of een passage bewust niet was ge-escaped, of toch per ongeluk was vergeten.
    • Voor het escapen van SQL queries, had ik laatst dit gemaakt.

      PHP Source Code

      1. <?php
      2. # Anti SQLi (SQL Injection)
      3. $array = array(
      4. "union",
      5. "sql",
      6. "mysql",
      7. "database",
      8. "cookie",
      9. "coockie",
      10. "select",
      11. "from",
      12. "where",
      13. "benchmark",
      14. "concat",
      15. "table",
      16. "into",
      17. "by",
      18. "values",
      19. "exec",
      20. "shell",
      21. "truncate",
      22. "wget",
      23. "/**/",
      24. "1=1",
      25. "xss"
      26. );
      27. foreach ($array as $d) {
      28. $string = security($_SERVER['QUERY_STRING']);
      29. if (strpos(strtolower($string), $d) !== false) {
      30. $ip = $_SERVER['REMOTE_ADDR'];
      31. $loc = $_SERVER['PHP_SELF'];
      32. $browseros = $_SERVER['HTTP_USER_AGENT'];
      33. $oslanguage = $_SERVER['HTTP_ACCEPT_LANGUAGE'];
      34. $date = date("d.m.Y / H:i:s");
      35. $file = security(''.$loc.'?'.$string.'');
      36. echo '<meta http-equiv="refresh" content="0;url=index.php" />';
      37. exit();
      38. }
      39. }
      40. # Anti XSS (Cross-site scripting)
      41. function security($input) {
      42. global $db;
      43. $input = $db->real_escape_string($input);
      44. $input = strip_tags($input);
      45. return $input;
      46. }
      Display All

      En dan bij belangrijke momenten: security($_POST['login']) <-- Bij wijze van.
    • dmeigenaar's insteek is prima, zijn kennis is alleen nog niet optimaal. Dat is ook niet iets wat hij ontkent. Hij bied zich aan als "Scripter" en niet als Programmeur.

      De kritiek en met name niet echt opbouwend, vind ik op ICTScripters regelmatig slecht en onbehoorlijk.

      dmeigenaar, je aanbod is prima. Het voldeed voor mijn behoefte destijds.
      Je code is inderdaad niet optimaal maar daar hebben je oplossingen als Udemy voor.
      Mijn advies is, volg eens een cursus, start eens een Codeignigter of Laravel project daar leer je enorm van (en ook snel!).

      Wat betreft escapen van data gaat als volgt op de msqli manier:

      PHP Source Code

      1. $bedrag = mysqli_real_escape_string($_POST['bedrag']);
      2. Connect::query("UPDATE `gebruikers` SET `silver`=`silver`+'".$bedrag."' WHERE `user_id`='".$_SESSION['id']."'");
      Persoonlijk zou ik hem dan ook nog als int casten.

      Ik zelf werk niet met MySQLi, simpelweg omdat ik persoonlijk PDO effectiever vind. Je hebt er meer functionaliteit in om waardes te definiëren (b.v. bindParam/bindValue).


      PHP Source Code

      1. $q = "INSERT INTO `log_useragent` (`username`,`data`,`date`) VALUES (:username, :logData, NOW())";
      2. $st = $db->prepare($q);
      3. $st->bindValue(':username', $_SESSION['user']['username'], PDO::PARAM_STR);
      4. $st->bindValue(':logData', $logData, PDO::PARAM_STR);
      5. $start = $st->execute();
      FangorN legt goed uit waarom men dit doet.
    • darkshifty wrote:

      Persoonlijk zou ik hem dan ook nog als int casten.
      Dat heeft niet zoveel zin. Als de data afkomstig is van een externe bron is het beter om de waarde gewoon te valideren. Voldoet deze niet aan het formaat dan gewoon afkeuren / programma staken. Een typecast probeert vaak recht te buigen wat al krom is. In het gunstigste geval levert dit dan een query op die weliswaar syntactisch correct is, maar semantisch nog steeds onzinnig is.

      Neem bijvoorbeeld code.php?id=aap en je verwacht dat $_GET['id'] een getal bevat (vaak een auto increment id). Een typecast van "aap" levert je dan het cijfer 0 op. Een query met die informatie levert dan nog steeds niet het gewenste resultaat op. Valideren is bijna in alle situaties beter.

      Het geven van typehints is dan wel leuk enzo, maar tenzij je PDO::ATTR_EMULATE_PREPARES uitzet wordt volgens mij niet van het zogenaamde binary protocol gebruik gemaakt in communicatie met je (MySQL) database. Dit had dacht ik tot gevolg dat alles gewoon als string wordt behandeld en dan zijn die typehints dus nogal loos.


      dmeigenaar wrote:

      # Anti SQLi (SQL Injection)
      Vervolgens wordt een array van verboden waardes gegeven. Realiseer je je goed dat dit een blacklist is. Het nadeel van blacklists m.b.t. securityzaken is dat als je een case vergeet dat daarmee je beveiliging effectief om zeep is. Het is beter om te definiëren wat wel toegestaan is in plaats van wat niet toegestaan is.

      Overigens is het gebruik van real_escape_string() alleen veilig in combinatie met quotes, het een is niet veilig zonder het ander. Ook dienen alle character encoderingen in de pas te lopen want escaping-functionaliteit is hier zwaar van afhankelijk.