Hi
I am familiar with the concept of SQL injection and preventing it via precautions such as prepared statements. I am also familiar with the idea of htmlspecialchars()
for preventing malicious JS etc.
Forgetting about client side validation, which I see more as providing a good user experience rather than any effective protection -
it seems to me that at there is a point between where a user input is submitted to the server and when any actual validation is performed. For example -
if (!filter_var(trim($_POST['email']), FILTER_VALIDATE_EMAIL)) {
We have no idea what $_POST['email']
actually contains until the validation has completed. Could a malicious user include malicious code that ārepurposesā the code.
Same for a password, could the actual $_POST['password']
value contain a malicious code segment that kicks in before $password = password_hash($_POST['password'], PASSWORD_DEFAULT);
completes the desired process.
I do not understand all the technicalities but it seems to me that, however much checking and validating you do, there is a point at which an āunvalidatedā string is presented within a PHP āinstructionā PRIOR to validation, if only to actually validate it!
As a follow on, kind of bonus question if you will permit me -
It is common practice to allow - or even insist on - special character within passwords. Should characters with particular āmathematicalā meanings be excluded such as =, (,) etc. to prevent any malicious activity hijacking the password validation itself.
Maybe I am paranoid, but it just seemed to me that there is a potential chink in the PHP armour here. Iāll just sleep easier if I know my validation attempts are not actually additional unlocked doors that could be exploited
Thanks guys