In a previous blog Browser Security Bugs that Aren’t we covered some of the most common submissions to Microsoft Edge’s Bug Bounty program but which unfortunately do not qualify for a reward. The previous blog covered the subject of local attacks, this time we will be covering web exploits; particularly Cross Site Scripting (XSS) attacks.
Common Submissions:
This blog will showcase some of the submissions that we have received in the Edge Security Team in recent years. The reports are anonymized and simplified to focus on their core concept. For each one, I will explain the scenario involved and provide a rationale for why the case was not categorized as a web browser vulnerability.
“I have discovered a persistent XSS in the Microsoft Edge’s PDF viewer”
This is one of the most commonly reported behaviors in the new Adobe powered PDF browser in Microsoft Edge (See our blog on how we hardened our PDF stack). Cross Site Scripting (XSS) is a class of web browser vulnerability wherein an attacker is able to inject scripts into otherwise trusted content. In the context of PDFs, the goal of the attacker would be to insert harmful scripts into the document that usually execute when a user opens the document. Most of the examples provided to our response team simply have a section within the PDF that triggers an app.alert(1). An example document may contain an object definition such as this:
1
2
3
4
5
6
7
4 0 obj
<<
/Type /Action
/S /JavaScript
/JS app.alert(1)
>>
endobj
Modern PDF viewers allow the execution of JavaScript by design. The execution of JavaScript that is contained within the document file does not constitute a vulnerability in the PDF viewer. In this respect, Microsoft Edge’s PDF reader is consistent with the Chromium PDF viewer.
JavaScript within a PDF executes in a separate isolate with the same sandbox environment as the renderer process. Embedding JavaScript within the PDF provides the ability to transform the document with subset of APIs like addIcon. The set of APIs implemented in the new PDF viewer are comparable with Chromium’s “PDFium” viewer. Additionally, it includes a limited set of privileged APIs such as app.alert, which are defined outside of the isolate.
Only a PDF capable of executing JavaScript beyond these limitations or evading the sandbox could present a potential risk to Edge users. A similar bug was able to use font capabilities to run arbitrary JavaScript.
“I can trigger a universal XSS using Edge Translate”
The Microsoft Edge translate feature translates the content of webpages to a language specified by the user. It is reachable through several surfaces, including the address bar, but can also be triggered to run automatically on detection of non-native text content. Since the introduction of Translate in 2020, we have received multiple reports that the page being translated displays an alert box. At first glance, it looks visually similar to the result of an XSS Proof of Concept (PoC). But is it really an XSS? Likely Not.
When we execute the PoC, an alert message will appear that needs to be closed. The page has text in a language other than English, which makes Edge’s auto translation notification offer to translate the page to English (or the preferred language). If we accept the translation notification, the page will be translated, and it will trigger the same alert message. One thing to notice from these cases is that the first and second alert messages are identical. This suggests that the same script is running again after the user chooses to translate the page.
When Edge translates a page it has to re-load the page, which re-executes the page’s scripts. If a script has an alert() function, it will run again and display the alert box. This doesn’t indicate an XSS vulnerability in the translation feature. This is similar to self-XSS, and therefore not something that the Microsoft Edge Team can address.
“I can trigger a universal XSS using Edge Favorites”
The reports that we received on this topic vary in detail but broadly observe JavaScript may be included in Favorites items and executed within the context of the active site when clicked. This is in fact a feature present in all modern web browsers known as bookmarklets. Bookmarklets are designed to assist users in running custom scripts on the active webpage, aiding in various ways, such as the automation of repetitive tasks.
This feature gets reports which can be divided into two categories. The first covers JavaScript stored within in a Favorite URL, which will cause the included JavaScript to run on the current page when the Favorite is chosen by the user. The second is the use of a JavaScript URL as the home button at edge://settings/startHomeNTP. Just like the first way, the included JavaScript will execute in the page.
In both cases the user consciously added the script to either a bookmark or the home button configuration. Neither of these actions are reachable from a web context and as such, the addition and use does not constitute an XSS attack. Note that this particular case is mentioned in the Chromium Security FAQs as well.