The get_links method in io.php contains an SQLi vulnerability. If the $in['id'] variable is set, then it is being directly inserted into the query, circumventing the binding process in your prepared query:
$clause = "where id = ${in['id']}";
The vulnerability is made possible because your escaping mechanism only sanitises characters that are considered potentially harmful (such as quotes), and since the value being inserted into the query doesn't have quotes around it, raw SQL can be directly inserted. This problem is exacerbated by being executed as a prepared query and by the application using PDO's default of emulating prepares on the client, enabling multi-queries to be executed.
Proof of the above:
curl -X GET "http://localhost/linbeta/api/2/links/0;drop%20database%20linora;--"
It can be fixed by simply putting quotes around the $in['id'] variable in your query. This will, however, still allow junk into your query, so the better fix would be to cast $in['id'] to an integer and then use that in your query.
Disabling emulated prepares may also be a good precaution because of their ability to worsen vulnerabilities through multi-query execution.
The
get_linksmethod in io.php contains an SQLi vulnerability. If the$in['id']variable is set, then it is being directly inserted into the query, circumventing the binding process in your prepared query:The vulnerability is made possible because your escaping mechanism only sanitises characters that are considered potentially harmful (such as quotes), and since the value being inserted into the query doesn't have quotes around it, raw SQL can be directly inserted. This problem is exacerbated by being executed as a prepared query and by the application using PDO's default of emulating prepares on the client, enabling multi-queries to be executed.
Proof of the above:
It can be fixed by simply putting quotes around the
$in['id']variable in your query. This will, however, still allow junk into your query, so the better fix would be to cast$in['id']to an integer and then use that in your query.Disabling emulated prepares may also be a good precaution because of their ability to worsen vulnerabilities through multi-query execution.