我正在通过 Intranet 开发应用程序,并且仅供内部员工使用。这里不会涉及任何外部方,应用程序不会使用外部通信。
在这种情况下是否需要安全的软件设计?如果是这样,遵循 OWASP 的指导方针就足够了吗?
我正在通过 Intranet 开发应用程序,并且仅供内部员工使用。这里不会涉及任何外部方,应用程序不会使用外部通信。
在这种情况下是否需要安全的软件设计?如果是这样,遵循 OWASP 的指导方针就足够了吗?
虽然Kyle Fennell 的回答非常好,但我想提供一个理由,说明为什么建议安全地设计内部应用程序。
这个事实有许多不同的版本。“50% 的成功攻击始于内部”、“三分之二的数据泄露涉及内部参与者”等。
我能找到的一项统计数据是Verizon 的 2019 DBIR,他们声称:
34% [分析的数据泄露] 涉及内部参与者
无论确切的数字是多少,大量的攻击都涉及内部参与者。因此,将您的威胁模型建立在“它是内部的,因此它是安全的”的基础上是一个坏主意。
我之所以提出滥用,是因为并非所有损害公司的事情都是故意的。有时人们会犯错误,如果人们犯了错误,那么机器可以防止这些错误产生广泛的后果是一件好事。
想象一个允许所有用户做所有事情的应用程序(因为设置权限需要很长时间,在开发过程中没有考虑到等等)。一位用户犯了一个错误并删除了所有内容。这使整个部门陷入停顿,而 IT 部门心脏病发作并带着上周的备份冲向服务器机房。
现在想象相同的应用程序,但具有明确定义的权限系统。用户不小心尝试删除所有内容,但只删除了他们自己分配的任务。他们自己的工作停止了,IT 将上周备份的数据与当前数据合并。今天有 2 名员工无法完成任何有成效的工作,而不是 30 名。这对你来说是一个胜利。
一些公司在技术上是一家拥有多个团队的公司,但它们的分裂方式是团队相互竞争,而不是一起工作。你可能认为这不会发生,但微软长期以来就是这样。
想象一下编写一个供所有团队内部使用的应用程序。你能想象一旦员工发现你可以通过运行他制作的脚本将其他员工锁定 30 分钟,会发生什么?来自“那个其他团队”的员工将不断被锁定在应用程序之外。帮助台本周将第 5次忙碌,试图弄清楚为什么有时人们会被锁定在应用程序之外。
您可能会认为这是牵强附会,但您会惊讶于有些人会在年底获得如此甜蜜的奖金,因为他们的表现比“另一支球队”更好。
现在,在 2020 年,您的应用程序将只被一小部分人使用。在 2029 年,该应用程序将被一些内部人员、一些供应商和一些承包商使用。如果您的供应商之一发现您的应用程序存在缺陷怎么办?如果他们能看到他们的竞争对手之一获得了更好的条件怎么办?
这是您不想陷入的情况,也是您本可以避免的情况。
您编写了一个内部应用程序来执行一些数据库访问工作。多年来它运行良好,没有人抱怨过。现在您必须编写一个访问相同数据的应用程序,但在外部。“简单!”,新手编码员认为。“我将重新使用已经存在的代码。”
现在你被一个外部应用程序困住了,你可以在其中执行 SQL 注入。因为突然之间,“仅供内部使用”(没有双关语)创建的代码在外部使用。首先通过使内部代码正常来避免这种情况。
这个问题的答案是另一个问题“足够做什么?”。起初这听起来很挑剔,但它说明了问题。你到底想保护什么?
为您的应用程序定义一个威胁模型,其中包括您认为谁可能以何种方式对您的应用程序构成威胁,然后为这些单独的威胁找到解决方案。OWASP Top 10 对您来说可能已经足够,也可能不够。
是的,内部应用程序应该通过尽职调查来保护,是的, OWASP可以成为保护您的应用程序的一个很好的指南。还可以查看微软的安全开发生命周期(SDL),它是一个专注于软件开发的安全保证过程。
为什么?
其他人已经提到了一些关于邪恶员工的好处,渗透,纵深防御……但实际远不止这些。我可以从一个随机网页攻击您的内部 Intranet 应用程序。
人们整天点击链接。有时是因为同事看到了他们想要分享的东西,有时是从搜索结果(或广告)中看到的,有时是来自 reddit 等网站的一张可爱的猫图片,上面有 1000 次点赞,有时是来自网络钓鱼电子邮件。
攻击者可以通过多种方式让您点击链接。让我们选择猫图片:对于那些为可爱的猫图片投票的其他数千人来说,它是无害的。直到有人点击谁的公司使用了不遵循 OWASP 指南的令人惊叹的 Intranet 网站。
单击指向恶意页面的链接应该是无害的:浏览器的定期更新可确保其安全,并且不允许该网站访问您计算机的其余部分。这就是为什么让您点击链接如此容易的原因,因为它“基本上是无害的”。但这并不意味着在目标公司网络中拥有一个运行 JavaScript 代码的页面对攻击者来说不是优势。
带有猫图片的页面可能包含如下内容:
1. <img src=cute_cat.jpg>
2. <iframe name=hiddenframe style='display:none'></iframe>
3. <form action='http://intranet.local/addUser.php?username=joseph&password=123456' id=myform target='hiddenframe'>
4. <input type=submit style='display:none'>
5. </form>
6. <script> document.getElementById('myform').submit() </script>
打开页面后,完全不可见,这将能够调用addUser.php
您的 Intranet 应用程序上的页面。如果您已登录(就像您通常在工作时一样),浏览器将愉快地添加您的登录 cookie(包含内部网识别您是您的会话令牌)。攻击者现在在您的系统上拥有一个帐户。对于没有 Intranet 应用程序的人来说,它什么也不做。
这是跨站点请求伪造 (CSRF) 攻击的示例(以及其他一些不良做法),遵循 OWASP 指南可以防止这种攻击。简要概述此代码的作用:
addUser
使用攻击者选择的一些用户名和密码调用该页面。submit()
表单,以便触发提交按钮。如果addUser.php
页面没有(或检查)反 CSRF 令牌,则这种攻击是 100% 可能的,并且许多网站过去都容易受到这种攻击。一个例子?我学校的成绩登记处的内部网。我本可以向老师发送一个数字交接的链接,并且该页面可能(除了显示我的交接)在后台更改了我(或其他任何人的!)成绩。
今天仍然很常见。这是另一个更简单(危害更小)的示例:
1. <img src='cute_cat.jpg'>
2. <img src='http://intranet.local/logout.php'>
这只是调用注销页面。浏览器期望来自该logout.php
页面的图像,但如果没有图像(因为它是注销页面),它只会丢弃结果。同时,Intranet 应用程序将您注销。如果攻击者设法从您保持打开一段时间的选项卡每 2 秒触发一次,您可能无法使用 Intranet,因为您一直处于注销状态。