我是否应该在我不了解黑客如何破坏系统的情况下添加保护?

信息安全 Web应用程序
2021-09-05 20:54:07

假设有一个 AJAX 应用程序,用户可以在其中提交项目 - 购买它们。

还有一个代码

IF ($_POST[items] > 20) {
   echo 'error';
}
else {
   do_buy($_POST[items]);
   echo 'success'
}

在这里,有一个检查是否items不超过 20。在客户端,应该不能选择超过 20 个项目。

即使提交了 21 个(或更多)项目(用户只需为每个项目付费),系统也可以正常工作。虽然我知道你一定想大喊不信任客户,但如果没有后果,这样做有什么害处吗,就像这里的情况一样?

有人可能会说,超载购物车可能会导致系统不稳定,但似乎最坏的情况是某些脚本超时。如果错误被禁用,用户将不会得到任何响应。

一般来说:为违反系统不变量的攻击编写保护代码是否有意义?

更新:

$_POST['items'] 我的意思是这是数组,而不是整数。以及每个项目如何拥有属性 - id 和数量,稍后在完成购买操作之前检查这些属性。

关于 sql 注入 - 我通常使用框架,它们负责注入保护。

更新

我问这个问题的另一个原因是我想要尽可能多的干净代码,并且当有人阅读它时 - 会想为什么需要这样做,这个程序员不知道他在编程什么以及为什么。因此,对于所有代码,我想清楚地说明为什么那段代码存在,所以如果没有评论,那么至少我自己会清楚地理解为什么要进行此检查,以便我可以解释是否有其他程序员询问。

4个回答

是的,您应该添加保护措施,但它们需要适合具体情况。

必须验证所有用户输入。基本原则是您不定义什么是“坏”输入,您定义什么是“好”输入并拒绝其他所有内容。以您为例,您已将“items > 20”定义为错误。但是如果“项目”是-1怎么办?如果是数量);DROP TABLE Orders;--呢?

基本技术是查看每个用户输入字段并定义“好”值的外观,同时考虑到您的软件功能和业务规则。例如,“items”可能是“一个大于 0、小于 20 且小于或等于库存数量的整数”——这将拒绝过大的订单、过小的订单和奇异的输入,例如SQL 注入,无需担心攻击者可能试图做什么或您的软件可能会如何反应。

这必须在服务器端完成。客户端验证可以帮助诚实的用户;不诚实的用户只能在服务器端被阻止,因为他们控制着客户端。

用你的房子类比,所有用户输入都是门的一部分。

你不可能总是知道事情真的会变坏。在您当前的示例中,攻击者可以发送一个非常大的值,导致算术或堆栈溢出或未处理的异常导致服务器关闭并导致可用性问题。

因此,请始终进行检查,始终考虑可能发生的最坏情况,并将攻击者视为能够做“任何事情”的人。始终制作白名单,而不是黑名单。在列表中考虑标准攻击方法(XSS、CSRF、注入等)并检查范围。

尽可能密封门窗,并始终检查您的设计、代码和环境。

简短的回答:不,如果您正在制作销售网站,请紧急参加安全速成课程!

您不应该仅仅因为您不知道发生了什么而添加任意限制、检查和“保护”。如果您这样做,您更有可能添加问题并让安全漏洞处于开放状态。显然,有安全专业人员的原因是因为他们受过培训,可以识别所需的保护措施。

首先定义系统中的资产,包括您的和您的客户的。你需要知道什么是有价值的,因为这就是黑客的目标。它包括个人数据、具有财务价值的数据(银行账户信息等)、您销售的商品、您客户的计算机(可用于僵尸网络,以防跨站点脚本攻击)以及您自己的服务器、数据库和 Web 服务器。

一旦您知道要保护什么,您就需要定义它需要发生什么以使您的系统正常运行。本质上,您需要列出您允许客户在您的网站上执行的操作。例如,这个任意的 20 项限制是完全不合理的

第二步是了解你的对手可能是谁以及他们能做什么要有创意,但要保持现实。你不太可能对 NSA 感兴趣,而不是一个对销售网站有经济利益的黑客。这个过程称为威胁建模你必须:

  • 为每个资产定义你的对手
  • 定义他们的能力(这需要大量的安全知识)
  • 定义对您的资产的威胁(这些功能可以让攻击者对您做什么)

既然您知道可能发生在您身上的事情,您需要定义必须保留在您的资产上的安全属性,然后您必须选择保证这些属性的机制。反过来,这些机制成为您系统的关键资产,必须同样受到保护。这被称为可信计算库

当你在那里时,你可以开始考虑转向测试版。您必须通过通常由第三方公司进行的渗透测试来评估您的安全性。但这应该已经让你很忙了;)

编辑:请花一些时间阅读最常见的变成漏洞的软件程序允许用户购买超过 20 件商品并不是其中之一。

如果用户端的某些恶意软件让客户在您的网站上购买了 200 万件商品,而您的网站在没有发出任何警报的情况下执行了交易,那么有些人,尤其是被骗的客户,可能会大声抱怨并声称您的服务器是有点松懈。可能会争辩(在法庭上!)您没有进行一些“明智的”检查是错误的。甚至可能有一些适用的法规要求进行一些服务器端验证(至少银行会检查信用卡上的“异常活动”并阻止看起来特别奇怪的交易)。

在一般情况下,为异常情况添加额外检查是明智的编程习惯。您知道客户端不应允许超过 20 个项目。如果客户端界面上的一些错误允许客户端放置 21 个项目,那么它应该被修复,并且如果您尽快收到警告会更容易,例如通过服务器端检查。

(但它有一个阴暗面:如果您在服务器端添加检查,然后决定将限制提高到 25,您必须修改客户端服务器。但是,这应该很容易检测到在部署前测试期间,所以不要避免添加健全性测试。)