我想知道类似以下的 URL 是否存在安全风险
http://www.mytestapp.com/results?limit=1234
限制 GET 参数将被检查为有效整数并直接传递到查询中。
如果用户将此参数更改为非常大的数字,会发生什么情况?对于一个巨大的数据库,这会导致类似于拒绝服务的效果吗?
具有可变结果限制的最佳实践是什么?
不要只是将 GET 变量直接传递到查询中。如果你这样做了,那么我可以像这样进行 SQL 注入:
http://www.mytestapp.com/results?limit=1%3BDROP%20TABLE%20USERS
您的查询最终将如下所示:
select * from some_table where parameter = 3 limit 1;DROP TABLE USERS
我假设您正在尝试进行分页。如果是这样,您会想要这样的东西:
http://www.mytestapp.com/results?page=1&size=10
然后,在后端验证
page
和 size
都是整数,并且大小都合理。也许可以对 size
的范围设置限制,例如,可能只能是 10 到 100 的倍数。
在 get 字符串中传递参数的主要问题是它可能会导致 SQL 注入攻击。如果有人通过了这个怎么办:
您需要仔细观察,以确保您的输入是干净的。
假设您对此很了解并了解安全性,那么另一个问题是它将您的限制置于最终用户手中。他们可以通过使用非常大的数字来有效地消除限制。根据查询的复杂性和表的大小,这可能会对服务器性能和其他用户产生负面影响。
我不知道由于限制条款中的数量较多而存在任何其他问题。例如,我认为您不需要担心溢出。
正如其他人所设置的,在将输入传递到数据库之前验证输入,以确保它是整数,不包含除数字之外的任何内容,并且具有合理的大小值。对于这种情况,您将有效地防止 SQL 注入。
您也不应该通过将命令逻辑与来自不受信任来源的参数连接起来来构建查询字符串。您应该使用参数化查询,在创建数据时确定数据适合 SQL 语句的位置,然后绑定该值。这具有允许数据库区分您想要的命令和数据的效果,即使您在输入验证中错过了攻击案例,也可以防止 SQL 注入(对于这种特殊情况,白名单很容易......这并不总是正确的,甚至是不可能的)。您可以在编写良好的 OWASP SQL 注入预防备忘单页面上阅读有关参数化查询的更多信息。