目前正在将Web应用程序转移到使用Knex来帮助解决与SQL注入有关的问题。
Knex帮助我们解决了运行不同查询和新查询的问题，但我们有一个关注点。目前我们有4个端点，如下所示：
router.all('/deleteTable', checkAuth, (req, res) => {
if (checkTableWhitelist(req.body.table) === true) {
knexMarsDb(req.body.table)
.where(req.body.where)
.del()
.then((result) => {
console.log(result);
res.json({ success: true, message: 'deleted' });
})
.catch((error) => {
res.json({ success: false, message: 'failure' });
console.log(error);
});
} else {
res.send(401, 'You are not authorised for this request');
console.log('Table not in whitelist');
}
});我所理解的是，这可能是一个威胁，因为它意味着人们可以删除任何东西，多少行等，他们想。
有没有一种方法可以使它更安全（我们有很多查询在运行），或者只是将所有内容移动到一个硬编码的单个端点基础上是不是更聪明？
谢谢
2条答案
按热度按时间dced5bon1#
是的，这是设计好的SQL注入，看起来它接受任意的WHERE子句，所以只要
checkTableWhitelist()返回true，他们就可以删除任何他们想要的东西。一般来说，不建议接受请求输入，然后将其作为代码逐字使用。这适用于SQL和任何其他在运行时解析的代码。例如，您不应该接受任意Javascript代码作为输入，然后将其传递给
eval()执行。我会编写一些条件来解释输入，确保它是一组指定的删除类型之一，然后有条件地形成查询。不要在查询中使用输入的文本，而只使用输入来选择要运行的DELETE语句。这使您能够进行控制。
dsekswqp2#
Knex是一个查询构建器（通常被其他高级库（如ORM）用作构建块），它可以防止SQL注入，因为它在幕后实现了占位符。
因此，假设函数“checkTableWhitelist”按预期工作（不容易受到攻击），您只是让最终用户完全控制这些表。
假设这是您想要实现的行为，则始终不建议直接向外部公开数据库。
如果安全性是您关心的问题，那么您应该以更严格的方式实现API。
例如：为要授予的每个操作公开一个终结点，
API/表格/字段/：ID/删除
因此控制器逻辑将是：