在没有参数化查询的情况下防止PHP中的SQL注入

我知道这个话题已经被讨论到死了，但是我想从社区中得到一些关于我们web应用程序安全性的反馈。

我们有标准的LAMP堆栈web应用程序，其中包含使用mysqli_query执行的大量数据库查询。这些查询目前没有参数化，但是使用addslashes对输入进行了一些简单的转义。

我的任务是使这个系统更安全，因为我们将很快进行渗透测试。上述高层知道参数化查询是使系统更安全的方法，但他们不想花费时间和精力重写应用程序中的所有查询，也不想改变我们必须使它们正常工作的框架。

基本上我在问我有什么选择?

我在输入端运行了mysqli_real_escape_string。我设置了一个过滤器，它不允许像SELECT, WHERE, UNION这样的词被传递，我想这让它更安全。我知道mysqli_query只允许一次运行一个查询，所以那里有一些安全性(从连接更新到选择的结束)。

我这里还有其他选择吗?

编辑:我可能应该补充说，如果有人能够提供一个攻击的例子，这是完全不可避免的没有参数化查询，这也将是有帮助的。我们有一个像这样的查询:

SELECT
pl.created
p.LoginName,
pl.username_entered,
pl.ip_address
FROM loginattempts pl
LEFT JOIN people p ON p.PersonnelId = pl.personnel_id
WHERE p.personnelid = $id
AND pl.created > $date1
AND pl.created < $date2

我已经将UNION查询替换为$id UNION SELECT * FROM p WHERE 1 = 1之类的东西，我可以通过不允许SELECT/UNION来防止这种情况，但我确信还有无数其他类型的攻击我无法想到。谁能再提几个建议?

我已经说服了我的上级，我们需要将查询重写为参数化语句。他们估计可能需要几个月的时间，但这是必须要做的。赢了。我的想法吗?

更新2

不幸的是，我还没能说服当权者，我们需要将所有的查询重写为参数化的查询。我们提出的策略是测试每个输入，如下所示:

如果用户提供的输入为is_int，则将其强制转换为is_int。实数也是一样。在字符数据上运行mysqli_real_escape_string。将查询中的所有参数更改为引号字符串，即

WHERE staffName = ' . $blah . '

根据这个答案，我们是100%安全的，因为我们没有在任何时候改变字符集，我们一直使用带有latin1字符集的PHP5.5

更新3

这个问题被标记为重复，但在我看来，这个问题仍然没有得到回答。根据更新编号。我们发现一些强烈的意见，mysqli_real_escape string函数可以防止攻击，显然是"100%安全"。从那以后，就没有一个好的反驳论据(例如，一个攻击的演示，如果使用得当，可以击败它)。