DOM text reinterpreted as HTML Update controllers.js

Extracting text from a DOM node and interpreting it as HTML can lead to a cross-site scripting vulnerability. to fix this issue is to use a utility function that escapes HTML special characters. i had created a function escapeHtml that replaces special characters with their corresponding HTML entities. This function can then be used to escape the text content before appending it to the DOM.

Thanks

Thanks for your contribution!

When all of the following conditions are fulfilled, your MergeRequest will be reviewed by the Team:

• the check pipeline passes
• the MR is considered as 'mergeable' by gitlab

You can find more details about the acceptance process here.

This message was automatically generated by homer-bot.

What if they are already escaped? &amp will become &ampamp

Hii @typx Thanks for pointing out the issue with double-escaping in the escapeHtml function. I've updated the implementation to prevent re-escaping already escaped HTML entities by using a negative lookahead in the regex.

herefunction could be updated like this

function escapeHtml(text) {
    return text.replace(/&(?!#?\w+;)|[<>"']/g, function(m) {
        const map = {
            '&': '&amp;',
            '<': '&lt;',
            '>': '&gt;',
            '"': '&quot;',
            "'": '&#039;'
        };
        return map[m] || m;
    });
}

This should skip over & characters that are already part of an entity like &

That screams of a broken kludge. Either the input is or is not escaped. You can't expect the same function to handle different types of inputs blindly.

Isn't text() supposed to escape html anyway?

Hii @Courmisch @typx Yes, ideally input should be consistent, but in some cases we get partially escaped content from mixed sources. This change avoids double-escaping in such edge cases while still protecting the DOM from unescaped HTML.

It is or it is not. This is not an ideal, it's a mandate, as far as I am concerned.

Nack on this patch.

If I believe bf02b8dd it is already escaped by vlc_xml_encode which does properly encode "'&<> (and more).

AFAICT it's not "mixed sources" it's a request on a local page, calling an internal VLC API. If vlm_cmd.xml gets compromised well, it's already running whatever code was put inside and if vlm is compromised well VLC is already running compromised native code in a way less sandboxed environment than your webpage :)

Hii Team Then what your suggestion to do in this ? Thanks

I'm no LUA or LUA http interface expert but unless you have an actual example of attack I don't really see how the problem can happen so personally I'd close that MR and focus on other problems .

Now if you want to help fix known VLC problems, and believe me, help is always welcome, you might want to start with our easy known bugs/tasks pick an unassigned task and express interest on it. (Also you should probably test that your MR actually compile next time )

added MRStatus::InReview label

added Component::Interface: HTTP server Status::BackportCandidate labels