Firefox 安全指南
目的
本文档概述了一套安全指南,这些指南通常适用于所有客户端应用程序,例如 Firefox 和 Thunderbird。
安全编码原则
确保应用程序遵循 OWASP 安全编码原则
- 最小化攻击面
- 建立安全默认值
- 最小权限原则
- 纵深防御原则
- 安全失败
- 不要信任服务
- 保持安全简单
- 正确修复安全问题
输入验证
- 应用程序是否接受用户输入?
- 验证输入位置样本,以确保在接受用户数据时已设置合理的最大值
- 验证输入位置样本,以确保应用程序仅允许一组定义的允许字符
- 确保使用白名单而不是黑名单
- 应用程序是否接受以任何方式显示的用户输入?
- 验证输入和输出位置的样本,以确保用户提供的内容在响应中被正确编码
Chrome JS - 危险函数
是否使用了以下任何函数?
如果是,请确保它们是安全的,并且没有更好的替代方案可用。
名称 | 风险等级 | 问题 | 解决方案 |
---|---|---|---|
eval | 非常高 | 调用 JavaScript 解析器 - 如果与不受信任的输入一起使用则很危险 | 尽可能避免使用 eval。 |
setTimeout(string, time) | 非常高 | 类似于 eval | 使用 setTimeout(function, time, param1, param2, …) |
C++ - 危险函数
是否使用了以下任何函数?
如果是,请确保它们是安全的,并且没有更好的替代方案可用。
名称 | 风险等级 | 问题 | 解决方案 |
---|---|---|---|
gets | 非常高 | 无边界检查 | 不要使用 gets。请改用 fgets。 |
strcpy | 非常高 | 无边界检查 | 只有当源字符串是常量且目标字符串足够大以容纳它时,strcpy 才是安全的。否则,请使用 strncpy。 |
sprintf | 非常高 | 无边界检查,格式字符串攻击 | sprintf 很难安全地使用。请改用 snprintf。 |
scanf, sscanf | 高 | 可能没有边界检查,格式字符串攻击 | 确保所有 %-指令都与相应的参数类型匹配。不要在没有边界检查的情况下使用 '%s' 指令。使用 '%xs',其中 x 是相应参数的缓冲区大小。不要在格式字符串中使用不受信任的、未经验证的数据。 |
strcat | 高 | 无边界检查 | 如果输入大小未知且不固定,请改用 strncat。 |
printf, fprintf, snprintf, vfprintf, vsprintf, syslog | 高 | 格式字符串攻击 | 不要在格式字符串中使用不受信任的、未经验证的数据。如果格式字符串可能受 Web 内容或用户输入的影响,请在调用这些函数之前验证其 %-指令的数量和类型是否正确。确保目标大小参数正确。 |
strncpy, fgets, strncat | 低 | 可能不会以 null 结尾 | 始终显式地以 null 结尾目标缓冲区。确保大小参数正确。确保在目标缓冲区中留出空间以添加 null 字符! |
URL
- 应用程序是否使用不受信任的数据来构建 URL?
- 确保在使用之前对任何此类数据进行充分的清理和编码。
- 确保在使用或存储之前检查从这些 URL 获取的任何数据。
- 应用程序是否遵循重定向?
- 确保对重定向以及原始请求 URI 执行安全检查。
安全控制
- 应用程序是否实现了合适的权限检查?
- 确保在可用时使用正确的 API(例如 shouldLoad 等)
- 确保应用程序安全失败。
远程系统访问
- 应用程序是否访问任何远程系统?
- 除非有非常充分的理由不使用,否则请确保使用 TLS。
- 确保未经用户同意不传输任何用户信息。
信息存储
- 文件存储
- 确保应用程序检查创建的任何文件是否在允许的路径下
- 文件名是否由不受信任的数据生成?
- 确保数据已适当地编码
- 检查文件是否为可接受的类型
- 检查文件不能超过合理的尺寸限制
- 数据库存储
- 确保发送到数据库的任何不受信任的信息都已充分清理
- 在可能的情况下,利用类型安全的参数化来防止注入攻击
- 敏感信息
- 确保任何安全敏感或个人信息都得到充分保护(请参阅加密部分)
- 必须特别注意凭据(密码等) - 如果您正在处理此类信息并且不确定该怎么做,最好随时询问
- 日志记录
- 不要忘记上述规则也适用于日志以及您通常的应用程序数据
加密
- 应用程序是否使用任何形式的加密?
- 使用的算法是否为公认的标准?
拒绝服务
- 确保应用程序防止耗尽
- 系统内存
- 存储
安全警告
- 应用程序是否向用户显示任何安全警告?
- 它们是否清晰易懂且合适?
- 不受信任的数据是否可以更改用户消息的含义?
- 用户输入是否可以更改消息的含义?
- 用户输入是否可以强制系统消息超出可见屏幕?
- 用户输入是否可以包含可以更改消息含义的特殊字符(例如 Unicode 从右到左覆盖 U+202E)?
- 攻击者是否可以使用对话框的时间来欺骗用户点击他们不想点击的内容?
信息泄露
- 应用程序是否泄露可能危及用户的信息?
- 应用程序是否泄露任何它不需要泄露的信息?
- 应用程序是否泄露任何可能让用户感到惊讶或不安的信息?
前端
- 是否使用安全机制创建 XUL 和 HTML UI 元素?
- 例如,使用 createTextNode 而不是 innerHTML 或类似方法
- 应用程序是否创建了自己的 docshell(选项卡、iframe)?
- 确保您明确这些类型,例如 iframe.setAttribute("type", "content")