Scripter aangeboden

  • Beste leden,


    Aangezien ik de komende tijd weer aardig wat tijd vrij hebt bied ik mijzelf als scripter aan met een vast tarief van €7,50 per uur. Projecten zijn ook welkom met een vaste prijs en / of een project met een deadline.


    Programmeertalen die ik beheer:
    - PHP
    - HTML / HTML5
    - CSS / CSS3 / Bootstrap
    - Javascript (Klein beetje Ajax / jQuery)


    Hoeveel uur ik per week beschikbaar ben:
    - Dit verschilt per week, maar zeker wel 15 - 20 uur per week.


    Uitgevoerde werkzaamheden:
    - Criminals
    - Pokemon games
    - Aanmeldsystemen
    - Forumsystemen
    - Race games


    Projecten wat ik beheer (Zodat u enige beeld kan krijgen wat ik zo al bouw.):
    - pokemongym.nl
    - pokemonplasma.com
    - pokemoncity.nl
    - pokestad.nl
    - streetmaffia.com <-- Momenteel een race game op actief.


    Projecten waar ik aan gewerkt heb:
    - pokemonrpg.nl
    - pokeworld.nl


    Daarnaast al een aantal jaren actief in het updaten van een hele hoop sources (Maffia, Pokemon en MMORPG sources.).


    Ook bezit ik tientallen (Betaalde) maffia sources en nog andere betaalde sources. Interesse in een source, stuur maar gerust een privebericht. ;)


    Opdrachten mogen verstuurd worden per privebericht of mailen naar: [email protected]


    Hoop dat alles zo een beetje duidelijk vermeld is, zo niet? Laat het dan maar weten.


    Met vriendelijke groet,
    Damon

  • In principe zijn al mijn sites die ik atm beheer / bezit, helemaal herschreven dus heb ik het zelf gemaakt.


    Heb nog geen behoefte gehad aan nieuw design / uiterlijk.


    Enigste wat niet 100% zelf gemaakt is het layout, dat is tevens wel gecleant en beter gemaakt als eerst.

  • Ja dat heb ik.


    Is gewoon simpel geschreven Kop of Munt code.


    Racegame komt inderdaad van CodeCanynon af. Enkel heb ik het aanmeld / registreer systeem al helemaal herschreven en verbeterd.

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

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


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



    PHP
    $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.

  • Bedankt DarkShifty voor het duidelijk maken van het topic wat ik hier aangemaakt heb.


    Daarbij maak ik inderdaad gebruik van mysqli_real_escape_string, alleen in een function gebouwd.


    Zelf gebruik ik mysqli, maar kan ook overweg gaan met PDO.
    Alleen zelf zie ik nog niet echt een super groot voordeel om te switchen van mysqli naar PDO.

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



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

  • 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

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

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

Participate now!

Heb je nog geen account? Registreer je nu en word deel van onze community!