En wat heb je zelf gemaakt?

Heb je voorbeeldcode die jij geschreven hebt?

BTW: de racegame is gewoon van CodeCanyon..

Ok laat maar :').

Zou bovenstaande code (met name de database queries) niet in een transactie moeten staan? Wat als iemand meerdere keren tegelijkertijd (parallel) een coinflip doet?

Hoe zit het met escaping in zowel HTML als SQL?

En kun je $flipJ niet gewoon als HTML retourneren (waarom een json_encode)?

Nog veel belangrijker dan wat en hoe je iets programmeert zijn de keuzes waarom je iets op een bepaalde manier programmeert.

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.

Wat heeft het strippen van tags met sql-injection te maken?

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:

$bedrag = mysqli_real_escape_string($_POST['bedrag']);


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).

$q = "INSERT INTO `log_useragent` (`username`,`data`,`date`) VALUES (:username, :logData, NOW())";
$st = $db->prepare($q);
$st->bindValue(':username', $_SESSION['user']['username'], PDO::PARAM_STR);
$st->bindValue(':logData', $logData, PDO::PARAM_STR);
$start = $st->execute();

FangorN legt goed uit waarom men dit doet.

Citaat van darkshifty

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.

Citaat van dmeigenaar

# 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.

Ik heb wel eens gezien dat iemand ook een blacklist had van 'forbidden words' voor in een SQL-query. Eén daarvan was WHERE.

Toen bleek dat station Purmerend Overwhere opeens niet geaccepteerd werd..

Zolang je alle delen die afkomstig zijn van een externe bron (de DATA delen in je SQL) op de juiste manier escaped dan is het onmogelijk om de werking van de query te veranderen. Hier hoef je dus helemaal geen ingewikkelde constructies voor te maken. Wanneer je met MySQLi werkt vergt het enkel wat discipline en als je van PDO gebruik maakt dan gebruik je als het goed is / ben je veroordeeld tot prepared statements. Ook daar geldt dat als je dit op de wijze toepast zoals het bedoeld is er eigenlijk niets mis kan gaan.

Neemt niet weg dat je altijd waakzaam moet zijn en je je altijd af moet vragen:
- in welke context je zit
- waar de data vandaan komt
- of er een speciale reden is om niet te escapen (in wat voor context dan ook), en dit anders wel te doen

Tuurlijk. Spreekt voor sich dat ik hem toen aanbevolen om mysqli_real_escape_string() te gebruiken. Nadat ik zag dat de rest in zijn query wel prima was.

Niet zozeer of uitsluitend uit voorzorg, maar meer om je werkwijze te simplificeren en te standaardiseren. Het is gewoon veel makkelijker om alles gewoon consequent te escapen, tenzij je een speciale (en gedocumenteerde) reden hebt om dit niet te doen.

Zoals eerder aangegeven, als je dit niet overal doet dan kan elke keer de vraag rijzen of je bewust niet ge-escaped hebt of dit per ongeluk vergeten bent. Je zou hier dan elke keer over na moeten denken en jouw code moeten herinspecteren. Ain't nobody got time for that.

Dit creëert ook een groter bewustzijn. Eigenlijk zou je je te allen tijde moeten afvragen als je met DATA uit een externe bron werkt of deze ge-escaped moet worden. Een externe bron kan ook jouw database zijn, deze bevat namelijk (indirect) ook USER DATA. Een goede instelling is om deze nooit te vertrouwen. Zelfs niet als deze in je database zit.

Het is echter niet de bedoeling dat je op voorhand alles voor een bepaalde context escaped waar je deze DATA niet direct voor gebruikt. Zo is het niet verstandig om bijvoorbeeld htmlentities() over tekst heen te gooien als deze de database in gaat omdat je die op den duur mogelijk gebruikt/weergeeft in een HTML-context. Vermijd het escapen van input, het (bredere) devies is nog steeds

filter input, escape output

Met de nadruk op output, oftewel, als je data in een bepaalde context gebruikt, dan is het zaak om te escapen. Je zou je in ieder geval altijd moeten afvragen of er ge-escaped moet worden en dit dan ook altijd doen, en zoniet, zou je een aantekening moeten maken die aangeeft waarom dat daar niet nodig of gewenst is.

Natuurlijk kun je de behandeling van DATA wel wat versoepelen op het moment dat geregistreerde gebruikers deze invoeren omdat je dan al iets beter weet wie deze personen zijn, maar dit zou nooit mogen resulteren in het zomaar accepteren van wat voor data dan ook of het blindelings verwerken hiervan, dit zou nog steeds aan alle (veiligheids)regels moeten voldoen. Je zult die data nog altijd valideren (filter input) en escapen in queries (escape output).

Citaat van dmeigenaar

Ik heb tot dus verre niet in enkele query mysqli_real_escape_string() staan.
Enkel bij queries die wat toevoegen zoals $_POST bijvoorbeeld.

Is het dan verstandig om uit voorzorg mysqli_real_escape_string() bij elke query toe te voegen?

Alleen als je de waarde kan manipuleren, zoals bij $_POST, $_GET, $_COOKIE, $_SESSION, $_SERVER en $_ENV. De laatste twee zijn wat lastiger, maar het zou in de praktijk kunnen.