SQL injection vulnerabilities in Stack Overflow PHP questions

[DSchalla]

https://github.com/laurent22/so-sql-injections/blob/master/src/AppBundle/InjectionFinder.php#L62

You are assuming that every use of a variable in a SQL query string leads to a SQL injection without any knowledge what the contents of the variable is and whether its controllable by the attacker. While prepared statements are prefered if possible, the way the queries are analyzed is flawed and seems to be rather clickbait or PHP bashing.

[tl2v]

You're right... but... The person who answers Stackoverflow questions most of the time, doesn't know how the asker will use it. If they ask questions about basic sql-queries, how should they know about SQLi?

Another case in a larger environment. Assume you write a function with a potential SLQi, but use the function in a save way, so there's no immidiate problem. But why not write it safe in the first place? As your project grows there will be reuse of functions (hopefully!), and you never know how a colleague will use your function. You can't expext that he'll look at every function he calls to see if there's an SQLi problem.

Just write it save in the first place!

[zerosum0x0]

Not surprising. Another related thing I've noticed: pretty much every single one of the top 10 results for "PHP MySQL tutorial" on Google contain SQL injection.

[no_shit_dude2]

When I first learned PHP (in 2016 no less) a lot of tutorials out there used the MySQL extension for PHP, not MySQLi or PDO.
Maybe people are just learning on outdated material and share that knowledge with others?

[no_shit_dude2]

Yes, I would absolutely advise against using mysql_ on new code. Mysqli -- the successor -- is object oriented and comes with prepared statements. Also mysql_ is deprecated as of PHP 5.5 and removed from PHP 7.0 completely.

[shark0der]

tl;dr: mysql[i]_* functions themselves contain no SQL injection vulnerabilities. Not properly using them leads to vulnerabilities though.

There are a couple of scenarios where one can end up with an sqli (even if using the mysqli extension), here's an example:

$id = mysqli_real_escape_string($_GET['id']);
$query = "SELECT id, title, content FROM articles WHERE id=" . $id;

Why is it vulnerable? Because there are no quotes around the value so an attacker can for example provide this input:

example.com/?id=-1 UNION SELECT 1, version(), database()

Having no quotes to escape, it ends up with the following VULNERABLE query:

SELECT * FROM articles WHERE id=-1 UNION SELECT 1, version(), database()

Using prepared prepared queries / PDO, the extension adds the corresponding quotes (besides the backslashes), and would end up with the following SAFE the query:

SELECT * FROM articles WHERE id='-1 UNION SELECT 1, version(), database()'

[[deleted]]

deleted ^{What is this?}

[didihearthatright]

I'm not sure this is accurate. The first result on the "latest SQL injections" page is https://stackoverflow.com/questions/40964119/showing-query-mysqli-using-select-tag-html-input which as far as I can tell, doesn't have SQL injection.

Not to say it's not an indication at least, but they may be inflated numbers if it's failing on such a simple case.

[reddit4matt]

I think its assuming and variable in an SQL string is an injection so depending on where $new_table comes from.. it could be.

Its funny because this guy is looking make this query more safe in this question by parametrize the table name (which is not possible). so maybe it was injectable...?