我目前正在查看 Veracode 及其代码分析工具套件提供的安全编码实践文档。

在“安全日志记录实践”部分中，他们提到在发生错误时记录完整的 HTTP 请求是一个常见错误，但他们没有解释原因。

我正在一个个人网站上工作，其中有 2 个单独的日志文件：

• errors.log ：任何意外异常最终都会被捕获并记录在该文件中。在那里，我只记录堆栈跟踪（经典的简单基本异常记录）

• security.log ：任何无法通过 UI 发出的请求，这是伪造请求的标志（例如：IDOR 尝试就像有人试图访问另一个用户的数据一样），导致引发自定义运行时安全异常。该安全异常特别存储了发出的 http 请求，然后被记录下来。基本上，当出现问题时，我所有的后端验证器（与前端验证器进行相同的检查）都会抛出此安全异常 - 想法是我（或 Cronned 任务；））可以定期验证 security.log 是否为空.

我决定记录完整的 http 请求（我的意思是：不是原始请求，但我提取所有标头/cookie 和参数并以可读方式显示它们，以及时间戳、原始 IP 等信息）仅用于安全例外（以方便分析潜在的与商业逻辑相关的攻击）。

该日志文件将仅在文本编辑器中打开（很可能是 VI），并且不会被工具自动解析或显示在 web 应用程序中。

现在，我知道在某些情况下可以利用记录完整的 http 请求。一个典型的例子是帮助台使用的容易受到 XSS 攻击的日志分析 Web 应用程序 - 在这种情况下，一旦帮助台人员通过易受攻击的 Web 应用程序检查日志内容，攻击者就可以伪造一个恶意请求，让有效负载爆炸。

我也明白，由于磁盘已满，记录太多内容会导致拒绝服务，但堆栈跟踪已经是这种情况。

就我而言，在特定情况下，记录请求会带来哪些危险？我看到的唯一（技术上有效但不切实际，考虑到网站的低敏感性）是一个特制的有效载荷，当被 VI 解析时可能会导致某种缓冲区溢出（攻击者必须知道我使用 VI + 使用一个 0 天等。对于 NSA 来说可能是可行的，但对于这个小站点来说是不切实际的，除了一些脚本小子之外，它不是感兴趣的目标）。

我想有人可以进行一些日志伪造，但祝你好运找到我独特的请求显示：P 因为我在请求中提取数据并以我自己的方式显示它们，所以实际上不可能通过日志伪造来欺骗我。

我是否应该专门检查文件结尾 VI 控制字符（甚至存在吗？）？

还有什么问题？我在这里错过了什么吗？现在我意识到我的问题可以解释为：“如果我让用户将文本（通过请求内容..）写入我机器上的单个受控文件，该文件只能由最新的井打开，会出现什么问题-经过验证的文本编辑器”

更新

更新以提供有关 3 个第一反馈的更多信息（顺便说一句，感谢您的反馈！）

• 该机制不涵盖登录表单（但注册表是！）
• 我不经营商店，没有高度敏感的信息。最敏感的信息是用户注册期间的名字/姓氏和出生日期。有一个有积分和排名的游戏，所以安全性对于防止作弊很重要（因此这个自定义日志记录）
• 坚持仅记录恶意（绕过前端验证）请求这一事实，在乌托邦世界中，安全日志文件将永远保持空白

感谢您的反馈，我意识到以下几点：

• 由于从请求中提取会话 cookie，披露此文件的内容可能会导致会话劫持
• 请求解析器中的错误可能导致请求未被记录
• 我的代码中的一个错误可能会记录格式错误的用户注册请求，该请求会将敏感信息存储在 secu-log 中（密码显然是最敏感的）

处理：

• 关于文件内容的披露，我假设如果有人到达那里，我已经被 pwned 了:)
• 关于解析器中的错误，确实，但至少它会触发将记录在“正常”记录器中的异常，这是可以接受的
• 关于注册表单，我认为即使发生这种罕见的错误，我也不应该访问明文密码，即使是偶然的。我将调整解析器，使其不存储任何与*password*模式匹配的请求参数。

我想我实际上不能更进一步来保护我的用户（如果我希望能够实时检测 biz 逻辑攻击）。我想网络上 99% 的网站都没有达到这些考虑的一半 :) )。我似乎很清楚，这种自定义日志记录提供的安全优势超过了增加的小攻击面。

我将在代码库的那部分添加额外的全面单元测试，以最终降低错误的风险。

在公司环境中，关于敏感数据的记录，我会猜测两次——我想我会与数据合规官这样的人讨论这个问题