Render content from untrusted sources via web_preview endpoint on Acronis Cloud

## Summary Hi team, I found a way to render videos from external sources in the following endpoint via the GET parameter named **url**: - `https://mc-beta-cloud.acronis.com/fc/web_preview/video.html` The following endpoints seems to correctly sanitize it throwing an error due to the incorrect URL: - `https://mc-beta-cloud.acronis.com/fc/web_preview/image.html` - `https://mc-beta-cloud.acronis.com/fc/web_preview/text.html` - `https://mc-beta-cloud.acronis.com/fc/web_preview/pdf.html` ## Description Using the normal flow of the application when rendering an uploaded video it will have the following URL format: `https://mc-beta-cloud.acronis.com/fc/web_preview/video.html?name=videoname.mp4&url=%2Ffc%2Fapi%2Fv1%2Fsync_and_share_nodes%2F{UUID}%2Fpreview&uuid={UUID}` Then, the backend will construct the URL to reflect it in the HTML in this way: 1. Get the **url** GET parameter. If the **url** contains the **protocol + host**, i t will use it as the domain where to load the video, otherwise it will use the default one which is **https://mc-beta-cloud.acronis.com**. The url variable at this point for the previous URL will be **/fc/api/v1/sync_and_share_nodes/{UUID}/preview** 1. Finally, get the file extension of the **name** parameter and concat their value to the previous variable. The URL variable now is **/fc/api/v1/sync_and_share_nodes/{UUID}/preview.mp4** For example, for the following URL check the reflection of the **url** parameter in the **src** attribute: `https://mc-beta-cloud.acronis.com/fc/web_preview/video.html?name=video.mp4&url=%2Ffc%2Fapi%2Fv1%2Fsync_and_share_nodes%2F370ed02b-6e09-49c1-a629-ef7d2c4e9dde%2Fpreview&uuid=370ed02b-6e09-49c1-a629-ef7d2c4e9dde` {F2139437} Using this understanding we can use it to load external videos, for example visiting this link: `https://mc-beta-cloud.acronis.com/fc/web_preview/video.html?name=1.mp4&url=http:%2F%2flocalhost%2fmyvideo&uuid=75db761a-112e-47d2-befb-b9f1eeac76ae` You will notice that it will render the video from the url -> `http://localhost/myvideo.mp4` About the **uuid** parameter there are some protections in place. It check if the uuid submitted exits or not, but we can bypass it using the uuid of a public link. ## Steps To Reproduce 1. Login in your Acronis Cloud account. 1. Visit `https://mc-beta-cloud.acronis.com/fc/web_preview/video.html?name=video.mp4&url=https://mr-medi.github.io/assets/video&uuid=370ed02b-6e09-49c1-a629-ef7d2c4e9dde` and check the rendered video from the external source. In this case `https://mr-medi.github.io/assets/video.mp4` but you can change it. You can visit the previous link and don't even need to be logged on Acronis Cloud. This is due to the **uuid** parameter is from a public video I uploaded on Acronis Cloud, therefore unauthenticated requests to external websites can be made as well. In this case the external request is made to my website. But you can change it to endpoints that does not return a video. Using the following link you can track users or perform GET Based CSRF attacks. Check how we bypassed the file extension being appended by adding a **/** in the **name** parameter: `https://mc-beta-cloud.acronis.com/fc/web_preview/video.html?name=/&url=/api/2/users/me/?IMTHEVIDEO&uuid=75db761a-112e-47d2-befb-b9f1eeac76ae` In the next video you can see it too as well as making the GET Based CSRF possible attack vectors: {F2139475} ## Recommendations This seems to be an issue while handling the value of the parameter **url** in the server-side. If the parameter contains the protocol + host prefix like **https://myserver.com** in the URL you append it to the **src** attribute of the **source** HTML Tag, instead of defining a variable with a static value like **https://mc-beta-cloud.acronis.com** or making a whitelist of allowed host where to load external content. So, it's possible to load videos or making requests to external websites. In theory, in Acronis Cloud you must only be able to see content uploaded from your account or public content uploaded in Acronis Cloud if you have the correspondent link. I think that since your users trust the top domain **mc-beta-cloud.acronis.com** where they are watching the content media, they may be able to be tricked into perform some actions by loading content from untrusted sources or making them think that the correspondent video belongs to his account. ## Impact Additional attack scenarios can be **GET Based CSRF** attacks and **tracking users** pointing the URL to the attacker server and log the User-Agent and IP of Acronis users. I will let you know if I found valid GET Based CSRF endpoints which can be chained with this report.