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