Reflected Cross-Site Scripting (XSS)

[yasanthau]

Hi,

Upon a vulnerability scan, it is requested to fix the above issue on Zimbra Server (8.8.7_GA_1964.RHEL7_64_20180223145016 RHEL7_64 FOSS edition). Please refer the details below.

A Reflected Cross-Site Scripting (XSS) vulnerability occurs when a web application sends strings that were provided by an attacker to a victim's browser in such a way that the browser executes part of the string as code. The string contains malicious data and is passed as to the application through a parameter that an attacker can control (e.g. a URL parameter or an HTML form field). The application immediately inserts it into its response. This results in the victim's browser executing the attacker's code within a legitimate user's session. Attackers typically exploit reflected XSS vulnerabilities by sending users malicious links containing JavaScript code (e.g. via e-mail) or by posting malicious code to other sites that the vulnerable application's users may visit.
Reflected Cross-Site Scripting vulnerabilities give the attacker control of the user's browser. The attack can alter page content with malicious HTML or JavaScript code. The attacker can arbitrarily alter page content displayed to the victim and can execute application functions using the victim's application identity if the victim is authenticated to the application. An often cited example use of a Reflected Cross-Site is where the attacker sends himself/herself the victim's session identifier. With this session identifier, the attacker can then perform application functions using that user's identity for the duration of that session.

Remediation:
Reflected Cross-Site Scripting (XSS) is prevented by encoding data before inserting it into the generated web page. Each character of the data is encoded and the result string is then inserted onto the generated web page. This technique of encoding values before inserting them on the web page is called "Output Encoding". Output Encoding libraries exist for most popular programming languages and frameworks.
A web page has seven different output contexts and each output context requires a different encoding scheme. Data must be encoded using the proper scheme. The seven different encoding
schemes are:
• HTML Text Element
• HTML Attribute
• URL Parameter
• JavaScript Literal
• HTML Comment
• HTTP Header
• CSS PropertyFor example, the characters: <, >, ", ' are encoded as <, >, ",' for when those characters are inserted into an HTML Text Element. When those characters are inserted as a URL Parameter, the same characters are encoded as %3C,%3E, %22, %27. Libraries for implementing the encoding schemes exist for most popular programming languages.
• OWASP Java Encoder: Java only
• Microsoft Web Protection Library: .NET languages
• Ruby - escapeHTML() - only supports HTML Text Encoding
• Jgencoder in JQuery: for preventing DOM-based XSSGreen field projects can consider
the use of other technologies:
• Google Capabilities based JavaScript CAJA
• OWASP JXT- automatically encodes string data with the proper encodingInput validation is often recommended as a way to mitigate reflected cross-site scripting. It is insufficient, however, because input validation can be used to prevent cross-site scripting only when the data has a strict syntactic format, such as numeric values and dates. Any application inputs which must accept arbitrary data would remain vulnerable.

Any solution to this issue is highly appreciated.

Thanks,

Yasantha

[7224jobe]

Recent patches and minor releases of Zimbra fixed some XSS security issues...I do not know if they fixed the one you are reporting, but it is advisable to update your Zimbra installation. Here on this section of the blog: https://blog.zimbra.com/product-updates/ you can see recent updates.

[jeastman]

You can also check the Zimbra Security Center site (https://wiki.zimbra.com/wiki/Security_Center) to get information on the specific issues which have been addressed in the available patches.