软件开发人员应遵循的四项安全原则

安全是一个开发人员常常缺乏理解的话题，因为他们中的许多人只关注安全的技术层面，而不是涉及人员、资金、风险和业务优先级等更广泛的主题。结果，我们经常看到糟糕的决策、不必要的复杂化和资源的浪费。

开发人员在构建或选择安全解决方案时，务必根据其业务或组织情况选择正确的解决方案。初级开发人员尤其需要了解制定安全决策的更广泛背景。

1. 避免教条主义和绝对主义

在最近的 dev.to 文章中，一位贡献者就 JSON Web 令牌和本地存储主题分享了以下建议。

我目前看到的最大的安全违规者是那些将 JWT（会话数据）存储在本地存储的人。很多人没有意识到 JWT 本质上与用户名/密码相同。如果攻击者能够获取你的 JWT 副本，他们就可以以你的名义向网站发出请求，而你永远不会察觉。请像对待信用卡号或密码一样对待你的 JWT：永远不要将它们存储在本地存储中。

这条建议出自那篇文章，非常不错，绝对值得一读，它涵盖了许多与 JavaScript 本地存储相关的重要问题。可惜的是，这篇关于 JWT 和安全性的论述存在误导，或者至少缺乏开发人员需要理解的细微差别。

关于 JWT 和本地存储，我的立场是绝对的：“千万别这么做！” 但是，JWT 的存储位置其实并不重要，即使存储在“安全”的地方也并不能保证安全。关键在于，你在 JWT 中存储了什么？你用 JWT 来做什么或访问什么？

如果这些问题的答案不包含任何个人身份信息，或者只包含极少的个人身份信息 (PII)，那么你大概可以随意使用这些 JWT。相反，如果你对上述问题的答案是“他们所有的信用卡信息！！”，那么你或许应该考虑 JWT 的替代技术。

例如，如果您要像现在许多在线新闻出版物一样实施内容付费墙，那么存储在本地存储中的 JWT 将是一个完全可以接受的安全解决方案。您所保护的内容价值较低，没有 PII，因此黑客入侵这些内容的可能性非常低。然而，JWT 可以阻止普通的 Web 用户在未付费的情况下访问这些内容。这是一个满足安全需求的简单解决方案。

您会注意到，这种解决安全问题的方法不那么教条和绝对。优秀的开发人员往往倾向于教条和绝对，可能是因为他们看到的一切都是“糟糕的”，或者至少不够完美。这有点像公元前五世纪柏拉图看待雅典时的情况，但就像柏拉图一样，这种方法可能会导致糟糕的解决方案和糟糕的答案。对于那些试图理解某个主题的人来说，这种方法可能毫无帮助，尤其是对于初级开发人员来说。

在处理安全问题时，明智的做法是避免教条主义、绝对主义和一刀切的表述。没有哪条道德准则能与“禁止谋杀”等同，因为安全涉及更多细微差别。

2. 安全根本不存在

安全的核心在于它根本不存在，这本身就极具讽刺意味。最近，谷歌 Chrome 在 Twitter 上宣布，他们将把所有使用 HTTP 的网站标记为“不安全”。而他们已经在 URL 栏中将 HTTPS 网站标记为“安全”。

🔐⚠️ 我们翘首以盼的时刻到了！Chrome 将于 2018 年 7 月将所有 HTTP 网站标记为“不安全”。🔐⚠️ https://t.co/2eV4GuEa2y

- 艾米丽·谢克特 (@emschec) 2018 年 2 月 8 日

这很奇怪，因为 HTTPS（通过 TLS 的 HTTP）是一种非常有用的安全增强功能，但并不能保证绝对安全。完全有可能构建一个网站并通过 HTTP 提供服务，而且比通过 HTTPS 提供服务的网站更安全。

谷歌的做法令人意外地不负责任，因为他们可能会鼓励普通网民在不安全的情况下感到安全，从而降低其在线行为的谨慎程度。这还没有涵盖 HTTPS 连接如何实现，请参阅 CloudFlare 灵活 SSL。更合理的做法可能是将连接描述为“私有”或“公共”，但“安全”或“不安全”则具有误导性。

从来没有任何东西是绝对安全的，即使我们取得了如此多的技术进步，也依然存在安全问题。安全始终与被保护的对象相关。几千年来，人们建造了各种各样的城墙，但从未有人成功建造出坚不可摧的穹顶。

不信的话，问问伊朗人就知道了。2009年，美国人（肯定是在以色列人，也可能是英国人的帮助下）入侵了伊朗纳坦兹核设施。你可能还记得震网病毒（Stuxnet）的报道，它很可能就是罪魁祸首。这次黑客攻击的特别之处在于，纳坦兹设施采用了物理隔离，可能是世界上最安全的设施之一。然而，这并没有阻止美国人将病毒带入设施，扰乱伊朗的核生产流程。

如果你对这个话题以及类似的故事感兴趣，我推荐你读读戈登·科雷拉的《拦截：计算机与间谍的秘密历史》。这本书非常棒，能帮你更好地理解安全和黑客攻击的本质。

良好的安全保障意味着要构建一道高于你所保护资产价值的墙。也就是说，黑客入侵你的系统所付出的成本要高于他们从中获得的收益。这也意味着你的安全保障应该与你所保护的内容成正比。例如，不要为了保护你从网络注册表单中收集到的几个电子邮件地址而设置服务器隔离，那将极其浪费金钱。

3. 了解威胁

建造围墙时，了解面临的威胁至关重要。安全威胁可以分为四大类：

1. Kiddy Scripters and Automated Threats：查看大多数 WordPress / Joomla 黑客攻击。
2. 黑客高手及黑客组织： Anonymous、LulzSec
3. 有组织犯罪和小国家行为体：黑手党、朝鲜
4. 主要国家行为体：美国、中国、俄罗斯、以色列、英国

大多数开发人员很少会处理一级以上的事情。原因有两个：你必须从事具有重大经济价值或政治价值的工作才能超越一级。例如，敏感的政府工作、金​​融工作以及大型企业工作。

此外，威胁多种多样，并不一定与黑客数据有关。例如，您的组织可能更容易受到 DDOS 攻击，而不是数据泄露。作为开发人员，您必须考虑您的组织可能面临的漏洞，而主要的漏洞可能并不总是与财务或 PII 相关，也可能与声誉相关。对黑客来说，让您的网站下线并让您的组织蒙羞，可能比窃取您服务器上的 PII 更有价值。

2014年的“Fappening”事件就是一个典型的例子，表明一个组织未能正确理解威胁。在这个案例中，苹果未能正确评估其iCloud系统上的内容，因此未能实施可能限制损害的安全功能。例如，当新设备或陌生IP连接到帐户时发送电子邮件。“Fappening”事件是一个极端案例，因为此前没有人真正考虑过名人数据的价值，但它确实凸显了组织面临的威胁可能并不总是合乎逻辑的。

4. 实施相应的解决方案

如果您在没有适当考虑所面临的威胁的情况下实施通用的安全解决方案，那么您的安全性可能不会比根本没有实施安全措施更安全。

作为开发者，在实施任何安全解决方案之前，必须认真考虑所面临的威胁。这样才能实施适度的安全措施。适度不仅仅与安全威胁有关，还与你能投入的资金规模有关。一个穷国无法建造万里长城，但如果它了解威胁并合理部署资源，就能保卫自己。

世界上许多人都喜欢嘲笑朝鲜、金正恩及其疯狂的核计划。然而，这种疯狂背后或许有其逻辑。有一种理论认为，朝鲜已经意识到美国和西方国家乐于对阿富汗、伊拉克和利比亚进行政权更迭，但对伊朗和巴基斯坦却更加谨慎。该理论认为，这是因为伊朗可能拥有核武器，而巴基斯坦也确实拥有核武器。朝鲜已经意识到这一点，并正在加紧研制核弹和导弹，以免成为下一个伊拉克。朝鲜已经评估了威胁，并在有限的资源下做出了合理的应对，或许能够成功保卫朝鲜政权免受美国核弹的袭击。然而，核弹最终可能无法保护朝鲜免受本国人民的威胁。

我并非建议你效仿朝鲜，但你应该考虑，考虑到你所在组织的资源，什么样的安全响应措施才是合理的。考虑到我们中很少有人在苹果、谷歌或 Facebook 工作，这一点尤为重要。大多数组织资源有限，他们没有理由在收益微乎其微的安全功能上投入巨资。在考虑你的安全响应措施时，你应该首先思考以下三个问题。

1. 我在捍卫什么？它有多有价值？
2. 是谁对我构成威胁？
3. 我的组织有多少资源来保护自己？

如果这些问题的答案是价值低、威胁有限且资源少，那么基本措施就足够了。例如，安全地加密密码、不要存储过多的 PII、实施 CSRF 策略等等。如果答案恰恰相反，那么您就必须考虑更高级的安全功能。如果答案五花八门，您可能不得不在某些方面做出妥协。

这里的要点是，没有“一刀切”的安全解决方案。因此，教条主义和绝对主义根本不适用于安全领域。在考虑安全问题时，请仔细考虑您要保护的对象，然后分析可能存在的威胁。之后，利用您现有的资源构建您的安全墙。