2 ms·
From the article: > Another example of this kind of thing is SQL injection, an attack that’s closely related to cross-site scripting. NaiveSite is powered by M
by thaumaturgy 7y ago
From the article:
> Another example of this kind of thing is SQL injection, an attack that’s closely related to cross-site scripting. NaiveSite is powered by MySQL, and it finds users like so:
>
> $query = "SELECT FROM users WHERE name = '{$name}'"*
>
> When a boy named Robert'); DROP TABLE users; comes along, NaiveSite’s entire user database is deleted. Oops!
Also from the article:
> And of course use your SQL engine’s parameterized query features so it properly escapes variables when building SQL:
>
> $stmt = $db->prepare('SELECT FROM users WHERE name = ?');
> $stmt->bind_param('s', $name);
And more from the article:
> The parallel for SQL injection might be if you’re building a data charting tool that allows users to enter arbitrary SQL queries. You might want to allow them to enter SELECT queries but not data-modification queries. In these cases you’re best off using a proper SQL parser (like this one) to ensure it’s a well-formed SELECT query – but doing this correctly is not trivial, so be sure to get security review.
And the article links to https://stackoverflow.com/questions/129677/how-can-i-sanitize-user-input-with-php/130323#130323 https://stackoverflow.com/questions/129677/how-can-i-sanitiz..., which further explains:
> What you should do, to avoid problems, is quite simple: whenever you embed a string within foreign code, you must escape it, according to the rules of that language. For example, if you embed a string in some SQL targeting MySQL, you must escape the string with MySQL's function for this purpose (mysqli_real_escape_string). (Or, in case of databases, using prepared statements are a better approach, when possible.)
I hope this satisfactorily answers your question.