Hallo,

Ik gebruikte altijd mysql_real_escape_string() om userinput veilig te maken en vervolgens te gebruiken in mijn MySql queries. Dit ter voorkoming van MySql injections.

Nu weet ik inmiddels dat mysql_real_escape_string() eigenlijk niet meer veilig genoeg is. Ik heb al wat gelezen over mysqli, maar ik kom er toch niet helemaal uit. Ik ben op zoek naar een functie die anno 2013 veilig is en ik op de volgende manier kan gebruiken:

<?php

function veiligeInput($input){

//hier de code die mijn input veilig maakt

return $veilige_string;
}


$voornaam = veiligeInput($_POST['voornaam']);
$achternaam = veiligeInput($_POST['achternaam']);
$email = veiligeInput($_POST['email']);

sql_query("INSERT INTO users (voornaam, achternaam, email) VALUES ('$voornaam', '$achternaam', '$email')");

//opmerking: hij moet natuurlijk net zo veilig zijn bij SELECT's en UPDATES, etc.

?>
Sorry Chris -, ik reageerde op de opmerking van jouw naamgenoot (Chris NVT).

Ik vind een prepared statement voor een eenmalige query overkill, en gebruik ze dus niet.
Met als gevolg dat ik dus ook geen parameters kan gebruiken, want volgens de PHP ontwikkelaars zijn die onlosmakelijk verbonden aan een prep. In asp.NET is dat niet, daar zijn de parameters verbonden aan een SQL command, en dat command kan je dan eventueel nog preparen.
Wat is er mis met producurele mysqli-code en mysqli_real_escape_string()?
Ger van Steenderen op 17/08/2013 19:24:29

als iemand het lef heeft om een string in te voeren ipv een integer een dikke vette exception te werpen!

Toevoeging op 17/08/2013 19:27:06:

Overigens geldt dit ook voor mysqli

Dat is toch goed? Je geeft zelf aan doormiddel van PDO::PARAM_INT of PDO::PARAM_STR of het een string is of een interger. Als jij dan een string toekent aan iets wat een integer veld is of andersom vind ik het niet meer dan normaal dat je een exeption krijgt, is onderdeel van de beveiliging.

Helemaal met je eens Chris NVT, maar ik heb begrepen** dat nu juist niet zo is. Vandaar de opmerking.

**= Ik heb die vraag hier eens op het forum gesteld.
@Ger,

Kun je dan ook uitleggen waarom die juit niet zo is? Want nu ben ik natuurlijk wel benieuwt!! Ik ga net over naar PDO.
Zoals ik het begrepen heb kan je gewoon een string toekennen aan een parameter van het type integer.
Ik heb het nog niet uitgeprobeerd, maar heb dat eens gevraagd hier op het forum, en toen was het antwoord dat je geen exception krijgt. Maar ik kan het dus mis hebben.

Ik heb overigens helemaal niks tegen op PDO, ik gebruik het zelf ook.
@Ger,
Ok, ik zal dit vanavond gelijk eens op de proef stellen of je daadwerkelijk een string aan PDO::PARAM_INT kunt assignen zonder een exception te krijgen, is idd een goed punt.

Als dat zo is dan heeft idd het hele bindParam geen nut, want je bind hem aan het type INT of STR.
Volgens mij typecast je dan van string naar integer, of integer naar string. String -> integer wordt 1, integer -> string wordt dezelfde waarde, maar dan als string
Volgens mij is de typecast inderdaad een issue, maar ook om een andere, meer fundamentale reden. MySQL accepteert bijvoorbeeld de string '1' als de integer 1. Dan is het dus niet het domein van PDO als database-interface om '1' automatisch als ongeschikte integer af te keuren.

Zolang PHP andere datatypen heeft dan databases, zijn de taken en verantwoordelijkheden van een brug zoals PDO nogal een schemerzone.

Reageren