Ik maak heel mijn leven al gebruik van PHP maar ik heb er nooit voor geleerd en ben dit ook niet van plan aangezien het voor mij altijd een "bijproduct" is.
Ik ontwikkel namelijk applicaties voor Android en iOS. Ik gebruik dus PHP om gegevens in een database te zetten en te lezen.
Nu maak ik dus gebruik van de lelijke $_GET functie aangezien mijn app op deze manier gegevens kan verwerken en ontvangen.
Ik gebruik dit bijvoorbeeld om een comment system in mijn app te bouwen. Nu wil ik natuurlijk wel dat er geen misbruik van gemaakt kan worden. Daarom wil ik even voor de zekerheid checken of mijn code veilig voor gebruik is.
Dat zou ik heel graag doen maar ik heb helaas die mogelijkheid niet. Ik maak gebruik van een soort drag & drop software en het word ge-export als HTML5 project. De software zelf heeft helaas geen functie om bijvoorbeeld een unieke check te doen.
Vanuit mijn software worden de php scripts aangeroepen door een AJAX request.
Verder is de code dus wel veilig voor SQL injection e.d.?
Hoe is dat een juist gebruik van prepared statements? Je injecteert rauwe, niet ge-escapete waarden in je statement, in plaats van deze te assignen via placeholders. Het netto effect van je bind_param() aanroepen is nul komma nul.
Nu kun je met deze query wellicht niet zoveel ongein uithalen (maar de vindingrijkheid van hackers is waarschijnlijk vele malen groter dan die van mij) maar ik vrees met grote vreze als de rest van je applicatie op dezelfde wijze omgaat met "prepared statements". Dit is in ieder geval niet de juiste manier.
Bonus ending: waar selecteer je de te gebruiken character encoding bij het maken van een connectie?
Hoe is dat een juist gebruik van prepared statements? Je injecteert rauwe, niet ge-escapete waarden in je statement, in plaats van deze te assignen via placeholders. Het netto effect van je bind_param() aanroepen is nul komma nul.
Nu kun je met deze query wellicht niet zoveel ongein uithalen (maar de vindingrijkheid van hackers is waarschijnlijk vele malen groter dan die van mij) maar ik vrees met grote vreze als de rest van je applicatie op dezelfde wijze omgaat met "prepared statements". Dit is in ieder geval niet de juiste manier.
Bonus ending: waar selecteer je de te gebruiken character encoding bij het maken van een connectie?
Deze site is een hel op de mobiel, en zag alleen de bind_param() staan, ging er vanuit dat het dan wel goed was.
Dat is tevens ook de reden dat ik hier kom. Zoals ik al aangeef, ik heb hier allemaal geen verstand van maar ik ben genoodzaakt gebruik te maken van PHP om mijn doel te bereiken binnen mijn app.
Kortom, geen idee of de code goed is ja of nee.
Ik weet alleen dat de code goed werkt, maar ik weet ook dat er 100den manieren zijn en ik er altijd langs pis.
Ik kan trouwens gebruik maken van txt bestanden. Dit zal wel altijd hetzelfde bestand zijn.
Ben ik ook wel benieuwd naar, ik doe obj-C met xCode voor iOS en ik kan gewoon json requests doen en daar een agent aan koppelen. (wel basic om te kijken of het van m'n app komt, maar toch)
Ik gebruik Construct 2 voor mijn apps. Ik ben helaas niet geboren om te programmeren en ik ben de juiste doelgroep voor software zoals dat. Drag en drop maar toch de vrijheid om het zo gek te maken als je maar wil.
Momenteel ben ik bezig met een app waar op het moment een Facebook login in zit, vervolgens ( nu dus veilig ) de gebruiker in een database zet met een Facebookid, waarmee ik dus ook de profielfoto kan gebruiken en de echte naam van de gebruiker. Vervolgens zit er een soort live feed in die dagelijks geupdate kan worden in een backend. Een comment system, een like system en noem maar op.
Alles werkt perfect maar ik wil het natuurlijk wel veilig maken. Ik ben al zo'n "Ach dat komt vast wel goed" persoon maar ik heb weinig zin in een scriptkiddie die straks heel mijn app naar de klote maakt door bijv. een klein stukje code als comment te posten waardoor heel de database op z'n kop gaat.
Je nieuwe script komt in de buurt, maar waarom prepare je de rest van je query ook niet gewoon? Dus ook de random code. Daarnaast: zie regels 23 t/m 26. De volgorde is raar, kan niet werken, en je maakt onnodig variabelen aan.