我是一名安全架构师，我习惯于将项目的安全性定义为由他人执行的规范。我最近的任务是教新编码人员如何使用“设计安全”（以及在不久的将来“设计隐私”）的原则进行设计和编程。我有 30-45 分钟（是的，我知道），而且谈话需要与语言无关。这意味着我需要提供可供 Web 开发人员、应用程序开发人员和基础设施开发人员应用的可操作规则。
我提出了 5 条基本规则和一个补充：
补充：如果您违反规则，请证明缓解措施可以在未来的程序员添加功能后继续存在。
这些规则中的每一个都可以用来自任何语言或应用程序的示例进行扩充，以获得具体指导。我相信这从高层次的角度处理了“设计安全”的大部分一般原则。我错过了什么吗？
设计安全概念的规范资源是Saltzer 和 Schroeder的“计算机系统中的信息保护” 。其精髓被提炼为他们的 8 个安全设计原则：
这些原则于 1974 年制定，今天仍然完全适用。
很难在 30 分钟内教授设计原则。我同意其他人的观点，他们说你必须以某种方式让他们兴奋。我开发了“特权提升”纸牌游戏来让人们对威胁建模感到兴奋，这可能会有所帮助。（https://blogs.microsoft.com/cybertrust/2010/03/02/announcing-elevation-of-privilege-the-threat-modeling-game/）
教人们如何像攻击者一样思考是非常具有挑战性的，教他们一些攻击（如 SQL 注入或跨站点脚本）更容易。
最后，如果您确实想尝试教授原则，我写了一系列博客文章，用星球大战中的场景来说明 Saltzer 和 Schroeder：http: //emergentchaos.com/the-security-principles-of-saltzer-and-schroeder
我不会专注于规则和“遵循这 5 条规则，你就安全了”，而是专注于向开发人员介绍攻击者以及他们的想法。你不能真正涵盖 5 种不同的东西，每一种都需要一些深入的知识才能真正正确实施，那么为什么要尝试呢？
与我交谈过的开发人员似乎认为黑客“真的很难”，并且并不真正理解它到底有多容易。因此，解释人们真正阻止安全的做法可能会令人大开眼界。
一个例子：
几年前，我正在审查基于 Web 的第 3 方报告产品，我们让供应商的开发人员使用该产品创建一些报告。我询问了安全性以及它在他们的产品中是如何工作的。他继续在报告网页上“查看源代码”，并向我展示一切都是动态 HTML，因此是不可破解的。我傻眼了一分钟，但告诉他这不是真正可行的安全措施，你不能相信客户端，等等。
他不相信我，问怎么会有人破解这个产品。我想了一分钟，说我要把浏览器连接到代理服务器，然后检查请求/响应是什么。（今天我只使用 tamper-data 插件）。 然后他说这将是“世纪黑客！” 在这一点上，我只是失败了，因为他已经确定他的产品是“安全的”。说服他的唯一方法是真正破解他的产品，这不值得我花时间，因为无论如何我都不打算购买该产品。
关键是，您需要从对安全性的需求以及我们都面临的问题开始。如果他们不明白这一点，游戏就结束了。至少你会给他们灌输一点恐惧，这是一个很好的动力。据我所见，许多开发人员并没有真正“明白”，他们首先需要了解他们面临的挑战。主要是为了能够理解他们为什么需要开发安全的应用程序。
让人们真正对安全感兴趣，你可能会从中得到一些东西。否则我担心你在 35 分钟内呈现的任何内容都会被置若罔闻。
你可能想先引起他们的注意。SQL 注入攻击的演示简单易懂，并且可能强调该主题的重要性。你可以在整个谈话中回顾它，当你提出观点时。
我喜欢你进入信任边界。通过输入验证，我会更详细地了解这一点。先验证长度，再提白名单和黑名单。您是否建议他们尝试自动修复错误数据，或者是否应该拒绝错误的输入？触摸您推荐的策略。
关于最小权限，这可能是一个介绍基于角色的访问控制思想的机会，以及相对于基于用户的系统的优势。
我认为有机会提到深度防御的原则。输入清理很关键，但是通过要求参数化 SQL 在代码中跟进它会有所帮助，即使有人错过了输入。
关于日志记录，请确保他们了解向用户显示的错误消息与日志文件内容之间的差异。并确保他们没有记录任何敏感信息。
还可以考虑讨论有助于确保他们保持在安全轨道上的开发过程。确保同行代码审查、使用静态代码分析器和动态分析器是他们开发过程的一部分。这可能超出了培训的范围，但你可以教他们审查和工具如何帮助改进他们的代码。
30-45 分钟……哎哟。你可以去组织者那里要求两三天，看看会得到什么样的反应。或者也许是一个 10 学期的课程......无论如何，祝你好运！