Argo-cd: Manipulation of argocd possible through third party scripts

[peterbosalliandercom]

We have the following finding from our pentesters, we like to know what can be done to mitigate the risk

Description
JavaScript code from external domains is included in several parts of the website. In
two cases, JavaScript from an external domain is loaded to offer a user interface for
the API.
Included JavaScript executes in the security context of the including website. If the
external host serving the included files is compromised, all users of the CI/CD
environment website can be attacked through manipulated JavaScript from the
external host, which is also known as Cross-Site Scripting.
Evidence
Use the developer tools of the browser to check which scripts are loaded on the
mentioned URL for example: https:///swagger-ui

Impact: high
Compromised external hosts make it possible to execute arbitrary scripting code in
the target user’s web browser. This scripting code will be executed within the security
context of CI/CD environment. Amongst other scenarios, this makes it possible to:
 Manipulate application interaction. Executed script can be used to perform any
interaction with the application on behalf of the user.
 Obtain cookies. Argo uses a session cookie which carries an ID for access control.
Access to this information provides control over the authenticated session
(account) of the target user. In case of an administrative user, the entire
application or server may be at risk.
 Mimic the web application presented to the target user (defacement). With this
attack, actual working functionality is injected into the vulnerable application,
designed to deceive end users and harvest confidential information such as log in
credentials.
 Perform arbitrary redirection. Redirection can be of use in phishing attacks in
order to induce a target user to visit a spoofed website and enter personal
information. Nowadays malware writers and scammers also use common redirect
vulnerabilities for luring unsuspecting users into installing malware on their
systems.

Recommendation
 Only deploy or install services, middleware and programs which are essential to
the correct working of the application. If partial installations are not possible,
non-essential services and functionality should be removed or disabled.
 Limit the privileges of the API interfaces by including a Content-Security-Policy
header in the response.
 Remove dependencies on external parties by reviewing the scripts and making
the scripts available from the application server directly.
 Make sure external parties are compliant with security guidelines.
 Use Subresource Integrity hashes on script tags to avoid loading manipulated
scripts.
 Reflect the above in a deployment or coding guideline in order to prevent the
same finding in future releases.

[jessesuen]

We have plans on switching off the redoc UI, so this particular piece of software will change.

A workaround would to be disabling this completely for example using a ingress rule that matches /swagger URLs to a 404.

[peterbosalliandercom]

Does this mean that argocd is not depending on any other third party scripts in the future? Any idea when?

[jannfis]

@jessesuen For when it is planned to get rid of the Redoc UI? I think there's a pretty simple, non-intrusive solution to serve the Redoc JavaScript from Argo CD itself.

[tetchel]

The other common solution to this issue is an integrity check

[jannfis]

The other common solution to this issue is an integrity check

I agree that this solution would be good, but in this case we can't do it. This is because the HTML for Redoc is generated by github.com/go-openapi/runtime/middleware (see https://github.com/argoproj/argo-cd/blob/e09cacba659fcb0dbf65b24118c70fef3857b11b/util/swagger/swagger.go#L12).

That library can be parametrized to set the URL from where the script is loaded, but alas no additional parameters for the src tag.