# vulnerability in AWX **URL:** \ **Category:** AWX Project\ **Tags:** awx, kubernetes\ **Created:** [April 16, 2020, 12:40pm UTC](https://forum.ansible.com/t/vulnerability-in-awx/32702 "2020-04-16T12:40:02Z")\ **Posts on this page:** 2\ **Page:** 1
**Author:** ![Amit\_Bhatia](https://avatars.discourse-cdn.com/v4/letter/a/9fc29f/32.png) [@Amit\_Bhatia](https://forum.ansible.com/u/Amit_Bhatia)\ **Post date:** [April 16, 2020, 12:40pm UTC](https://forum.ansible.com/t/vulnerability-in-awx/32702/1 "2020-04-16T12:40:02Z")
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: - [https://10.61.244.164:32164/static/partials/login/loginModal/loginModal.partial.html](https://10.61.244.164:32164/static/partials/login/loginModal/loginModal.partial.html) The form contains the following password field: - login\_password 1. 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](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}} 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: - [https://10.61.244.164:32164/static/partials/login/loginModal/loginModal.partial.html](https://10.61.244.164:32164/static/partials/login/loginModal/loginModal.partial.html) The form contains the following password field with autocomplete enabled: - login\_password 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: - [tz@iana.org](mailto:tz@iana.org) 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 ---
**Author:** ![Bill\_Nottingham1](https://avatars.discourse-cdn.com/v4/letter/b/58f4c7/32.png) [@Bill\_Nottingham1](https://forum.ansible.com/u/Bill_Nottingham1)\ **Post date:** [April 16, 2020, 7:33pm UTC](https://forum.ansible.com/t/vulnerability-in-awx/32702/2 "2020-04-16T19:33:37Z")
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](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](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. \ > 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