威胁模型文档
我正在为我托管的应用程序之一编写威胁模型文档。它是一个 Apache 网站，允许用户登录、通过添加一些最畅销的产品等来创建他们的小部件。有人可以指导我如何从这个开始？
前端使用javascript + perl，后端使用cpp。我们确实接受来自用户的敏感信息，例如他的姓名、SSN 等，并且我们存储会话 ID
- 有哪些方法可以识别应用程序中的安全漏洞？我应该如何开始呢？
- 该文件应包含哪些内容？
- 我应该阅读哪些威胁（例如 DoS 等）？
I am in the process of writing a threat model document for one of the applications which I am hosting.Its a Apache website which allows users to login, create their widgets by adding some best selling products etc. Can someone give me pointers on how to start with this ?
Frontend uses javascript + perl, backend is cpp. We do accept sensitive information from the user like his name, SSN etc and we do a store session-id
- What are some of the ways I can identify security holes in my application ? How should I start with this ?
- What are some of the areas which should be part of the document ?
- what are some of the threats like DoS etc. which I should read about ?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
询问尽可能多的人来思考打破这个系统的方法。他们很可能会想到你不会想到的事情。跳出框框思考至关重要。
正确的威胁树分析从一系列不良结果开始（“敏感数据泄露”、“服务器被劫持以托管恶意软件/发送垃圾邮件/成为僵尸网络的一部分/无论什么”、“公司因使用被盗的信用卡详细信息而被诈骗”，以及希望你能想到更多）并逆向思考：要实现这一点需要什么？通常，您会发现每个糟糕的结果都会有几个必需的促成事件 - 一个因果链 - 通过比较它们，您可以识别弱点并深入规划您的防御。
Ask as many people as you can find to think about ways to break the system. It's very likely that they'll think of things you won't. Thinking outside the box is crucial.
A proper threat tree analysis starts with a series of bad outcomes ("sensitive data leaked", "servers hijacked to host malware/send spam/be part of botnet/whatever", "company defrauded by use of stolen credit card details", and you can hopefully think of more) and works backwards: what would be necessary for that to happen? Often you'll find that each bad outcome will have several required enabling events - a causal chain - and by comparing them you can identify weak spots and plan your defence in depth.
这可能对构建威胁模型文档没有帮助，但 OWASP howto 可能会有所帮助您可以根据行业最佳实践验证应用程序的设计。
This might not help in building the threat model document, but the OWASP howto might help you in validating the design of the application against the industry best-practice.
我不是安全方面的专家，但这是我的两分钱。
1) 你可以放心地认为 javascript 是完全不安全的，因为你并不能真正控制它的执行。
2）所以，perl部分是第一道防线。首先阅读 perldoc perlsec。
应检查包含
eval、反引号、system和open的 Perl 代码（始终使用树参数 open，只是为了确定）。此外，缺乏严格/警告的代码应该进行审查，最好是重写。
任何未经彻底检查有效性的输入都是可疑的。当然，任何未处理的输入（除了仅由系统存储的用户文件之外）都不应该到达您的后端。
3) 根据我最近的经验：
我们进行了 JSON 反序列化，其基础是将输入提供给正则表达式，然后对其进行
eval处理。我已经成功地传递了 perl 代码。 失败。我们有一大块代码晦涩难懂、不严格、缺乏任何注释，并且依赖于外部程序的某些行为，迫使我们使用过时的 ssh 版本。 失败。 （我承认没有重写它）。
我们有
open (FD, "$file");。虽然前导/和..已从 $file 中删除，但显然没有检查管道符号 (|) 。可以提供精心设计的命令而不是文件名。 失败。始终使用三参数打开。 system/exec 也是如此：只有 @array 变体是可以的，不要依赖愚蠢的ls '$file'。我希望得到其他人的补充和/或更正。
I'm no expert in security, but here are my two cents.
1) You can safely regard javascript as completely insecure, as you don't really control its execution.
2) So, the perl part is the first line of defence. Read perldoc perlsec for starter.
Perl code containing
eval, backticks,system, andopenshould be inspected (always use tree-argument open, just to be sure).Also code that lacks strict/warnings should be reviewed and, ideally, rewritten.
Any input that is not checked thoroughly for validity is suspicious. Of course, no unprocessed input (except for user's files that are only stored by the system) should ever reach your back-end.
3) From my recent experience:
we had JSON deserialization based on feeding the input to a regexp and then
eval'ing it. I've managed to pass perl code through. FAIL.we had a chunk of code that was obscure, strictless, lacked any comments, and relied on certain behaviour of external programs that forced us to use outdated ssh version. FAIL. (I admit to failing to rewrite it).
we had
open (FD, "$file");. While leading/'s and..'s were removed from $file, apparently it wasn't checked for the pipe symbol (|). A carefully crafted command could be supplied instead of a file name. FAIL. Always use three-argument open. Same goes for system/exec: only @array variant is OK, don't rely on stupidls '$file'.I would appreciate additions and/or corrections from other people.
有关威胁建模的方法，请查看 MyAppSecurity 的 ThreatModeler。从高级架构图可视化您的应用程序并识别潜在威胁以及在安全代码和安全控制方面找到补救控制措施非常容易。
干杯
For your methodology of Threat Modeling, check out MyAppSecurity's ThreatModeler. Pretty easy to visualize your application from a high level architecture diagram and identify potential threats as well as find remediating controls in terms of secure code and security controls.
Cheers
免责声明：
合规性和法规。
我实在无法为你总结，请阅读：
http://en.wikipedia.org/wiki/Information_privacy_law
美国：FISMA 和 FIPS
（包括但不限于...）
有标准和法律
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
回到问题...
199 和 200 将为您提供评估需要做什么的良好起点。
例如，对于 perl... https://cve.mitre.org/cgi-bin/cvekey.cgi ？关键字=perl
从信息治理 (IG) 的定义开始：
http://searchcompliance.techtarget.com/definition/information-governance
评估信息如何被使用以及在哪里使用。
使用 CVE/漏洞利用数据库中的相关信息为您自己的软件编写渗透测试。
我发现使用系统架构图有助于确定哪些部分需要独立测试和隔离；以及要保护哪些边界。
如果您已经阅读了上一节，您应该对可以在文档中添加哪些内容有一个很好的了解。
这些都列在 CVE/漏洞利用数据库中。
Disclaimer:
Compliance and regulations.
I really cannot sum it up for you, please have a read:
http://en.wikipedia.org/wiki/Information_privacy_law
United States : FISMA and FIPS
( Including but not limited to... )
There are standards and laws
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
Back to the question...
FIPS 199 and 200 will give you good starting points for evaluating what needs to be done.
e.g. for perl... https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=perl
Start with this definition of Information Governance (IG):
http://searchcompliance.techtarget.com/definition/information-governance
Assess how the info is used and where.
Write penetration tests for your own software using relevant info from the CVE / exploit database.
I find that using a system architecture diagram is helpful in identifying what parts to test independently and isolate; and which boundaries to secure.
If you have looked and the previous section, you should have a good idea about what you could put in the document.
These are listed in the CVE / Exploit databases.