【问题标题】：Threat model document威胁模型文件
【发布时间】：2011-08-28 18:01:10
【问题描述】：

我正在为我托管的一个应用程序编写威胁模型文档。它是一个 Apache 网站，允许用户登录，通过添加一些最畅销的产品等来创建他们的小部件。有人可以给我指点关于如何开始？

前端使用javascript + perl，后端是cpp。我们确实接受来自用户的敏感信息，例如他的姓名、SSN 等，并且我们会存储会话 ID

有哪些方法可以识别应用程序中的安全漏洞？我应该如何开始？
哪些区域应该成为文档的一部分？
我应该了解哪些威胁（如 DoS 等）？

【问题讨论】：

【解决方案1】：

请尽可能多的人思考破坏系统的方法。他们很可能会想到你不会想到的事情。跳出框框思考至关重要。

正确的威胁树分析始于一系列不良结果（“敏感数据泄露”、“服务器被劫持以托管恶意软件/发送垃圾邮件/成为僵尸网络的一部分/无论什么”、“公司通过使用被盗的信用卡详细信息进行诈骗”，希望您能想到更多）并向后工作：发生这种情况需要什么？通常，您会发现每个不良结果都会有几个必需的促成事件 - 因果链 - 通过比较它们，您可以找出薄弱环节并制定深度防御计划。

【讨论】：

【解决方案2】：

这可能无助于构建威胁模型文档，但 OWASP howto 可能会帮助您根据行业最佳实践验证应用程序的设计。

【讨论】：

【解决方案3】：

我不是安全专家，但这是我的两分钱。

1) 您可以放心地将 javascript 视为完全不安全，因为您无法真正控制其执行。

2) 所以，perl 部分是第一道防线。阅读perldoc perlsec 作为入门。

应该检查包含 eval、反引号、system 和 open 的 Perl 代码（始终使用树形参数打开，以确保）。

还应审查缺乏严格/警告的代码，最好重写。

任何未经彻底检查有效性的输入都是可疑的。当然，任何未处理的输入（除了仅由系统存储的用户文件）都不应到达您的后端。

3）根据我最近的经验：

我们进行了 JSON 反序列化，该反序列化基于将输入提供给正则表达式，然后 eval'ing 它。我已经设法通过 perl 代码。失败。
我们有一段代码晦涩难懂、没有严格要求、缺少任何 cmets，并且依赖于外部程序的某些行为，迫使我们使用过时的 ssh 版本。失败。（我承认没有重写它）。
我们有open (FD, "$file");。虽然前导 / 和 .. 已从 $file 中删除，但显然它没有检查管道符号 (|)。可以提供精心设计的命令而不是文件名。失败。始终使用三参数打开。 system/exec 也是如此：只有@array 变体是可以的，不要依赖愚蠢的ls '$file'。