CRLF 注入 – 攻击解释、检测和预防

CRLF 注射

回车 行 ) ( \r 换 行 尾 。 ( \n ) 通常用于记录 但是，根据不同的平台和 HTTP 协议，这些被使用。 那么，这对应用程序有何影响？ 当服务倾向于响应命令时。 这些在操作平台中被表示为命令。 他们将在命令提交的那一刻采取行动。 我们不能像平台的错一样向他们抱怨。 我们有责任确保我们不会在来自客户端的请求中传递这些字符（ASCII 13、\r 和 ASCII 10、\n）。

如何在攻击中使用它？

攻击者可以通过修改 HTTP 参数或 URL 参数来提交 CRLF 注入。 如上所述，如果这成功提交到服务器。 然后可以执行基于此注入的各种攻击。

HTTP 响应拆分

HTTP 响应拆分是一种通过向网络服务器提交请求以及修改后的数据来利用的攻击。 如果请求像通常的请求一样提交，它将失败。 Web 服务器无法理解它。 但是，为了让服务器理解，攻击者会通过注入 CRLF 来修改和添加恶意数据。 现在，服务器将使用 HTTP 响应标头中的数据响应客户端。 基于标头值的网络浏览器将携带指令。 通过这种攻击，可以进行各种其他攻击，例如跨站点脚本、平衡缓存的标头注入、中毒客户端浏览器。

日志中毒

日志用于应用程序中的各种需求。 有许多已知的日志类型是调试日志、访问日志、基于错误的日志、用户日志、系统日志。 事实上，当今的数据世界围绕着质量日志展开。 我们可以看到请求访问 cookie 以获得更好信息的网站。 同样，许多应用程序商店会记录日志，以便为用户提供最佳体验。 现在，我们知道了日志的用途。

当在日志文件上打印不受信任的数据和未经验证的输入时，日志注入是应用程序中的一个弱点/漏洞。

为什么有人会这样做？ 这样做对他们有什么好处？

我们需要提出这些问题来了解使用日志系统文件的真实情况。

当轨道被覆盖时，攻击者将称攻击成功。 是的，用重复的日志修改和破坏原始日志不会留下跟踪攻击者的痕迹。 当没有达到确切的限制来提醒用户/管理员尝试不成功的次数时，即使是警报系统也会失败，直到攻击者找出进入的方法。

最坏的情况是，如果日志文件在浏览器中呈现，可能会导致基于攻击者恶意数据的 XSS 和其他注入类型的攻击。

预防：

• 永远不要相信客户提供的数据并处理它们。
• 如果要将数据作为响应的一部分发送，请清理输出并发送。
• 如果要记录数据，请在记录前删除 CRLF。
• 禁用 Web 服务器中未使用的标头。
• 给系统打上最新补丁。 由于大多数系统都针对这些漏洞进行了修复。
• 创建 SIEM 用例以在发现这些用例作为提交的监控和响应请求的一部分时发出警报。