Veilige input
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:
Code (php)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
<?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.
?>
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.
?>
Gewijzigd op 14/08/2013 18:46:06 door Frank Nietbelangrijk
Enigste is dat het deprecated word in php 5.5 (dacht ik) en daarom zal je over moeten stappen op iets anders zoals bijv pdo of mysqli.
Mysqli kan je in theory hetzelfde gebruiken als mysql, (of je dit wil is een 2e) enigste is dat je altijd je connectie als parameter mee moet gegeven als je iets wil escapen met mysqli_real_escape_string.
Ik zal binnenkort eens kijken of ik me oude mysqli class nog heb, mischien heb je er iet saan.
- Aar - op 14/08/2013 20:43:13:
Hoezo een mysqli-class? Wist je dat MySQLi zover objectgeorienteerd kan werken als losstaand (woord kwijt)?
procedural style ;)
@Frank, @Erik, zie het topic [Q&A] Beveiliging algemeen, dan zie je snel genoeg dat mysql_real_escape_string() lang zo veilig niet is..
Erik van Beek op 14/08/2013 20:37:31:
Mysql_real_escape_string is prima veilig.
Enigste is dat het deprecated word in php 5.5 (dacht ik) en daarom zal je over moeten stappen op iets anders zoals bijv pdo of mysqli.
Mysqli kan je in theory hetzelfde gebruiken als mysql, (of je dit wil is een 2e) enigste is dat je altijd je connectie als parameter mee moet gegeven als je iets wil escapen met mysqli_real_escape_string.
Ik zal binnenkort eens kijken of ik me oude mysqli class nog heb, mischien heb je er iet saan.
Enigste is dat het deprecated word in php 5.5 (dacht ik) en daarom zal je over moeten stappen op iets anders zoals bijv pdo of mysqli.
Mysqli kan je in theory hetzelfde gebruiken als mysql, (of je dit wil is een 2e) enigste is dat je altijd je connectie als parameter mee moet gegeven als je iets wil escapen met mysqli_real_escape_string.
Ik zal binnenkort eens kijken of ik me oude mysqli class nog heb, mischien heb je er iet saan.
Ga voor PDO werkt super.
PDO werkt redelijk, het zou super zijn als een parameter niet verbonden wordt aan een prepared statement, én 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
Gewijzigd op 17/08/2013 19:25:44 door Ger van Steenderen
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.
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
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.
**= Ik heb die vraag hier eens op het forum gesteld.
Kun je dan ook uitleggen waarom die juit niet zo is? Want nu ben ik natuurlijk wel benieuwt!! Ik ga net over naar PDO.
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.
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.
Zolang PHP andere datatypen heeft dan databases, zijn de taken en verantwoordelijkheden van een brug zoals PDO nogal een schemerzone.