Recently, we discovered a cross-site scripting vulnerability during a penetration test, which was only made possible using a third-party plugin. What was surprising: the vulnerability seemed to occur only when the website used a specific language. As a result, we took a closer look.

Why does this vulnerability occur?
The web application under test was based on Shopify and used a plugin named Weglot that translated its content into different languages. For the translation, an API associated with the plugin was used, which received the content to be translated within a request. The response resulting from the API then contained the translated content, and the client’s browser then embedded everything correctly into the web page. A (reflected) cross-site scripting was possible as soon as input – originating from a user – was part of the translation to be performed. In our case, for example, a classic search bar within the web page was everything we needed for a successful exploitation.

Interestingly, the search bar, which is part of the ordinary functionality of Shopify systems, is not inherently vulnerable to reflected cross-site scripting: all contents of our malicious code were correctly HTML-encoded according to best practices, if we did not use the translation plugin due to the default language set. If we changed the language so that the plugin became active, the page was vulnerable to a reflected cross-site scripting. The following graphic illustrates the relationship between the entities user, the tested target application and the Weglot API used for translation:

The first request and the corresponding response show the expected and secure behavior of the search function within the target website. It should be noted – as described earlier – that our cross-site scripting payload is correctly encoded in HTML and the application thus protects itself against cross-site scripting in this case. The second request and the corresponding response provide information about the cause of the identified vulnerability: among other things, the previously html-encoded cross-site scripting payload is also sent to the API of the translation plugin, only in this case it comes back unicode-encoded. And this unicode-encoded payload can be interpreted as regular HTML or Javascript by the client’s browser; this again can trigger cross-site scripting payloads.

What is the impact?
By the time you can read about this issue, it has already been resolved. Further research had revealed that many different content-management-systems for which this plugin is provided – probably not only Shopify and WordPress – were vulnerable to the described attack. As shown, the only condition for a successful attack seemed to be user-entered content is sent to the API for translation. As a quick reminder, what does a cross-site scripting attack entail? Not only simple alert boxes are invoked, but also other actions can be performed in the background and in the context of the user in the same or foreign web application – so-called Cross Site Request Forgery – and in the worst-case code can be executed on visitors’ systems – a so-called Remote Code Execution.

How to mitigate?
After verifying the vulnerability, the plugin manufacturer was also contacted immediately in an effort to report and fix the identified issue. As stated before, the vendor was already able to resolve this issue and as the vulnerability was linked to behavior on the backend, you will not need to install a patch here.

Conclusion
At this point, we would like to thank Weglot for this short-term and small, but excellent cooperation. Not only was the vulnerability fixed promptly, but there was also a very interesting, professional exchange about the cause and effect of the vulnerability!

This scenario shows that you can be vulnerable precisely because you use third-party software. Blind trust in any software is simply not recommended. This is another reason why it is advisable to perform regular checks and tests.

Also, due to the dynamic nature of the various requests that were made during the mentioned translation, no reputable web vulnerability scanner has been able to detect this vulnerability in an automated manner. In a case like this, curiosity and skepticism on the part of the pentester are key to finding vulnerabilities with a potentially high impact.

Der Beitrag Case Study – Reflected Cross-Site-Scripting in Weglot Translator Plugin erschien zuerst auf e2 Security.