软件开发人员的 3 个安全提示

不要犯这些常见的安全错误,它们会使您容易受到攻击。
416 位读者喜欢这篇文章。
Improve your DevOps security game with Ansible Vault

Opensource.com

每位开发人员都知道遵循最佳安全实践的重要性。但是我们常常偷工减料,也许是因为我们必须努力工作直到这些安全实践深入人心。不幸的是,这种情况通常需要看到非常糟糕的安全失误,以至于它在我们的大脑中被永久地标记出来。

在我的职业生涯中,作为一名系统管理员,我见过很多糟糕的安全实践案例,但我将在这里描述的三个是每个软件开发人员都应该避免的基本事项。重要的是要注意,我见过大型公司和经验丰富的开发人员都犯过这些错误,所以你不能将这些错误归咎于新手初级工程师。

[下载 DevSecOps 入门指南]

1. 不要加密密码,对它们进行哈希处理。

在我的职业生涯早期,我曾为一家公司工作,该公司使用一个管理系统,其中包含一些非常重要的信息。有一天,我被要求对网络和存储我们关键信息的软件进行安全审查。我花了几分钟四处查看,然后决定启动 Wireshark,看看网络上运行的流量。

我使用了我的本地工作站,登录了信息系统,并注意到一些奇怪的事情。即使这在 SSL 风靡之前,我也不希望看到包含“username”和“password”等字节的纯文本数据。经过仔细检查,似乎系统正在通过线路发送我的用户名和一个随机字符串——这不是我的密码。我不能就此罢休。我再次尝试登录,但这次我故意输入了错误的密码。我没有更改所有密码,只是更改了一个字符。

 

我期望看到的是一个完全不同的随机字符串来表示密码。相反,只有前两个字节发生了变化。这很有趣。即使我相对缺乏经验,我也知道如果我的密码的表示形式被哈希处理,正如它应该的那样,它将是完全不同的,而不仅仅是两个字符不同。甚至一个好的加密方案也会做到这一点。然而,这根本没有做到这一点。我又尝试了两个错误的密码。

 

我拿着一些纸和一支铅笔,花了接下来的两个小时来弄清楚解密方案。在这两个小时结束时,我编写了一个 Python 脚本,它可以获取任何这些“加密”密码并将其解密以显示原始密码,这是任何人都不应该能够做到的。我确信,想出这个加密方案的人从来没有想过,一个有几个小时空闲时间的人会坐下来解决它,但我做到了。

为什么?因为我可以。

如果您必须存储密码以进行比较,请永远不要加密它们,因为始终存在有人可以找到解密算法或密钥的可能性。哈希没有直接的反向,这意味着除非他们已经有一个从纯文本到哈希的映射表(或者他们只是猜测),否则没有人可以反转它。知道哈希机制不会泄露数据的完整性,而知道加密方案和密钥则会。

2. 不要在软件中放入秘密后门。

作为第三方软件部署的一部分,我正在支持一些用户,他们告诉我他们的登录不起作用。这是一项由供应商提供的付费服务,但在处理通常是最令人恼火的支持电话之一(“我的登录不起作用”)之前,我想我会自己尝试一下。事实证明,登录确实不起作用。

该系统是一个基于 Web 的学习管理平台,我们只为它更大功能的一小部分付费。当我在登录页面上多看了看时,有什么东西引起了我的注意。其中一个单词中的一个字符看起来不同。也许是不同的字体,一个稍微不同的“o”形状。我这个人,在源代码视图中查看了页面,并注意到有一个链接与这个特定的字母相关联。该链接是故意隐藏的。鼠标光标悬停在它上面时不会改变。

我小心翼翼地将那个神秘链接加载到一个新的浏览器窗口中。突然,我遇到了一个屏幕,详细介绍了一整套计算机,让我可以完全控制它们可以做什么,以及关闭它们、重启它们、截取屏幕截图的能力,等等。我打电话给软件供应商,要求与 IT 人员通话。在经历了一些周折之后,我终于找到了一个知道我在说什么的人。

“哦,是的!”他说。“我们把它放在那里是为了方便访问,在你之前没有人发现它。我们会立即删除它。”在我们结束通话之前,他问了我最后一个问题:“你为什么要开始挖掘 HTML?”

我的回答很简单:“因为我可以。”

在任何系统中放置一些花哨的后门访问权限都不值得冒险,因为你可以打赌,肯定有人会找到它。无论多么晦涩难懂,代码分析——以及一般的探测和戳探——通常会产生最令人惊讶和有趣的结果。

3. 在每个页面上验证用户身份——而不仅仅是在登录页面上。

在我职业生涯的某个阶段,我参与了一个软件开发项目,该项目由一位经验丰富的开发人员实施。由于对这个特定的应用程序感到有点力不从心,我告诉我的经理,我们需要对代码进行深入的安全审查。我被要求先自己看看,看看我能发现什么。我开始玩这个应用程序,登录并查看了一些数据。然后我发现了一些非常有趣的东西。

如果我将我深入系统后访问的其中一个 URL 添加到书签,我可以将其复制并粘贴到另一个浏览器中,然后砰!我就在那里了,无需登录。我问开发人员:“你为什么不在每个页面上检查登录?如果我只是输入系统中更深层页面的 URL,我就可以在不登录的情况下到达那里。”他问:“你为什么要这样做?”

“因为我可以,”我回答道。

不要把任何事情都寄托于偶然

即使是经验丰富的开发人员也可能犯这些错误。他们认为,没有人会尝试深入研究他们没有真正访问权限的系统。问题是人们会探测,他们会戳探。我,一个只涉足安全领域的人,想要在这里传达的首要建议是:不要把任何事情都寄托于偶然。那里有像我这样的人,他们喜欢深入研究事物,看看它们为什么以及如何工作。但也有很多人会挖掘以利用你的缺陷和漏洞。

为什么?因为他们可以!

下载 DevSecOps 入门指南

接下来阅读什么
User profile image.
Peter 是一位充满热情的开源爱好者,在过去的 10 年中一直在推广和使用开源产品。他曾在许多不同的领域担任志愿者,最初在 Ubuntu 社区,后来转向音频制作领域,再后来转向写作。

6 条评论

简而言之
* 哈希不是加密!
* 用糟糕的解决方案代替可能的问题不是答案
(问题:加密密钥丢失 > 糟糕的解决方案:不要使用加密)
(* 使用适当的加密)

您认为当输入与存储的哈希值相同的“密码”时会发生什么..

哈希冲突(当两个不同的字符串具有相同的哈希值时)绝对是可能的,但这非常不可能。即使使用不再推荐的 MD5,在测试 2^64 个密码后,您仍有 50% 的机会发生冲突。那是非常多的密码。

回复 作者 Wim

当我在大学学习 PHP 时,很明显,在不到 10 行代码中编写一个暴力破解程序非常容易,包括 { }。我花了不到 3 个小时的 PHP 学习时间就写出来了。

回复 作者 bcotton

对于合理的哈希算法来说,这并不是一个充分的攻击向量。

很棒的文章!关于使用哈希函数的建议应包括“使用盐”。否则,您很容易受到彩虹攻击,最终会像 LinkedIn 一样。 :-)

回复 作者 aaroncocker

Pete,这是一篇很棒的文章。我也喜欢“只是因为我可以”而摆弄软件。我建议新的计算机科学专业的学生也做同样的事情,了解底层系统以及不该做什么。例如,Windows 上的一些应用程序正确地使用 /AppData 目录来存储临时文件,而我见过其他应用程序使用 /ProgramFiles、注册表或单独的 .hidden 文件来存储用户凭据,认为它对其他用户是安全的。惊喜,事实并非如此。

Creative Commons License本作品根据知识共享署名-相同方式共享 4.0 国际许可协议获得许可。
© . All rights reserved.