安全编码原则
确保应用程序遵循 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 字符! |
URLs
-
应用程序是否使用不受信任的数据来构造 URL?
- 确保在使用前充分对任何此类数据进行清理和编码。
- 确保在使用或存储来自这些 URL 的任何数据之前对其进行检查。
-
应用程序是否遵循重定向?
- 确保对重定向以及原始请求 URI 执行安全检查。
安全控制
- 应用程序是否实施了适当的权限检查?
- 确保在可用时使用正确的 API(例如 shouldLoad 等)
- 确保应用程序安全地失败。
远程系统访问
- 应用程序是否访问任何远程系统?
- 确保使用 TLS,除非有*非常*充分的理由不这样做。
- 确保在未经用户同意的情况下不传输任何用户信息。
信息存储
-
文件存储
-
确保应用程序检查创建的任何文件是否在允许的路径下
-
文件名是否由不受信任的数据生成?
- 确保数据经过适当编码
-
检查文件是否为可接受的类型
-
检查文件大小是否不超过合理限制
-
-
数据库存储
- 确保发送到数据库的任何不受信任的信息都经过充分清理
- 尽可能使用类型安全的参数化来防止注入攻击
-
敏感信息
- 确保任何安全敏感或个人信息得到充分保护(参见加密部分)
- 在处理凭据(密码等)时尤其要注意 - 如果您正在处理此类信息并且不确定该怎么做,最好问一下
-
日志记录
- 不要忘记以上规则同样适用于日志以及您的常规应用程序数据
加密
- 应用程序是否使用任何形式的加密?
- 使用的算法是否为公认的标准?
拒绝服务
- 确保应用程序能够防止耗尽
- 系统内存
- Storage
安全警告
-
应用程序是否向用户显示任何安全警告?
-
它们是否清晰易懂且恰当?
-
不受信任的数据是否会改变用户消息的含义?
- 用户输入是否会改变消息的含义?
- 用户输入是否会将系统消息推离可见屏幕?
- 用户输入是否包含可能改变消息含义的特殊字符(例如,Unicode 从右到左覆盖 U+202E)
-
攻击者是否可以通过对话框的时序来欺骗用户点击他们无意点击的内容?
信息泄露
- 应用程序是否会泄露可能危及用户的信息?
- 应用程序是否会泄露它不需要的信息?
- 应用程序是否会泄露任何可能令用户惊讶或不满的信息?
前端
-
是否使用了安全机制来创建 XUL 和 HTML UI 元素?
- 例如,使用 createTextNode 而不是 innerHTML 或类似的
-
应用程序是否创建自己的 docshells(标签页、iframe)?
- 确保明确指定这些的类型,例如,iframe.setAttribute("type", "content")