软件开发人员的 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 行的代码编写一个暴力破解程序非常容易,包括 { }。 我在学习 PHP 不到 3 个小时内就写出来了。

回复 作者:bcotton

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

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

回复 作者:aaroncocker

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

知识共享许可协议本作品采用知识共享署名-相同方式共享 4.0 国际许可协议进行许可。
© . All rights reserved.