安全漏洞 - veracode报告 - crlf注射 [英] security flaw - veracode report - crlf injection

查看:206
本文介绍了安全漏洞 - veracode报告 - crlf注射的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我收到了我的javaEE应用程序的veracode报告。它在任何日志记录中都存在缺陷(使用log4j),因此我将 StringEscapeUtils.escapeJava(log)添加到所有日志中,但是veracode会将它们报告为安全漏洞。 / p>

这是一个正确的解决方案吗?
我还能做什么?



这是报告信息:
标题:
日志输出中和不正确



描述:
函数调用可能导致日志伪造攻击。将未经过授权的用户提供的数据写入日志文件允许
攻击者伪造日志条目或将恶意内容注入日志文件。损坏的日志文件可用于覆盖
攻击者的跟踪或作为攻击日志查看或处理实用程序的传递机制。例如,如果web
管理员使用基于浏览器的实用程序来查看日志,则可能会发生跨站点脚本攻击。



建议:
尽可能避免将用户输入直接嵌入日志文件中。使用安全日志记录机制(如OWASP ESAPI Logger)清理用户提供的用于构建log
条目的数据,该机制将自动删除
意外回车和换行符,并可配置为使用HTML实体编码对于非字母数字
数据。只在绝对必要时才编写自定义黑名单代码。始终验证用户提供的输入以确保符合预期格式的
,尽可能使用集中数据验证例程。



他们建议使用ESAPI,但是这是一个非常大的项目所以我需要最简单的解决方案,这就是为什么我尝试使用String.escape'StringEscapeUtils.escapeJava(log)'



Thx in advanced!

解决方案

我领导Veracode应用安全咨询小组,可以详细回答您的问题。对话的最佳场所是通过Support@veracode.com,因为讨论可能涉及我们可能希望避免公开的有关您的发现的具体细节。



简短的回答是StringEscapeUtils.escapeJava()有效消除典型的CRLF风险,但它不是我们的系统自动识别的机制之一,因为有些情况这可能是不够的。



Veracode系统有一个适当标记这些发现的机制,因此它们不会引起混淆。



请联系Veracode支持(support@veracode.com),我们将能够详细讨论。



祝你好运,
吉姆。


I got the veracode report for my javaEE app. It had a flaw at any logging (using log4j), so I add the StringEscapeUtils.escapeJava(log) to all of them, but veracode keeps reporting them as security flaws.

Is this a right solution? What else can I do?

This is the report info: Title: Improper Output Neutralization for Logs

Description: A function call could result in a log forging attack. Writing unsanitized user-supplied data into a log file allows an attacker to forge log entries or inject malicious content into log files. Corrupted log files can be used to cover an attacker's tracks or as a delivery mechanism for an attack on a log viewing or processing utility. For example, if a web administrator uses a browser-based utility to review logs, a cross-site scripting attack might be possible.

Recommendations: Avoid directly embedding user input in log files when possible. Sanitize user-supplied data used to construct log entries by using a safe logging mechanism such as the OWASP ESAPI Logger, which will automatically remove unexpected carriage returns and line feeds and can be configured to use HTML entity encoding for non-alphanumeric data. Only write custom blacklisting code when absolutely necessary. Always validate user-supplied input to ensure that it conforms to the expected format, using centralized data validation routines when possible.

They recommend to use ESAPI, but it is a very big project so I need the simplest solution, tht's why I tried with String.escape 'StringEscapeUtils.escapeJava(log)'

Thx in advanced!

解决方案

I head up the Veracode Application Security Consulting group, and can answer your question in detail. The best venue for the conversation is through Support@veracode.com, since the discussion may involve specific details about your findings that we probably want to avoid making public.

The short answer is the StringEscapeUtils.escapeJava() is effective at eliminating typical CRLF risk, but it is not one of the mechanisms our system automatically recognizes as there are situations in which it may be insufficient.

The Veracode system has a mechanism for marking these findings appropriately so they do not cause confusion.

Please contact Veracode Support (support@veracode.com), and we'll be able to talk in detail.

Best regards, Jim.

这篇关于安全漏洞 - veracode报告 - crlf注射的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆