[
https://issues.apache.org/jira/browse/TIKA-3054?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tim Allison resolved TIKA-3054.
-------------------------------
Fix Version/s: 1.24
Assignee: Tim Allison
Resolution: Fixed
> [Dependency] Cross-site Scripting (XSS) in
> org.apache.cxf:cxf-rt-transports-http 3.3.2
> --------------------------------------------------------------------------------------
>
> Key: TIKA-3054
> URL: https://issues.apache.org/jira/browse/TIKA-3054
> Project: Tika
> Issue Type: Bug
> Affects Versions: 1.23
> Reporter: Michael Moritz
> Assignee: Tim Allison
> Priority: Major
> Fix For: 1.24
>
>
> This issue has been created automatically by a source code scanner
> ## Third party component with known security vulnerabilities
> ent-search-master/script/vendor_jars > Jars.lock >
> org.apache.cxf:[email protected]
> ## Overview
> [org.apache.cxf:cxf-rt-transports-http](http://cxf.apache.org/index.html) is
> an open source services framework.
> Affected versions of this package are vulnerable to Cross-site Scripting
> (XSS).
> By default, Apache CXF creates a /services page containing a listing of the
> available endpoint names and addresses. This webpage is vulnerable to a
> reflected Cross-Site Scripting (XSS) attack, which allows a malicious actor
> to inject javascript into the web page. Please note that the attack exploits
> a feature which is not typically not present in modern browsers, who remove
> dot segments before sending the request. However, Mobile applications may be
> vulnerable.
> ## Details
> A cross-site scripting attack occurs when the attacker tricks a legitimate
> web-based application or site to accept a request as originating from a
> trusted source.
> This is done by escaping the context of the web application; the web
> application then delivers that data to its users along with other trusted
> dynamic content, without validating it. The browser unknowingly executes
> malicious script on the client side (through client-side languages; usually
> JavaScript or HTML) in order to perform actions that are otherwise typically
> blocked by the browser’s Same Origin Policy.
> ֿInjecting malicious code is the most prevalent manner by which XSS is
> exploited; for this reason, escaping characters in order to prevent this
> manipulation is the top method for securing code against this vulnerability.
> Escaping means that the application is coded to mark key characters, and
> particularly key characters included in user input, to prevent those
> characters from being interpreted in a dangerous context. For example, in
> HTML, `<` can be coded as `<`; and `>` can be coded as `>`; in order to
> be interpreted and displayed as themselves in text, while within the code
> itself, they are used for HTML tags. If malicious content is injected into an
> application that escapes special characters and that malicious content uses
> `<` and `>` as HTML tags, those characters are nonetheless not interpreted as
> HTML tags by the browser if they’ve been correctly escaped in the application
> code and in this way the attempted attack is diverted.
>
> The most prominent use of XSS is to steal cookies (source: OWASP HttpOnly)
> and hijack user sessions, but XSS exploits have been used to expose sensitive
> information, enable access to privileged services and functionality and
> deliver malware.
> ### Types of attacks
> There are a few methods by which XSS can be manipulated:
> |Type|Origin|Description|
> |--|--|--|
> |**Stored**|Server|The malicious code is inserted in the application (usually
> as a link) by the attacker. The code is activated every time a user clicks
> the link.|
> |**Reflected**|Server|The attacker delivers a malicious link externally from
> the vulnerable web site application to a user. When clicked, malicious code
> is sent to the vulnerable web site, which reflects the attack back to the
> user’s browser.|
> |**DOM-based**|Client|The attacker forces the user’s browser to render a
> malicious page. The data in the page itself delivers the cross-site scripting
> data.|
> |**Mutated**| |The attacker injects code that appears safe, but is then
> rewritten and modified by the browser, while parsing the markup. An example
> is rebalancing unclosed quotation marks or even adding quotation marks to
> unquoted parameters.|
> ### Affected environments
> The following environments are susceptible to an XSS attack:
> * Web servers
> * Application servers
> * Web application environments
> ### How to prevent
> This section describes the top best practices designed to specifically
> protect your code:
> * Sanitize data input in an HTTP request before reflecting it back, ensuring
> all data is validated, filtered or escaped before echoing anything back to
> the user, such as the values of query parameters during searches.
> * Convert special characters such as `?`, `&`, `/`, `<`, `>` and spaces to
> their respective HTML or URL encoded equivalents.
> * Give users the option to disable client-side scripts.
> * Redirect invalid requests.
> * Detect simultaneous logins, including those from two separate IP addresses,
> and invalidate those sessions.
> * Use and enforce a Content Security Policy (source: Wikipedia) to disable
> any features that might be manipulated for an XSS attack.
> * Read the documentation for any of the libraries referenced in your code to
> understand which elements allow for embedded HTML.
> ## Remediation
> Upgrade `org.apache.cxf:cxf-rt-transports-http` to version 3.2.12, 3.3.5 or
> higher.
> ## References
> - [Apache Security
> Advisory](http://cxf.apache.org/security-advisories.data/CVE-2019-17573.txt.asc?version=1&modificationDate=1579178542000&api=v2)
> - [GitHub
> Commit](https://github.com/apache/cxf/commit/a02e96ba1095596bef481919f16a90c5e80a92c8)
> -
> [SNYK-JAVA-ORGAPACHECXF-542666](https://snyk.io/vuln/SNYK-JAVA-ORGAPACHECXF-542666)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
