Below are the following vulnerabilities our Vulnerability Assessment raised. Please resolve or suggest work-arounds:

1. Emails Allow Arbitrary Hyperlinks.

"The webmail application allows users to input links with arbitrary protocols when composing emails. This could lead to malicious consequences for victims that click on links that use certain protocols. For example,
an attacker with a presence on the same network as the victim could input an SMB link pointing to a malicious host in order to conduct an SMB relay attack to compromise the user's workstation (or another host) and steal their password hash once the user clicks on the link.
For an example of how SMB relay attacks can be
executed, see the following SpiderLabs blog about the popular Responder tool:
https://www.trustwave.com/Resources/SpiderLabs-Blog/Responder-2-0---Owning-Windows-Networks-part-3/
For more information please refer to section 4.6
Emails Allow Arbitrary Hyperlinks."

2. Email Address in URL String.

"The webmail application exposes the user's email address in the URL of all authenticated HTTP requests. This results in unnecessary information exposure in that these URLs may be stored in local browser history and cache (see issue 18735-1-08). Within a shared computing environment, this may reveal the identity and email address of our.email.domain users to other
computer users, which may be undesirable. An attacker that obtained this information would be able to use it in other attacks, such as phishing and social The following is an example URL path used when viewing the user inbox:
/SOGo/so/geva.shamam1@our.email.domain/Mail/0/folderINBOX/view
For more information please refer to section 4.7 Email Address in URL String. engineering attacks."

3. Insecure Cookie Attributes

"The application does not set the 'Secure' flag on the user's session token (0xHIGHFLYxSOGo). This could lead to the affected cookie being transmitted over an unencrypted channel and intercepted by an attacker, who could use it to gain unauthorised access the user's session.
The likelihood of this finding being exploited is
reduced as the application implements HTTP Strict Transport Security (HSTS), which results in all application traffic being encrypted in transit. However, as HSTS is not supported by Internet Explorer prior to version 11, the 'Secure' flag should be set if users are likely to access the site using Internet Explorer 10 or other older browsers.
The application did not send any unencrypted HTTPrequests in normal usage, which lowers the likelihood of a successful attack. However, an attacker performing an active man-in-the middle attack can inject an unencrypted link to the application into another webpage being viewed by the user, resulting in their browser sending cookies over an unencrypted channel.
In addition the application does not set the 'HttpOnly' flag when cookies are set. This flag prevents JavaScript from accessing the cookie. This helps mitigate the impact of any cross-site scripting (XSS) vulnerability within the application.
No XSS weaknesses were identified in the application. This reduces the likelihood of this issue being exploited.
Currently the Set-Cookie header for the session cookie is formed as follows:
set-cookie: removed hash; path=/SOGo/"

4. Mass User Data Extraction

"The contact search function available when composing emails retrieves user contact details in an insecure fashion, allowing a malicious user to extract excessive amounts of user data in a single request. Using an inline web proxy, it is possible to intercept the relevant HTTP request and submit a search for a single letter. This returns records for all webmail application
users in the Domain Address Book with names
containing that letter. Each record returned includes the following data fields:
c_cn
c_component
c_mail
c_o
c_screenname
c_telephonenumber
c_uid
containerName
emails
fn
has Photo
id
During testing, it was possible to submit a request for the letter 'a' and retrieve a 54MB response containing details for 135800 users. An attacker could abuse this ability to quickly extract large amounts of data about personnel which could then be used in other attacks such as Social Engineering, Phishing and reconnaissance.
Note: when searching for contacts in the application graphical UI, client-side controls appear to require searching to a minimum of two letters and limit the amount of results. This makes it appear that only a small amount of results are retrieved each time. In fact the underlying HTTP request is receiving a large
number of results that are being reduced only in the user's application view.
For more information please refer to section 4.4 Mass User Data Extraction."