-
Notifications
You must be signed in to change notification settings - Fork 17
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Code vulnerable for SQL injections #28
Comments
The |
(Correction by @GreenReaper: throwing an exception is new in PHP 8, in PHP 7 it raises a warning and evaluates to 0, or maybe it depends on some kind of strictness setting too. But at no point does the string survive into the |
Could avoid the exception with type coercion to int if that is desired. As it is, it'd probably still take a float, which may not be desirable to present to SQL that expects an int (I don't think you can pass in INF or NAN; they'd be taken as strings, not constants). In the general case, yes, it's probably a good idea to use parameterized queries in new code and seek to convert old ones, because it's easy to slip up. |
Maybe in this particular example.. But that's not the point. Not using prepared statements is not something you would like to do.. |
Hi,
I see a lot of lines like this function:
If one would simply set $id to
0;DROP TABLE COMMAND;
, the command table will be gone. Easy as that.. Please, for the love of god; use SQL prepared statements. See: https://www.w3schools.com/php/php_mysql_prepared_statements.aspThe text was updated successfully, but these errors were encountered: