fix: DOM text reinterpreted as HTML Improper Neutralization of Input Cross-site Scripting

[odaysec]

mongo/src/third_party/wiredtiger/src/docs/style/header-web.html

Line 42 in 0a68308

<select id="version_select" onchange="window.location=window.location.href.replace('$projectbrief',this.value);">

Extracting text from a DOM node and interpreting it as HTML can lead to a cross-site scripting vulnerability. A webpage with this vulnerability reads text from the DOM, and afterwards adds the text as HTML to the DOM. Using text from the DOM as HTML effectively unescapes the text, and thereby invalidates any escaping done on the text. If an attacker is able to control the safe sanitized text, then this vulnerability can be exploited to perform a cross-site scripting attack.

POC

The following vulnerable shows a webpage using a data-target attribute to select and manipulate a DOM element using the JQuery library. In the data-target attribute is read into the target variable, and the $ function is then supposed to use the target variable as a CSS selector to determine which element should be manipulated.

$("button").click(function () {
    var target = $(this).attr("data-target");
    $(target).hide();
});

However, if an attacker can control the data-target attribute, then the value of target can be used to cause the $ function to execute arbitrary JavaScript.

The above vulnerability can be fixed by using $.find instead of $. The $.find function will only interpret target as a CSS selector and never as HTML, thereby preventing an XSS attack.

$("button").click(function () {
    var target = $(this).attr("data-target");
	$.find(target).hide();
});

References

• DOM based XSS Prevention Cheat Sheet.
• XSS (Cross Site Scripting) Prevention Cheat Sheet.
• DOM Based XSS.
• Types of Cross-Site Scripting.
• Cross-site scripting.
• CWE-79.
• CWE-116.

[kelly-cs]

Hi @odaysec!

Thanks for the report! This code is imported from https://github.com/wiredtiger/wiredtiger/blob/develop/src/docs/style/header-web.html so that repo probably makes more sense for the change.

Since this is a security issue, we normally prefer the bug submission form. I've flagged this internally.