Romi, how many issues total (total count) did your tool identify with CXF?
A potential flaw is not the same as an actual flaw (you'd have to go
through the running code to determine that, usually outside the
capabilities of a software checker), and probably the vast majority of
what an automated tool like Veracode would report would fall into the
former category. If you're aware of actual flaws (and not just
potential ones), by all means, enter a JIRA for it. But CXF does not
code to Veracode (nor can we, it being a commercial product and we're
open source) or any other commercial code-testing tool's specific
standards, indeed, if we tried to please all of them by taking the
intersection of what they each allow it may not be possible to write any
code at all. I suspect you'd easily run into the same issues if you
tried Veracode with Jersey or RESTEasy.
Glen
On 12/02/2012 12:46 PM, Benson Margulies wrote:
On Sat, Dec 1, 2012 at 7:34 PM, Romi Awasthy <[email protected]> wrote:
Here are few sample issues that our tool has identified,
Improper Output Neutralization for Logs:
http://cwe.mitre.org/data/definitions/117.html
org/apache/cxf/common/util/UrlUtils.java line 53
This call to java.util.logging.Logger.warning() could result in a log
forging attack. The first argument to warning() contains tainted data. The
tainted data originated from earlier calls to
org.apache.xml.resolver.Catalog.parseCatalog,
org.apache.xml.resolver.Catalog.resolvePublic,
org.apache.xml.resolver.Catalog.resolveSystem, and
org.apache.xml.resolver.Catalog.resolveURI. Avoid directly embedding user
input in log files when possible.
Why do you think that CXF is responsible for providing secure log messages?
Path-Traversal:: http://cwe.mitre.org/data/definitions/73.html
org/apache/cxf/jaxrs/impl/tl/ThreadLocalServletContext.java line 98
org/apache/cxf/transport/servlet/AbstractHTTPServlet.java line 206
The argument to the function is a filename constructed using user-supplied
input. The first argument to getResourceAsStream() contains tainted data
from the variable path. The tainted data originated from an earlier call to
javax.servlet.http.HttpServletRequest.getPathInfo. If an attacker is
allowed to specify all or part of the filename, it may be possible to gain
unauthorized access to files on the server, including those outside the
webroot, that would be normally be inaccessible to end users.
This doesn't make sense. getResourceAsStream returns only data from
the classpath, not arbitrary file system paths. So long as the
available collection of resources are all the same from a security
standpoint, there's no issue here.
cross-site scripting (XSS) : http://cwe.mitre.org/data/definitions/80.html
org/apache/cxf/transport/servlet/servicelist/FormattedServiceListWriter.java
line 56
org/apache/cxf/transport/servlet/servicelist/
UnformattedServiceListWriter.java line 55
The first argument to write() contains tainted data from the variable
styleSheetPath. The tainted data originated from an earlier call to
javax.servlet.http.httpservletrequest.getrequesturi. The tainted data is
directed into an output stream returned by
javax.servlet.servletresponse.getwriter. Use contextual escaping on all
untrusted data before using it to construct any portion of an HTTP response
HTTP-Response-Splitting : http://cwe.mitre.org/data/definitions/113.html
org/apache/cxf/jaxrs/impl/tl/ ThreadLocalHttpServletResponse.java line 44
This call to javax.servlet.http.HttpServletResponse.addHeader() contains an
HTTP response splitting flaw. Writing unsanitized user-supplied input into
an HTTP header allows an attacker to manipulate the HTTP response rendered
by the browser, to inject additional headers or an entire response body
into the response stream The tainted data originated from an earlier call
to javax.servlet.http.HttpServletRequest.getHeaders.
On Sat, Dec 1, 2012 at 5:41 PM, Benson Margulies <[email protected]>wrote:
I don't see why we should believe that they are flaws unless you tell
us precisely what code it is complaining of and offer an explanation
of the vunerability. These are general descriptions of *possible*
flaws caused by *somewhat risky* coding practices.
On Sat, Dec 1, 2012 at 4:21 PM, Romi Awasthy <[email protected]>
wrote:
We are using Apache CXF Rest for our Restful web services. We ran
Veracode's static security scan on our code base and have identified some
flaws in Apache CXF code, in following categories:
http://www.owasp.org/index.php/Unsafe_Reflection
http://webappsec.pbworks.com/Improper-Output-Handling
http://webappsec.pbworks.com/Path-Traversal
http://webappsec.pbworks.com/HTTP-Response-Splitting
Has anyone else seen these flaws in Apache CXF code and knows any way to
resolve them?
--
Glen Mazza
Talend Community Coders - coders.talend.com
blog: www.jroller.com/gmazza
