2 selectboxen
Prepared Statements of de $con->real_escape_string() functie gebruiken voor OO-gebruik met MySQLi. Bij gebruik van procedureel is het mysqli_real_escape_string($con, $string);.
De beveiliging doe je je in de query. Je kan gebruik maken van - Aar - op 13/09/2015 21:29:45:
SELECT dit, dat FROM dingen WHERE dit = '$_POST['name']'
Denk wel aan SQL-injection uiteraard, want iedereen kan een selectbox manipuleren.
Denk wel aan SQL-injection uiteraard, want iedereen kan een selectbox manipuleren.
Ik volg dit topic een beetje.
Ik lees dat je zegt dat het mogelijk is om een select box /dropdown menu te manipuleren mbv SQL injection.
Op welke manier gebeurt dat en is dat te voorkomen als je method="post" gebruikt?
http://stackoverflow.com/questions/22534183/do-i-have-to-guard-against-sql-injection-if-i-used-a-dropdown
Misschien handig als ervaren gebruikers nog eens een voorbeeld zouden maken over de beveiliging, zie hier een en ander met wat verouderde datum, tenzij ik iets mis.Zelf ben ik nog te onervaren voor een en ander.
Gewijzigd op 15/09/2015 16:06:39 door Pierre Web
user input altijd escapen.
Johan West op 15/09/2015 15:41:15:
Ik volg dit topic een beetje.
Ik lees dat je zegt dat het mogelijk is om een select box /dropdown menu te manipuleren mbv SQL injection.
Op welke manier gebeurt dat en is dat te voorkomen als je method="post" gebruikt?
- Aar - op 13/09/2015 21:29:45:
SELECT dit, dat FROM dingen WHERE dit = '$_POST['name']'
Denk wel aan SQL-injection uiteraard, want iedereen kan een selectbox manipuleren.
Denk wel aan SQL-injection uiteraard, want iedereen kan een selectbox manipuleren.
Ik volg dit topic een beetje.
Ik lees dat je zegt dat het mogelijk is om een select box /dropdown menu te manipuleren mbv SQL injection.
Op welke manier gebeurt dat en is dat te voorkomen als je method="post" gebruikt?
Je kan met de Element Inspector van je browser de opbouw van je HTML client-side aanpassen. Dus ook manipulerende strings toevoegen aan de POST en GET requests.
Randy Flujowa op 15/09/2015 16:18:32:
@johan, bekijk de link die hierboven staat, dan zie je dat het met post waardes ook gaat :)
user input altijd escapen.
user input altijd escapen.
En escapen is zoveel als .... ?
Escapen is zeer nuttig vanwege veiligheid. Stel je voor dat iemand met het aanpassen van je POST/GET/COOKIE waardes je query kan manipuleren. Dat heet SQL-injection.
Als je niet weet wat verschillende termen inhouden kan het verstandig zijn om even Google door te zoeken.
Heel simpel uitgelegd:
PHP is een "interpreted language", dit betekend dat het in per aanvraag text bestandjes omzet in machine taal wat jouw computer kan begrijpen. Je kan met dit soort systemen dingen misbruiken aangezien jouw code op dezelfde hoogte ligt als de gebruiker. Dus, eigenlijk zonder enige vorm van controle kan een gebruiker PHP code uitvoeren op jouw server via de gebruikers invoer van PHP; "$_COOKIE, $_GET, $_POST".
Dit kan je voorkomen om tekens te "escapen".
In PHP heb je de " en de ' om een string aan te duiden, als de gebruiker 1 van deze tekens gebruikt kan de gebruiker een string eindigen en zijn eigen code er aan toe voegen.
Als jij dit toelaat in een string die toegang heeft in jouw database geef je de gebruiker de mogelijkheid om ook daar zonder wachtwoord code uit te voeren. Dit word dan ook een SQL-injectie genoemd.
Het escapen is niets meer dan " en ' te vervangen door \" en \' zodat deze tekens "geescaped" worden zodat de PHP interpreter deze tekens (", ') niet interpreteert als een begin of eind van een string.
Het escapen gaat ook nog verder, bijvoorbeeld zoals forums het niet toestaan om < tekens te gebruiken maar (bb code net zoals hier) zodat jij als gebruiker geen HTML code kan uitvoeren op jouw website. In dit geval worden dan de specifieke HTML karakters (<) omgezet naar "<" wat jouw webrowser dan weer terug vertaald naar < maar zonder enige "interpreted" betekenis.
Als je dit niet doet, zou ik bijvoorbeeld een javascript code kunnen toevoegen op jouw website die verbinding maakt met mijn server om jouw cookie gegevens door te sturen.
Als jij als admin dan die pagina bekijkt, kan ik inloggen in jouw sessie (dan heb ik dus dezelfde rechten als jouw) en flinke schade toerichten in jouw admin paneel.
Gewijzigd op 15/09/2015 22:57:23 door Johan K
En op welke manier?
Klopt het dat je dit kunt instellen in de .htaccess file? En hoe effectief is dat?
Geen cookies gebruiken, maar PHP-sessies!
Code (php)
Ik krijg alleen plaats geprint het jaar niet indien gekozen, het selecteren van plaats of jaar werkt overigens wel
Gewijzigd op 17/09/2015 08:10:28 door Pierre Web
Logisch: op regel 9 overschrijf je $xxx van regel 3 / 5
Als ik de var op regel 9 andere naam geef lost dit niks op voor regel 3/5 ?
Pierre Web op 17/09/2015 12:21:50:
Ik heb het anders opgelost.
Hoe dan??
Pierre Web op 17/09/2015 12:21:50:
Als ik de var op regel 9 andere naam geef lost dit niks op voor regel 3/5 ?
Waarom denk/vraag je dat? Volgens mij namelijk wel.
Ik zou variabelen alleen geen naam als $xxx geven, maar bv. $jaar / $plaats
Gewijzigd op 17/09/2015 12:56:57 door Obelix Idefix
$xxx is alleen tijdelijk voor testje.
Johan K op 15/09/2015 22:46:22:
Als jij dit toelaat in een string die toegang heeft in jouw database geef je de gebruiker de mogelijkheid om ook daar zonder wachtwoord code uit te voeren. Dit word dan ook een SQL-injectie genoemd.
Actually, no. Een SQL-injectie is het manipuleren van een query waarbij de DATA-delen in een query als SQL geinterpreteerd worden, waarmee je effectief het gedrag van de query kunt veranderen. Injecties zijn mogelijk doordat de DATA-delen onvoldoende zijn beveiligd (door middel van onder andere, maar niet uitsluitend escaping).
Johan K op 15/09/2015 22:46:22:
Het escapen is niets meer dan " en ' te vervangen door \" en \' zodat deze tekens "geescaped" worden zodat de PHP interpreter deze tekens (", ') niet interpreteert als een begin of eind van een string.
Dit lijkt mij een oversimplificatie (denk bijvoorbeeld ook aan backslashes (\) en NUL (NULL byte) als je het over string(waarde)s hebt). Daarnaast is het praten over escaping (een definitie hiervan zou kunnen zijn: het ontdoen van de speciale betekenis van een (reeks) karakter(s) binnen een bepaalde context) zinloos als je daarbij niet aangeeft over welke context het gaat (denk aan HTML, een URL, JavaScript, (My)SQL et cetera).