vulnerability in AWX

Hi Team,

We run Burp suit on AWX 9.0.1 deployed on kubernetes cluster and found below vulnerability:

  1. The following cookie was issued by the application and does not have the secure flag set:
  • sessionid
    The cookie appears to contain a session token, which may increase the risk associated with this issue. You should review the contents of the cookie to determine its function.This issue was found in multiple locations under the reported path.
  1. The following cookie was issued by the application and does not have the secure flag set:
  • csrftoken
    The cookie appears to contain a session token, which may increase the risk associated with this issue. You should review the contents of the cookie to determine its function.This issue was found in multiple locations under the reported path.
  1. The following cookies were issued by the application and do not have the secure flag set:
  • csrftoken
  • sessionid
    The cookies appear to contain session tokens, which may increase the risk associated with this issue. You should review the contents of the cookies to determine their function.
  1. The following cookies were issued by the application and do not have the secure flag set:
  • csrftoken
  • sessionid
  • current_user
    The highlighted cookies appear to contain session tokens, which may increase the risk associated with this issue. You should review the contents of the cookies to determine their function.
  1. The following cookie was issued by the application and does not have the secure flag set:
  • userLoggedIn
    The cookie does not appear to contain a session token, which may reduce the risk associated with this issue. You should review the contents of the cookie to determine its function.
  1. The page contains a form with the following action URL, which is submitted using the GET method:
  1. The page contains a form with the following action URL, which is submitted using the GET method:
  1. The following cookie was issued by the application and does not have the HttpOnly flag set:
  • csrftoken
    The cookie appears to contain a session token, which may increase the risk associated with this issue. You should review the contents of the cookie to determine its function.This issue was found in multiple locations under the reported path.
  1. The following cookie was issued by the application and does not have the HttpOnly flag set:
  • csrftoken
    The cookie appears to contain a session token, which may increase the risk associated with this issue. You should review the contents of the cookie to determine its function.
  1. The following cookies were issued by the application and do not have the HttpOnly flag set:
  • csrftoken
  • current_user
    The highlighted cookie appears to contain a session token, which may increase the risk associated with this issue. You should review the contents of the cookies to determine their function.
  1. The following cookie was issued by the application and does not have the HttpOnly flag set:
  • userLoggedIn
    The cookie does not appear to contain a session token, which may reduce the risk associated with this issue. You should review the contents of the cookie to determine its function.
  1. The page contains a form with the following action URL:
  1. The response states that the content type is application/octet-stream. However, it actually appears to contain unrecognized content.

The following browsers may interpret the response as HTML:

  • Internet Explorer 11
  • Internet Explorer 11 (Compatibility Mode)
  • Edge
  1. The value of the URL path folder 1 is copied into the application’s response.

  2. The following email address was disclosed in the response:

  1. The following RFC 1918 IP address was disclosed in the response:
  • 192.168.2.100
  1. The following RFC 1918 IP addresses were disclosed in the response:
  • 10.102.98.102
  • 10.111.187.58
  • 10.96.0.1
  • 10.96.45.199
  • 10.97.245.66
  1. 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 UTF-8, 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.
    In most cases, the absence of a charset directive does not constitute a security flaw, particularly if the response contains static content. You should review the contents of affected responses, and the context in which they appear, to determine whether any vulnerability exists.
    HTTP/1.1 200 OK
    Server: nginx
    Content-Type: text/html

Is it possible to confirm if these are genuine and needs to be addressed or is it safe to ignore these.

Regards,
Amit

Amit Bhatia (bhatia.amit1987@gmail.com) said:

1) The following cookie was issued by the application and does not have
the secure flag set:

   - *sessionid*

The cookie appears to contain a session token, which may increase the risk
associated with this issue. You should review the contents of the cookie to
determine its function.This issue was found in multiple locations under the
reported path.

Well, yes, the session id cookie is for the session id.

4) The following cookies were issued by the application and do not have the
secure flag set:

   - *csrftoken*
   - *sessionid*
   - current_user

The highlighted cookies appear to contain session tokens, which may
increase the risk associated with this issue. You should review the
contents of the cookies to determine their function.

Check your SESSION_COOKIE_SECURE and CSRF_COOKIE_SECURE settings.
Note that the development environment, and certain proxy-fronted
deployments, may not work depending on what you set these to.

5) The following cookie was issued by the application and does not have the
secure flag set:

   - userLoggedIn

The cookie does not appear to contain a session token, which may reduce the
risk associated with this issue. You should review the contents of the
cookie to determine its function.

Not an issue.

6) The page contains a form with the following action URL, which is
submitted using the GET method:

   -
   https://10.61.244.164:32164/static/partials/login/loginModal/loginModal.partial.html

The form contains the following password field:
   
   - login_password

7) The page contains a form with the following action URL, which is
submitted using the GET method:

   -
   https://10.61.244.164:32164/static/partials/templates/prompt/steps/survey/prompt-survey.partial.html

The form contains the following password field:
   
   - survey_question_{{$index}}

Not an issue.

<a bunch of duplicate items snipped>

13) The response states that the content type is *application/octet-stream*.
However, it actually appears to contain *unrecognized content*.

The following browsers may interpret the response as HTML:
   
   - Internet Explorer 11
   - Internet Explorer 11 (Compatibility Mode)
   - Edge

Not supported browsers, in any case it's not an AWX bug.

14) The value of the URL path folder 1 is copied into the application's
response.

What?

15) The following email address was disclosed in the response:

   - tz@iana.org

Not an issue.

16) The following RFC 1918 IP address was disclosed in the response:

   - 192.168.2.100

17) The following RFC 1918 IP addresses were disclosed in the response:

   - 10.102.98.102
   - 10.111.187.58
   - 10.96.0.1
   - 10.96.45.199
   - 10.97.245.66

These are probably your IP addresses.

18) 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 UTF-8, 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.

Not an issue.

Is it possible to confirm if these are genuine and needs to be addressed or
is it safe to ignore these.

I don't see anything in these.

Bill