Access JIRA in internet as of now it's working only in intranet

Kavitha Chandramohan December 26, 2016

HI,

Earlier a JIRA ticket has been raised regarding this issue with reference to that ticket (Reference: GHS-65913) our  corporate security team came up with the below recommendations to do the configuration changes in JIRA application. I want to know whether the below changes are feasible to do in the application.

Kindly let me know which needs to be done in application and which to be done in server side.

PS: Our JIRA maintenance is expired and the current version is 7.1.4.

Expecting your response as early as possible.

 

S.No

APPLICATION VULNERABILTIY

DESCRIPTION

FIX

Severity

1

Server Version disclosure

Knowing the version and type of a running web server allows testers to   determine known vulnerabilities and the appropriate exploits to use during   testing.

Remove the server name, its version/type from the HTTP Response   headers.

Low

2

Stack/trace enabled

The application must handle all errors and   must not display any debug information or verbose messages thus revealing   sensitive parameters

 

Disable Stack/trace methods.

Medium

3

Apache Tomcat Error message

Apache Tomcat Error message   is obtained. These can reveal various kinds information depending on the type   of error.

Create custom error pages without exposing server/application related   information.

Medium

4

X-Frame options not set

X-Frame-Options   header is not included in the HTTP response to protect against 'Click   Jacking' attacks.

X-Frame Options header: SAMEORIGIN

Medium

5

Web Browser XSS Protection Not Enabled

The X-XSS-Protection HTTP   response header allows the web server to enable or disable the web browser's   XSS protection mechanism.

Ensure   that the web browser's XSS filter is enabled, by setting the X-XSS-Protection   HTTP response header to '1'.

 

Low

6

Cookie without HTTPOnly, secure flag set

When a cookie is set with the secure, HTTPOnly flag, it instructs the   browser: cookie can only be accessed by the server and not by client-side   scripts. This is an important security protection

Of session cookies.

o             Ensure you have   mod_headers.so enabled in Apache instance

 

o             Add following   entry in httpd.conf

 

                Header edit   Set-Cookie ^(.*)$ $1;HttpOnly;Secure

                Restart Apache   Web Server

Low

7

Auto completed enabled

AUTOCOMPLETE attribute is not disabled in HTML FORM/INPUT element   containing password type input.    Passwords may be stored in browsers and retrieved.

Set AUTOCOMPLETE to “off” in all forms.

Low

8

File Upload

Uploaded files may   pose a significant risk if not handled correctly. A remote attacker could send   a multipart/form-data POST request with a specially-crafted filename or mime   type and execute arbitrary code.

Restrict file types accepted for upload:   check the file extension and only allow certain files to be uploaded. Use a   whitelist approach instead of a blacklist. Check for double extensions such   as .php.png. Check for files without a filename like .htaccess (on ASP.NET,   check for configuration files like web.config). Change the permissions on the   upload folder so the files within it are not executable. If possible, rename   the files that are uploaded.

 

Medium

9

Enable HTTPS over the URL

User credentials are transmitted over an unencrypted channel. This   information should always be transferred via an encrypted channel (HTTPS) to   avoid being intercepted by malicious users. Touch   base with the NSS Team for the same.

Raise a GSD ticket using below   category in GSD - NSS – DCS for enabling HTTPS over the URL.

Wintel-Development --> Web   --> Installations

 

High – GSD Ticket has been raised and in WIP

10

Cross Site Scripting

Cross site scripting (also referred to as XSS) is a vulnerability that   allows an attacker to send malicious code (usually in the form of Javascript)   to another user. Because a browser cannot know if the script should be   trusted or not, it will execute the script in the user context allowing the   attacker to access any cookies or session tokens retained by the browser.

Filter metacharacters from all user input fields.

 

User whitelisting approach to accept user input characters.

High

11

Vulnerable JavaScript Library

Detected versions:

1.8.24

1.7.2

 

Upgrade to the latest version of JavaScript library and uninstall the   older versions of the same.

High – Java 8 is installed on the server. How   to verify the Java versions 1.8.24 & 1.7.2

12

Login page password guessing attack

This login page doesn't have any protection against password-guessing   attacks (brute force attacks).

It's recommended to implement some type of account lockout after a   defined number of incorrect password attempts

Low – This is resolved

2 answers

0 votes
Kavitha Chandramohan December 27, 2016

Thanks for your response. Let's proceed with your recommendations.

0 votes
Nic Brough -Adaptavist-
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
December 27, 2016

This looks like an auto-generated security scan that's been done on a non-configured JIRA, and some of them on a system that isn't even JIRA, and then read by someone who doesn't know what they are doing.

  1. You can configure your Tomcat and/or proxy to do that
  2. It doesn't on the most part, you have to dig deep to get a stack trace in front of the user, and if you do, there's nothing you can do with it anyway.  Stack traces go into logs
  3. Yes, configure the proxy
  4. "
  5. "
  6. "
  7. Nonsense, as it can be bypassed by the browser.  The change would get you no extra security.
  8. This scan wasn't run on a JIRA system, and even if it had been, the user doesn't understand that the application does not allow it
  9. Yes, you should do that, on your side
  10. Mmm.  There may well be a valid concern here, but the suggested fix is inadequate and generally wrong for this type of application
  11. Your security team don't know what they are doing.  JAVA is not Javascript
  12. Yes it does.  Scan is incorrect, unless you were on a very old JIRA, or your admins had deliberately disabled it.

You can fix 11 and possibly improve some stuff on 10 and 2 - renew your licence and upgrade to a later version.  The other concerns you have are all network or proxy server related stuff.  Not bad suggestions, but made by a team that don't really understand what they're doing judging by the comments makes me somewhat skeptical

Suggest an answer

Log in or Sign up to answer