JIRA 5.2.11 application vulnerabilities

[Sujata]

Hi Team,

  During JIRA application VA sacn we have identified some vulnerabilities as below,

1. Session token in URL : Sensitive information within URLs may be logged in various locations. Placing session tokens into the URL increases the risk that they will be captured by an attacker

2. Cross site request forgery : Cross site request forgery (CSRF) vulnerabilities may arise when applications rely solely on HTTP cookies to identify the user that has issued a particular request. Because browsers automatically add cookies to requests regardless of their origin, it may be possible for an attacker to create a malicious web site that forges a cross domain request to the vulnerable application.

3. Internal Information Disclosure :Details about infrastructure software are revealed in error messages or some pages of applications. This information is used as input for automated exploit tools, and allow an attacker to quickly learn whether infrastructure software has known vulnerabilities, simplifying an attack. This information is useful to an attacker, and is not needed by a legitimate client.

4. File upload functionality : File upload functionality is commonly associated with a number of vulnerabilities,including: File path traversal ,Persistent cross,site scripting ,Placing of other client,executable code into the domain ,Transmission of viruses and other malware ,Denial of service
 
5. Password Field with autocomplete enabled : The stored credentials can be captured by an attacker who gains control over the user's computer. Further, an attacker who finds a separate application vulnerability such as cross site scripting may be able to exploit this to retrieve a user's browser stored credentials.

6. Input Returned in response : It is a prerequisite for many client side vulnerabilities, including cross site scripting, open redirection, content spoofing, and response header injection. Additionally, some server side vulnerabilities such as SQL injection are often easier to identify and exploit when input is returned in responses

7. Email Address disclosed : Email addresses of developers and other individuals (whether appearing on screen or hidden within page source) may disclose information that is useful to an attacker; for example, they may represent usernames that can be used at the application's login, and they may be used in social engineering attacks against the organization's personnel. Unnecessary or excessive disclosure of email addresses may also lead to an increase in the volume of spam email received.

8. HTML does not specify charset : If a response states that it contains HTML content but does not specify a character set, then the browser may analyze the HTML and attempt to determine which character set it appears to be using. Even if the majority of the HTML actually employs a standard character set such as UTF8, the presence of non standard characters anywhere in the response may cause the browser to interpret the content using a different character set. This can have unexpected results, and can lead to cross site scripting vulnerabilities in which non standard encodings like UTF 7 can be used to bypass the application's defensive filters

Please let us know how to fix these issues.

Our JIRA version is 5.2.11

[Nic Brough -Adaptavist-]

Upgrade to 7.

You're on an old version which has known security issues, and is no longer supported, so there's no patches or fixes available for most of these.

Although I would point out that

5.  This is a failure of your security scans, not Jira.  You want autocomplete enabled so that users can use password safes in their browsers.  If they do not, then they will use weak passwords and/or write them down.  (And you can override "autocomplete off" with some trivial tricks in a browser, so the test is pointless anyway)

7.  Go to admin -> global permissions, and remove all groups from "browse users".  That will remove all email.