我正在为我托管的一个应用程序编写威胁模型文档。它是一个 Apache 网站,允许用户登录,通过添加一些最畅销的产品等来创建他们的小部件。有人可以给我指点如何从这个开始?
前端使用javascript + perl,后端是cpp。我们确实接受来自用户的敏感信息,例如他的姓名、SSN 等,并且我们会存储会话 ID
- 有哪些方法可以识别应用程序中的安全漏洞?我应该如何开始?
- 哪些领域应该成为文件的一部分?
- 我应该阅读哪些威胁,例如 DoS 等?
我正在为我托管的一个应用程序编写威胁模型文档。它是一个 Apache 网站,允许用户登录,通过添加一些最畅销的产品等来创建他们的小部件。有人可以给我指点如何从这个开始?
前端使用javascript + perl,后端是cpp。我们确实接受来自用户的敏感信息,例如他的姓名、SSN 等,并且我们会存储会话 ID
让尽可能多的人思考打破系统的方法。他们很可能会想到你不会想到的事情。跳出框框思考至关重要。
正确的威胁树分析始于一系列不良结果(“敏感数据泄露”、“服务器被劫持以托管恶意软件/发送垃圾邮件/成为僵尸网络的一部分/无论什么”、“公司因使用被盗的信用卡详细信息而被骗”,以及希望您能想到更多)并向后工作:发生这种情况需要什么?通常你会发现每一个糟糕的结果都会有几个必要的促成事件——一个因果链——通过比较它们,你可以找出弱点并深入规划你的防御。
这可能无助于构建威胁模型文档,但 OWASP howto可能会帮助您根据行业最佳实践验证应用程序的设计。
我不是安全专家,但这是我的两分钱。
1) 您可以放心地将 javascript 视为完全不安全,因为您并不能真正控制其执行。
2) 所以,perl 部分是第一道防线。阅读perldoc perlsec作为初学者。
应该检查包含eval
、反引号、system
和的 Perl 代码(始终使用树形参数打开,以确保)。open
缺乏严格/警告的代码也应该被审查,最好是重写。
任何没有彻底检查有效性的输入都是可疑的。当然,任何未处理的输入(除了仅由系统存储的用户文件)都不应到达您的后端。
3)根据我最近的经验:
我们基于将输入提供给正则表达式然后eval
'ing 它进行 JSON 反序列化。我已经设法通过 perl 代码。失败。
我们有一大段代码晦涩难懂,没有任何注释,并且依赖于外部程序的某些行为,迫使我们使用过时的 ssh 版本。失败。(我承认没有重写它)。
我们有open (FD, "$file");
。虽然从 $file 中删除了前导/
' 和..
',但显然没有检查管道符号 ( |
)。可以提供精心设计的命令而不是文件名。失败。始终使用三参数打开。system/exec 也是如此:只有 @array 变体是可以的,不要依赖愚蠢ls '$file'
的。
我将不胜感激其他人的补充和/或更正。
有关您的威胁建模方法,请查看 MyAppSecurity 的ThreatModeler。从高级架构图可视化您的应用程序并识别潜在威胁以及找到安全代码和安全控制方面的补救控制非常容易。
干杯
免责声明:
我既不是安全专家,也不是合规专家,也不是律师。不要从表面上接受这个建议。在处理机密信息时,您应该寻求专家的建议。
我真的无法为你总结,请阅读: http ://en.wikipedia.org/wiki/Information_privacy_law
( 包括但不仅限于... )
有标准和法律 http://en.wikipedia.org/wiki/Federal_Information_Security_Management_Act_of_2002 http://en.wikipedia.org/wiki/Federal_Information_Processing_Standards
FIPS 199:http ://csrc.nist.gov/publications/fips/fips199/FIPS-PUB-199-final.pdf
FIPS 200:http ://csrc.nist.gov/publications/fips/fips200/FIPS-200-final-march.pdf
我们确实接受来自用户的敏感信息,例如他的姓名、SSN 等
FIPS 199 和 200 将为您提供良好的起点来评估需要做什么。
有哪些方法可以识别应用程序中的安全漏洞?
例如对于 perl... https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=perl
我应该如何开始?
从信息治理 (IG) 的定义开始: http ://searchcompliance.techtarget.com/definition/information-governance
评估信息的使用方式和位置。
使用 CVE / 漏洞利用数据库中的相关信息为您自己的软件编写渗透测试。
哪些领域应该成为文件的一部分?
我发现使用系统架构图有助于确定要独立测试和隔离哪些部分;以及要确保哪些边界。
如果您已经查看了上一节,您应该对可以在文档中放入的内容有一个很好的了解。
我应该阅读哪些威胁,例如 DoS 等?
这些都列在 CVE / Exploit 数据库中。