Closed peterbosalliandercom closed 4 years ago
jessesuen
commented
4 years ago 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
commented
4 years ago Does this mean that argocd is not depending on any other third party scripts in the future? Any idea when?
jannfis
commented
4 years ago @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
commented
4 years ago The other common solution to this issue is an integrity check
jannfis
commented
4 years ago 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.
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.