input filteren
Dit is eerder een vraag om advies over veiligheid.
Ik merkte deze functies onlangs op:
$sanitized_a = filter_var($a, FILTER_SANITIZE_EMAIL);
Dus je kan input filteren tegen sql injectie bvb.
Nu vraag ik mij af of dit even veilig is om te gebruiken als de zelfgemaakte functies gelijk in wordpress.
Ruben D op 28/12/2017 17:11:07:
Dus je kan input filteren tegen sql injectie bvb.
Daar is deze functie niet specifiek voor bedoeld. Deze functie probeert van een string nog een geldig emailadres te maken. Om SQL injection tegen te gaan kun je beter gebruik maken van bv. PDO en Prepared Statements
Gewijzigd op 28/12/2017 17:55:37 door Jan Koehoorn
Ik zou het ook zo doen maar wou weten of dit daar ook tegen helpt.
SQL injectie voorkom je ook niet (altijd) simpelweg door het filteren van input, tenzij deze heel strict is. Wat veel beter werkt tegen SQL injectie is output escaping. En vaak gaan input filteren en output escapen hand in hand.
Desalniettemin zijn dit twee compleet verschillende dingen.
EDIT: en sanitizen is wéér iets anders, daarbij wordt vaak geprobeerd recht te buigen wat eigenlijk al krom is. Vergelijk dit met een typecast waarbij getracht wordt iets om te zetten naar een bepaald type waarbij alles wat onleesbaar is uit oogpunt van dat type wordt weggekapt. Maar daarmee was dus eigenlijk de invoer al ongeldig... Invoer is meestal gewoon GOED of FOUT, en niet MISSCHIEN-GOED-DUS-LAAT-IK-PROBEREN-ER-IETS-VAN-TE-BAKKEN.
> filter input, escape output
> mysql_real_escape_string() is geen wondermiddel
Gewijzigd op 28/12/2017 19:25:56 door Thomas van den Heuvel
$stmt = $pdo->prepare("INSERT INTO myTable (name, age) VALUES (?, ?)");
$stmt->execute([$_POST['name'], 29]);
of bypass gelijk dit denk ik dat je bedoeld?
$stmt = $pdo->prepare("INSERT INTO myTable (name, age) VALUES ($name, ?)");
Ik dacht wel ergens gelezen te hebben dat mysqli escape eruit gaat bij recente versies.
Ik zal is kijke of ik het nog kan vinden.
Voordat je de waarden gebruikt om aan je insert query te koppelen, heb je alles gevalideerd (met bv. een EmailValidator class) en in orde bevonden.
Een andere optie, is werken met Value Objects, waarbij de validatie in de constructor plaatsvindt. Een Value Object voor een email adres kan er zo uitzien:
Code (php)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
Het voordeel van werken met Value Objects is, dat je in je hele codebase nu nog maar één plek voor het valideren van email adressen hebt, namelijk in de constructor van dat object.
Gewijzigd op 28/12/2017 21:23:05 door Jan Koehoorn
Jan Koehoorn op 28/12/2017 20:51:17:
Value Objects
Dit klinkt allemaal best zinnig enzo, maar hoe ga je dit inpassen in de validatie van formuliergegevens? Wanneer een exception gethrowd wordt, wordt de normale flow van het programma onderbroken.
Ik zou ook niet zeggen dat een exception hier op zijn plaats is, het ligt immers in de lijn der verwachting dat iemand (al dan niet per ongeluk) een verkeerd e-mailadres invult. Ook wil je dan niet dat alles gestaakt wordt maar idealiter krijg je dan gebruiksvriendelijke terugkoppeling over *alle* velden waar mogelijk iets mis mee is (en niet enkel de eerste waar ie op stuk loopt, denk aan JavaScript popups uit de jaren 90 :p).
Ik had ook eerder een berichtje
Mogelijk zou een exception bijvoorbeeld (wel?) op zijn plaats zijn bij formulierafhandeling wanneer een CSRF-token niet meer klopt (of niet meer bestaat) bij validatie omdat dat echt iets "onverwachts/ongeplands" is. Maar zelfs dan heb je liever dat (wanneer je sessie onderwater weer hersteld is, want het is meestal zoiets als een verlopen sessie ofzo) je weer teruggestuurd wordt naar het formulier met de zojuist ingevulde informatie -ook al is deze goed- maar met de mededeling dat het token is verlopen en je nogmaals dient te submitten. Dat lijkt mij vriendelijker dan een aparte "oeps, er ging iets mis" pagina nadat je het afgelopen half uur een verhaal hebt zitten typen, en dat je dat dan kwijt bent.
Oftewel: ik zie niet zogauw hoe het (veelvuldig) gebruiken van exceptions een goed idee is bij formulierafhandeling/-validatie. Het is niet "fataal" als iemand iets verkeerds ingevuld heeft, noch is het dan onduidelijk wat er vervolgens zou moeten gebeuren.
Gewijzigd op 29/12/2017 01:26:50 door Thomas van den Heuvel
Ik vind dat ook wat lastig. Op het forum heb ik mensen wel eens horen (niet letterlijk) zeggen dat je beter overal exceptions kunt gebruiken (ipv if-statements). Ik vraag me dus ook wel af wanneer wel en wanneer niet. Mij lijkt het ook niet logisch om een fout e-mailadres af te vangen met een exception, en toch schijnt het te gebeuren.
Want eigenlijk is het natuurlijk best raar ... Je vangt een situatie die zich kan voordoen af met een exception ... maar als je weet dat de situatie zich kan voordoen ... in hoeverre is het dan nog een exception? En ... wanneer is iets dan überhaupt nog een exception? Iemand die een typfout maakt (veelvoorkomend gedrag) zie ik niet als een exception, iemand die een fout wachtwoord invoert ook niet. Dat is allemaal VOORSPELBAAR gedrag.
Maar wat zou dan wel een exception kunnen zijn ... Misschien een keuzeformulier dat als waarde A, B of C verwacht, maar X ontvangt? Dan is er sprake van iets onverwachts wat riekt naar een hackpoging, maar verder zou ik het zo gauw ook even niet weten.
Was dat niet ook op de DOS-prompt: de keuze-loop vliegt er toch ook niet uit als je iets anders dan [a]bort, [r]etry, [f]ail kiest? :)
Zoals ik het zie is een exception een soort van noodrem, waarbij de code zegt "ik kom er ff niet uit". Een hoger gelegen laag / ander stuk code beslist dan meestal wat er moet gebeuren. Dit is denk ik ook een kenmerk van exceptions: de plek waar aan de noodrem wordt getrokken is zelden tot nooit de plek waar dit verder wordt afgehandeld. Immers, dit zou namelijk inhouden dat de code al een soort van idee heeft van wat er mis is gegaan, en hoe hier mee omgegaan moet worden. Wat weer een indicatie is dat je hiervoor geen exception hoeft te/zou moeten gebruiken :).
Thomas van den Heuvel op 29/12/2017 01:20:47:
Dit klinkt allemaal best zinnig enzo, maar hoe ga je dit inpassen in de validatie van formuliergegevens?
Jan Koehoorn op 28/12/2017 20:51:17:
Value Objects
Dit klinkt allemaal best zinnig enzo, maar hoe ga je dit inpassen in de validatie van formuliergegevens?
Niet. Daar vul je gewoon een array met errors. Je zou trouwens wel kunnen denken aan een AJAX call op de onblur van een formfield, met daarin dan weer wél de check met het value object. Dan heb je userfriendly validation aan the client side en uiteraard check je altijd serverside. Ik zou dat alleen doen bij formulieren met veel velden. Dan is het wel prettig om meteen na het verlaten van het veld erachter te komen dat het invalid is, en niet pas bij het submitten van het formulier.
Thomas van den Heuvel op 29/12/2017 14:37:52:
Precies, maar dan zou je kunnen zeggen: ik heb een set A, B, C en hier moet een geldige keuze in gemaakt worden. Als je dan X krijgt is dat geen geldige keuze. Het is dan nog steeds duidelijk wat er zou moeten gebeuren (kies een geldige waarde).
Ik snap wat je bedoelt ... maar stel we hebben 2 radiobuttons waarbij je kunt kiezen of je van een product de variant van € 50 wilt hebben, of de luxere variant van € 65.
Je kunt dus kiezen uit waarde € 50 of € 65. Stel dat je nu ineens als waarde € 1 krijgt (een keuze-optie die helemaal niet beschikbaar is), zou je dan niet een exception kunnen gooien? In dat geval heeft namelijk iemand handmatig de POST-data gewijzigd en is er blijkbaar sprake van een soort hackpoging. Dit gaat weer net iets verder dan simpelweg 'een ongeldige keuze'.
In zo'n geval zou ik misschien op een hoger niveau het IP-adres even willen blokkeren vanwege verdacht gedrag.
Ozzie PHP op 29/12/2017 17:23:44:
In zo'n geval zou ik misschien op een hoger niveau het IP-adres even willen blokkeren vanwege verdacht gedrag.
En dat is een goed voorbeeld van Value Objects. Je throwt een Exception, en in de catch log je iets, of je onderneemt een andere actie. Bij Value Objects kun je denken aan geldbedragen, datumbereiken, emailadressen, etc.
Maar dan moet dat value object wel weten welke waardes wel en niet zijn toegestaan. De toegestane waardes geef je dan als parameter mee in een array of zo?
nee, de enige parameter(s) die je aan de constructor meegeeft, zijn de value(s) die je wilt gebruiken. De validatie vindt geheel in de constructor plaats, en je kunt natuurlijk ook properties gebruiken om bijv. een onder- en bovengrens van een waarde aan te geven.
Mijn voorbeeld hierboven in dit topic is niet helemaal volledig. Een Value Object is bijvoorbeeld altijd final, want je wilt dat de waarde niet kan veranderen als hij eenmaal gevalideerd is, door hem bijvoorbeeld te extenden, wat dus verboden is. Een VO heeft ook geen setters. Dat is eigenlijk de essentie van een Value Object; alleen het feit dat hij aangemaakt is en dus door de constructor-validatie komt, garandeert dat hij altijd valid is.
Er is nog veel meer te vertellen over Value Objects, maar dat valt een beetje buiten dit topic, maar er zijn goeie blogs over te vinden.
Edit:
Nog één aanvulling: wanneer je in een andere class in de constructor een type-hint naar een Value Object aangeeft, garandeer je dus dat die property altijd valid is. Bijvoorbeeld:
Als nu $email niet van het type Email is, of niet goed aangemaakt is, krijg je automatisch een Exception. Het scheelt je dus heel veel validatie.
Toevoeging op 29/12/2017 20:41:04:
Nog één aanvulling: wanneer je in een andere class in de constructor een type-hint naar een Value Object aangeeft, garandeer je dus dat die property altijd valid is. Bijvoorbeeld:
Code (php)
Als nu $email niet van het type Email is, of niet goed aangemaakt is, krijg je automatisch een Exception. Het scheelt je dus heel veel validatie.
Toevoeging op 29/12/2017 20:41:04:
Jan Koehoorn op 28/12/2017 20:51:17:
Sowieso gebruik je nooit rechtstreeks $_POST variabelen in parameter binding.
Voordat je de waarden gebruikt om aan je insert query te koppelen, heb je alles gevalideerd (met bv. een EmailValidator class) en in orde bevonden.
Een andere optie, is werken met Value Objects, waarbij de validatie in de constructor plaatsvindt. Een Value Object voor een email adres kan er zo uitzien:
Het voordeel van werken met Value Objects is, dat je in je hele codebase nu nog maar één plek voor het valideren van email adressen hebt, namelijk in de constructor van dat object.
Voordat je de waarden gebruikt om aan je insert query te koppelen, heb je alles gevalideerd (met bv. een EmailValidator class) en in orde bevonden.
Een andere optie, is werken met Value Objects, waarbij de validatie in de constructor plaatsvindt. Een Value Object voor een email adres kan er zo uitzien:
Code (php)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
<?php
final class Email
{
private $email;
public function __construct($email)
{
if ( ! filter_var($email, FILTER_VALIDATE_EMAIL)) {
throw new InvalidArgumentException(sprintf('[%s] is not a valid email address', $email));
}
$this->email = $email;
}
public function __toString()
{
return $this->email;
}
}
?>
final class Email
{
private $email;
public function __construct($email)
{
if ( ! filter_var($email, FILTER_VALIDATE_EMAIL)) {
throw new InvalidArgumentException(sprintf('[%s] is not a valid email address', $email));
}
$this->email = $email;
}
public function __toString()
{
return $this->email;
}
}
?>
Het voordeel van werken met Value Objects is, dat je in je hele codebase nu nog maar één plek voor het valideren van email adressen hebt, namelijk in de constructor van dat object.
Gewijzigd op 29/12/2017 20:37:53 door Jan Koehoorn
>> nee, de enige parameter(s) die je aan de constructor meegeeft, zijn de value(s) die je wilt gebruiken.
Oké ... maar hoe zou je dat dan doen bij een keuze met radiobuttons ... in het voorbeeldje wat ik gaf, kun je dmv een radiobutton waarde ABC123 of XYZ789 kiezen. Hoe voorkom je dan dat een hacker de waarde KLM456 verstuurt? Anders gezegd ... hoe weet dat value object dat alleen ABC123 en XYZ789 zijn toegestaan?
Code (php)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
<?php
class MyVerySpecificValueSet
{
private $allowed = [
'ABC123' => true,
'XYZ789' => true,
];
private $val;
public function __construct($val)
{
if (empty($this->allowed[$val])) {
throw new InvalidArgumentException(
sprintf('[%s] is not a valid value for [%s]', $val, __CLASS__)
);
}
$this->val = $val;
}
}
?>
class MyVerySpecificValueSet
{
private $allowed = [
'ABC123' => true,
'XYZ789' => true,
];
private $val;
public function __construct($val)
{
if (empty($this->allowed[$val])) {
throw new InvalidArgumentException(
sprintf('[%s] is not a valid value for [%s]', $val, __CLASS__)
);
}
$this->val = $val;
}
}
?>
(ja, ik weet, we dwalen af ...).
(uiteraard zit hier dan ook een programmeerfout als je het op deze manier zou programmeren, maar het is puur even als voorbeeldje bedoeld)
PS
Alvorens ik dit topic nu kaap ... Ruben ... heb jij al een antwoord op je vraag?
Ik wou er even op in gaan wat het nut van bind_param is, is dit ook en filter op je variabel?
dan zou ik er dus 2 achter elkaar hebben, niet dat het erg is.
hierna mag je het kapen.