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. 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. 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? >
