软件开发者的 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 添加到书签,我可以将其复制并粘贴到另一个浏览器中,然后,boom!我就在那里了,无需登录。我问开发人员,“为什么不在每个页面上检查登录信息?如果我只是输入系统中更深层页面的 URL,我可以无需登录即可到达那里。”他问,“你为什么要那样做?”

“因为我能,”我回答道。

不要放过任何机会

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

为什么?因为他们能!

下载 DevSecOps 入门指南

接下来阅读什么
User profile image.
Peter 是一位充满激情的开源爱好者,在过去的 10 年里一直在推广和使用开源产品。他曾在许多不同的领域做过志愿者,从 Ubuntu 社区开始,然后进入音频制作领域,后来又进入写作领域。

6 条评论

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

当你输入一个与存储的密码具有相同哈希值的“密码”时,你认为会发生什么?

哈希冲突(当两个单独的字符串具有相同的哈希值时)当然是可能的,但它非常不可能。即使使用不再推荐使用的 MD5,在测试 2^64 个密码后,你也会有 50% 的冲突机会。这很多密码。

回复 作者:Wim

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

回复 作者:bcotton

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

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

回复 作者:aaroncocker

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

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